This is our old Q&A Site. Please post any new questions and answers at

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 (dont fragment) bit is not set, it should fragment the packet and should go through. Also I am assuming ICMP is not disabled otherwise ping should not work. If its MSS issue then why SYN packets for ftp connection handshake shows 9000 as the MSS on both side?


asked 04 Apr '15, 06:36

vondutch9's gravatar image

accept rate: 0%

Can you please upload a capture file (google drive, dropbox, that shows the various ping tests and the TCP connection, and then post the link here?

(06 Apr '15, 03:41) Kurt Knochner ♦

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:

            To avoid the infinite regress of messages about messages
etc., no ICMP messages are sent about ICMP messages.
(06 Apr '15, 06:48) cmaynard ♦♦

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

(07 Apr '15, 02:14) DarrenWright

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.

(07 Apr '15, 02:41) DarrenWright

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.

(19 May '15, 08:52) jbiggley

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.

(19 May '15, 09:20) grahamb ♦

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

(19 May '15, 09:23) jbiggley
showing 5 of 7 show 2 more comments
Be the first one to answer this question!
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here



Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text]( "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:


question asked: 04 Apr '15, 06:36

question was seen: 6,669 times

last updated: 19 May '15, 09:42

p​o​w​e​r​e​d by O​S​Q​A