Hello everytime I type the Command in the CMD-prompt ping 8.8.8.8 -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 ?
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.
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.
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.
https://bugs.wireshark.org/bugzilla/s...
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.
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.
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 8.8.8.8 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 8.8.8.8
Pinging 8.8.8.8 with 69 bytes of data:
Reply from 8.8.8.8: bytes=68 (sent 69) time=26ms TTL=54
Reply from 8.8.8.8: bytes=68 (sent 69) time=13ms TTL=54
Reply from 8.8.8.8: bytes=68 (sent 69) time=12ms TTL=54
Reply from 8.8.8.8: bytes=68 (sent 69) time=23ms TTL=54
Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 12ms, Maximum = 26ms, Average = 18ms
C:\>
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 8.8.8.8 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 8.8.8.8 PING 8.8.8.8 (8.8.8.8): 69 data bytes 76 bytes from 8.8.8.8: icmp_seq=0 ttl=54 time=18.353 ms wrong total length 96 instead of 97 76 bytes from 8.8.8.8: icmp_seq=1 ttl=54 time=18.038 ms wrong total length 96 instead of 97 76 bytes from 8.8.8.8: icmp_seq=2 ttl=54 time=15.280 ms wrong total length 96 instead of 97 76 bytes from 8.8.8.8: icmp_seq=3 ttl=54 time=22.787 ms wrong total length 96 instead of 97 --- 8.8.8.8 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 1.1.1.1 and 9.9.9.9, does not appear to have this reply size downgrade behavior.
There's a few things to consider here:
The 8.8.8.8 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.
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:
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.
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.
Comments
Can you paste the output of Help->About Wireshark here.
I cant Upload Data because I dont have enough Points.