2012-06-25 69 views
1

我不知道發生了什麼,但每次我輸入以下命令:PowerShell測試連接-TimeToLive錯誤?

Test-Connection -ComputerName TARGET -TimeToLive 6 

我得到了以下錯誤:

Test-Connection : Testing connection to computer 'TARGET' failed: Problem with some part of the filterspec or providerspecific buffer in general 
At line:1 char:16 
+ Test-Connection <<<< -ComputerName TARGET -TimeToLive 6 
    + CategoryInfo   : ResourceUnavailable: (TARGET:String) [Test-Connection], PingException 
    + FullyQualifiedErrorId : TestConnectionException,Microsoft.PowerShell.Commands.TestConnectionCommand 

有趣的是,如果我不把-TimeToLive參數,例如:

Test-Connection -ComputerName TARGET 
Test-Connection -ComputerName TARGET -Count 2 

這些命令按預期工作!並做Get-Help Test-Connection誘人地表明,-TimeToLive確實是一個有效的參數。

我哪裏錯了?

+1

使用-TimeToLive參數適合我。你可以在另一臺電腦上查看嗎? – ravikanth

+0

@ravikanth它確實在其他計算機上工作。 IIRC,它*使用*正常工作,但現在不再工作。可能是什麼原因,我想知道...... – pepoluan

+1

在測試localhost時是否會出現相同的錯誤? – SpellingD

回答

2

每個發送出去的IP數據包都有一個TTL字段,該字段被設置爲相對較高的數字(在LAN中的ping爲128的情況下)。當數據包通過網絡時,每個經過的路由器都會將TTL字段減1;當TTL降到0時,數據包被路由器丟棄。 IP規範說TTL應該設置爲60(儘管它對於ping包是255)。這樣做的主要目的是讓一個數據包不會永遠活在網絡上,並在它被認爲「丟失」時最終死亡。

在你的局域網中,可能有6個TTL不能到達目的地。

在我的環境中,在兩跳子網中只有1個ping的TTL返回您的錯誤,並且對,我只有一個核心路由器/交換機用於多個vlans和一個本地路由器,每個子網/域不同。

+0

PowerShell中的'-TimeToLive'參數不是** IP數據包的TTL字段。它應該正確地命名爲'-TimeOut',但名稱已經被卡住了。 – pepoluan

+1

@pepoluan mmmhh ...我認爲是TTL字段(是ping -i,與ping.exe的-w參數沒有關係:以毫秒爲單位等待每個回覆的超時。) –

+1

您可以嘗試如果ping .exe -i 6 TARGET'給出相同的結果? –

-1

好的,經過幾個星期的不間斷工作,我昨晚在我回家之前重新啓動了筆記本電腦。

今天早上,令人驚訝-TimeToLive再次作品!

所以,我主要「不能夠使用-TimeToLive」的問題已經解決了......

...但我仍然不知道,原先發生了什麼是-TimeToLive導致的錯誤.. 。

+0

您在_laptop_上觀察到這一事實是一個進一步的線索,即'-TimeToLive'不是seconds_中的_timeout,而是_max。 hop count_:也許在您重新啓動的時候,您碰巧連接到_different_網絡,目標主機恰好可以通過_6或更少的跳數訪問。 – mklement0

+0

好吧,這已經是很久以前的事了,但我記得目前我使用電纜連接到公司的網絡。即使我有權連接到WiFi(由高層管理人員使用),我也使用電纜(千兆位以太網FTW)。我認爲這是Windows作爲Windows的簡單情況。 – pepoluan

+0

不需要依賴很久以前的內存:查找一個服務器,其中'ping -i 1 -n 1'返回「TTL在傳輸中過期」(幾乎是瞬間的,而不是在1秒之後),並且與'Test-Connection - TimeToLive 1 -Count 1' - 你會看到'ping'和'Test-Connection'並行失敗。繼續增加TTL值以查看兩個命令最終開始使用相同的值; 'ping -i'表示TTL爲_hops_,'Test-Connection-TimeToLive'也是如此,儘管文檔聲明如此。在數據包級別驗證這一點不應太難。 – mklement0

1

這個答案是基於我自己的實驗。如果我錯了,請告訴我。
這個答案的依據CB.'s helpful answer

TL;博士

  • -TimeToLive,儘管什麼Test-Connection documentation說(仍然爲PSv5.1的和also in the source-code repository on GitHub[1] ),不是一個超時,但跳數的最大數量數據包可以在它被認爲是expir之前編輯。

    • 因此,它類似於ping.exe-i <TTL>參數。
    • Test-Connection的默認值-TimeToLive - 80 - 提供線索,這是不超時在,因爲這將是過高的。
    • Test-Connection沒有相當於ping.exe的真正基於時間的-w <ms>超時參數。
  • 在這種情況下(problem with some part of the filterspec or providerspecific buffer in general最可能源於的分組中的晦澀錯誤消息具有在運輸過程中到期,由於低的TTL(跳數限制)值。

    • ping.exe將在該事件中報告更有幫助的TTL expired in transit

TTL(時間 -to-Live)的是名不副實在實踐中,這是一個已經在IPv6中得到糾正的問題,如Wikipedia告訴我們(重點煤礦):

In theory, under IPv4, time to live is measured in seconds, although every host that passes the datagram must reduce the TTL by at least one unit. In practice, the TTL field is reduced by one on every hop. To reflect this practice, the field is renamed hop limit in IPv6.

雖然TTL真正代表了什麼是混淆,但它是可以理解的不幸的是,Test-Connection文件中的錯誤信息在很多年裏都沒有得到糾正。


[1]我已經打開an issue there跟蹤的問題。