Hi, I have a this setup : [server] -- [Cisco Switch] -- [windows client]. When I try to ping the server from client with -l 1200, I get "Request timed out" errors. I verified that the MTU on server is set to 9000. The MTU on windows client was set to 1010. I tried ping -f -l 970 and it succeeds but anything above 970 fails. I changed the MTU setting on the windows client to 9000. Then I tried ping with -l 1000 but it failed. I tried to capture wireshark and it shows the request packets from client to server but info shows "no response found". I tried to open a ftp session from client to server and captured the trace and I can see in the handshake SYN packets the MSS is 9000. So what possibly could be a reason for ping to fail? If the size of the icmp packet is bigger than 970 then I should at least get the message saying that it needs fragmentation. And if the -f (don Thanks! asked 04 Apr '15, 06:36  vondutch9 showing 5 of 7 show 2 more comments |
This is a static archive of our old Q&A Site.
Please post any new questions and answers at ask.wireshark.org.
Can you please upload a capture file (google drive, dropbox, cloudshark.org) that shows the various ping tests and the TCP connection, and then post the link here?
If the size of the icmp packet is bigger than 970 then I should at least get the message saying that it needs fragmentation.
This is not the case. RFC 792 states:
I have noticed this same thing this morning on Windows 7. (MTU=1500)
ping blah -f -l 1450 = No reply. Nothing. like really nothing captured ping blah -f = reply (sent 32bytes) ping blah -f -1400 = Fragmentation required ping blah -f 1373 = request timed out ping blah -f 1360 = reply
The sizes are not the point, but the sometimes nothing and sometimes fragmentation warning is starting to make life annoying. (1373 = Nothing but 1400 = reply fragmentation required???)
It is definitely the case and it does not matter where you ping. play with the sizes and you will see sometimes you get fragment required and sometimes not. I followed the path, always the same route.
*Update: The route stayed the same, however on the route I noticed that the one address had several (5) different IP Addresses. I watched a bit more closely and noticed that ONE of these addresses always gave me a Type 4 and the rest didn't.. Just called the provider of the servers and he went "oops" So I assume that in the next few minutes either my rogue Fragment needed will probably black hole on me or I will get Type 4 from everyone..
With regard to No response found: I get this in most Ping requests, And right after that a response stating request in ** Probably a timing issue or something
Just looked at "No response found". If you capture live ICMP and a ping takes longer than 100ms or so, then I always see "No response found" in the info field. If I then switch profiles or reload, the ICMP request is refreshed and matches the reply. can someone else verify this and I'll open a bug report if need be. Not sure if this is one of the users problems, but it probably doesn't help. 1.12.4 before someone asks.
I can confirm that we are seeing the same behaviour although it does not appear to be related to size. OUr ICMP packets are only 65 bytes (520 bits). In a particular capture we are seeing response times above 200ms (I'll try and find something better to test against) and when we save the capture and re-open it there ICMP packets appear to be recalculated. All of the 'no response found!' entries are gone.
What is really odd is that the ICMP portion of the packet shows the correct response frame packet reference so it looks like the packets know about but it is just Wireshark that is misinterpreting the results.
I'm going to try and grab an older version and see if it still happens. Currently running version 1.12.4 on Server 2012 R2. (Full version is 1.12.4-0-gb4861da from master-1.12)
EDIT: I can confirm that this behaviour exists in v12.5 now. Testing version 1.10.14 now. Doesn't appear to be exhibiting the same behaviour. I'll update this post if anything changes.
I think the issue with live capture may be a 1-pass\2-pass issue.
With a live capture, when the request is initially dissected, obviously no reply has been received yet so the info column defaults to "no response found".
When the reply is received and dissected the conversation tracking in the icmp dissector connects the request and the reply.
When the packets are re-dissected on the second pass, the request info column can be updated as the conversation includes the reply packet.
When opening an existing capture file, 2 passes are done which ensures the request info column is correct.
I'm not so sure what happens with a live capture, from the evidence it does seem as though some form of 2nd pass takes place but I'm not sure how or why. In my tests I get ~25% of requests with the "no reply found" info column, even with ping times of 4mS.
Crud. v1.10.14 shows the same sort of behaviour on our test server.
However we did not see the ping -f -l 1000 {target} issue in v1.10.14. Packets were delivered without issue