 | 1 | initial version |
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.