Ask Your Question

No Response found on ICMP Request

asked 2020-02-09 13:12:57 +0000

rokit gravatar image

Hello everytime I type the Command in the CMD-prompt ping -l "X"

X= Above 68

I Receive a "No Response found" message from Wireshark.

When the Datalength is 68 or under 68 I dont get these messages.

Could you tell me why this happen ?

edit retag flag offensive close merge delete


Can you paste the output of Help->About Wireshark here.

Chuckc gravatar imageChuckc ( 2020-02-09 14:56:26 +0000 )edit

I cant Upload Data because I dont have enough Points.

rokit gravatar imagerokit ( 2020-02-09 15:38:47 +0000 )edit

3 Answers

Sort by ยป oldest newest most voted

answered 2020-02-09 14:12:54 +0000

grahamb gravatar image

Testing locally with a dev build of Wireshark I see the same. The target only returns 68 bytes of data and I think the ICMP dissector is not matching up the responses with the request due to the size difference.

I can't see anything about this in bugzilla, please raise an issue there and attach a capture showing the problem.

edit flag offensive delete link more

answered 2020-02-09 15:17:43 +0000

Jaap gravatar image

updated 2020-02-09 15:23:14 +0000

Hmm, RFC 792 says on page 15: "The data received in the echo message must be returned in the echo reply message". If not, the checksum will be different, which is part of the key to match the ICMP echo requests and responses.

If there's a valid reason to limit the payload size (e.g. anti DDOS), it may be needed to tweak the PDU matching code.

edit flag offensive delete link more


It looks as though the key for matching transactions (beyond the basic conversation) consists of: (1) the IP checksum (2) ID & sequence number (i.e. next 2 16-bit fields) (3) possible VLAN Id

But this part of packet-icmp.c could be a lot clearer.

martinMath gravatar imagemartinMath ( 2020-02-09 17:34:55 +0000 )edit

I'm also not sure about the dissector displaying both big-endian and little -endian values for ID and sequence number. Is there an actual need to display both? I can't see anything in the RFC or subsequent updates that shows the byte order for these fields.

grahamb gravatar imagegrahamb ( 2020-02-09 17:43:56 +0000 )edit

This question discusses the reason for both BE and LE representations.

grahamb gravatar imagegrahamb ( 2020-02-09 17:45:59 +0000 )edit
There has been some recent work on the checksum check.
Perhaps add a preference to ignore checksum then match on basic IP info, ICMP ID and ICMP Seq.

Chuckc gravatar imageChuckc ( 2020-02-09 20:15:53 +0000 )edit

answered 2020-02-10 01:37:46 +0000

Jim Young gravatar image

Google's DNS server's truncate a ping reply to a maximum payload of 68 bytes regardless of the size of the request.

On a windows system if you initiate a ping to with a length value greater than 68 (e.g. 69), Microsoft's ping will indicate that the ping is successful, but Wireshark's analysis reports "no response found!".

C:\>ping -l 69

Pinging with 69 bytes of data:
Reply from bytes=68 (sent 69) time=26ms TTL=54
Reply from bytes=68 (sent 69) time=13ms TTL=54
Reply from bytes=68 (sent 69) time=12ms TTL=54
Reply from bytes=68 (sent 69) time=23ms TTL=54

Ping statistics for
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 12ms, Maximum = 26ms, Average = 18ms


But there's a subtle addition to the Microsoft's ping Reply report. Note that it indicates "bytes=68 (sent 69)".

On a macOS system a ping to with a length of 69 also indicates a reply was received but in this case an second line follows each reply message reporting "wrong total length 96 instead of 97".

$ ping -c 4 -s 69
PING ( 69 data bytes
76 bytes from icmp_seq=0 ttl=54 time=18.353 ms
wrong total length 96 instead of 97
76 bytes from icmp_seq=1 ttl=54 time=18.038 ms
wrong total length 96 instead of 97
76 bytes from icmp_seq=2 ttl=54 time=15.280 ms
wrong total length 96 instead of 97
76 bytes from icmp_seq=3 ttl=54 time=22.787 ms
wrong total length 96 instead of 97

--- ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 15.280/18.614/22.787/2.689 ms

Pinging other commonly accessible sites, for example two open DNS server addresses of and, does not appear to have this reply size downgrade behavior.

There's a few things to consider here:

The servers only reply with the first 68 octets of the ping request's payload for lengths greater than 68, is this in fact a successful ping? Perhaps.

Could Wireshark's ping analysis be enhanced to report on the reply as successful but we have a length discrepancy? Perhaps.

edit flag offensive delete link more


No. It works just as @Jaap stated. The checksums are expected to match, but they don't. When matching requests to replies, I took the approach of trying to make the heuristics as strong as possible to avoid accidentally matching replies to the wrong request, but of course when the RFC's aren't followed, things like this are the result.

Some possible solutions:

  • Don't change anything since the response payload doesn't match the request payload, a violation of the RFC.
  • Ignore the checksum in the request/response matching.
  • Ignore the checksum in the request/response matching, but only for packets of a particular size (such as 68 bytes). I suppose that value could even be made configurable as an ICMP option, if needed or desired for more flexibility.
  • Compromise and add an ICMP option to relax the checksum match requirement, but I'd recommend adding an expert ...
cmaynard gravatar imagecmaynard ( 2020-02-10 02:20:00 +0000 )edit

You are correct Chris, Wireshark does indeed work as Jaap stated.

Would a Wireshark user be better served with enhanced ICMP reply matching code here? I'm not really convinced anything needs to change. But more than once I have had to personally explain that Wireshark was not technically wrong in this exact case.

If a change is made to match truncated ICMP echo replies to their full size requests, then the Info column should be augmented and/or an expert info generated to indicate that less bytes than the requested number of bytes was received to make it obvious that this reply is not technically correct in the sense of RFC 792.

Jim Young gravatar imageJim Young ( 2020-02-10 03:54:56 +0000 )edit

Would a Wireshark user be better served with enhanced ICMP reply matching code here?

Yes, probably so. While technically not the expected response, the user is probably just mainly concerned about connectivity. Can I reach a host and can the host reach me? And what is the round-trip delay in reaching that host? So to be more flexible, one of bullets 2, 3 or 4 I mentioned above should probably be considered.

cmaynard gravatar imagecmaynard ( 2020-02-10 15:16:48 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2020-02-09 13:12:57 +0000

Seen: 33,016 times

Last updated: Feb 10 '20