Introduction to Google DNS Ping Response Truncation
Google DNS Ping response truncation occurs when Google DNS 8.8.8.8 reduces the length of the Ping response data packet, leading to different outcomes across systems. While the Windows system may display a successful Ping, Wireshark’s packet capture often shows no response because the Echo reply data length doesn’t match the Echo request length, in line with RFC 792 guidelines. This discrepancy can complicate network troubleshooting, making it essential to understand the impact of Ping response truncation and accurately analyze network issues using packet capture tools.
163 Examples
First, go to http://www.163.comFor example, Windows defaults to Ping, and the data length is 32.
$ ping www.163.com
Pinging z163picipv6.v.bsgslb.cn [180.97.232.124] with 32 bytes of data:
Reply from 180.97.232.124: bytes=32 time=8ms TTL=53
Reply from 180.97.232.124: bytes=32 time=8ms TTL=53
Reply from 180.97.232.124: bytes=32 time=8ms TTL=53
Reply from 180.97.232.124: bytes=32 time=8ms TTL=53
Ping statistics for 180.97.232.124:
Packets: Sent = 4, Received = 4, Lost = 0 (0% lost),
Estimated round trip time (in milliseconds):
Minimum = 8ms, Maximum = 8ms, Average = 8ms
The Windows Ping data length is 1472, and the packet capture results show that the total length is 1514, ETH 14 + IP 20 + ICMP 1480 (8+1472) = 1514, which just meets the MTU 1500 .
$ ping -l 1472 www.163.com
Pinging z163picipv6.v.bsgslb.cn [180.97.232.124] with 1472 bytes of data:
Reply from 180.97.232.124: bytes=1472 time=9ms TTL=53
Reply from 180.97.232.124: bytes=1472 time=9ms TTL=53
Reply from 180.97.232.124: bytes=1472 time=8ms TTL=53
Ping statistics for 180.97.232.124:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Estimated round trip time in milliseconds:
Minimum = 8ms, Maximum = 9ms, Average = 8ms
The byte length of Windows Ping is 1473. Because it exceeds the maximum MTU, IP fragmentation occurs, but the Ping result is still normal.
$ ping -l 1473 www.163.com
Pinging z163picipv6.v.bsgslb.cn [180.97.232.125] with 1473 bytes of data:
Reply from 180.97.232.125: bytes=1473 time=7ms TTL=53
Reply from 180.97.232.125: bytes=1473 time=7ms TTL=53
Reply from 180.97.232.125: bytes=1473 time=7ms TTL=53
Ping statistics for 180.97.232.125:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Estimated round trip time in milliseconds:
Minimum = 7ms, Maximum = 7ms, Average = 7msWe can see that the ping request consists of 3 packets, which are fragmented into 6 packets. Similarly, the reply consists of 3 packets, which are also fragmented into 6 packets.
Google Example
Google DNS 8.8.8.8, Windows default Ping, data length 32.
$ ping 8.8.8.8
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=35ms TTL=114
Reply from 8.8.8.8: bytes=32 time=35ms TTL=114
Reply from 8.8.8.8: bytes=32 time=36ms TTL=114
Reply from 8.8.8.8: bytes=32 time=36ms TTL=114
Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Estimated round trip time in milliseconds:
Minimum = 35ms, Maximum = 36ms, Average = 35msGoogle DNS 8.8.8.8, Windows Ping data length 68 and 69. Note the difference, Ping 69 will be displayed as Bytes=68 (69 sent) on the system , and the result is still a successful Ping.
$ ping -l 68 8.8.8.8
Pinging 8.8.8.8 with 68 bytes of data:
Reply from 8.8.8.8: bytes=68 time=65ms TTL=49
Reply from 8.8.8.8: bytes=68 time=64ms TTL=49
Reply from 8.8.8.8: bytes=68 time=64ms TTL=49
Ping statistics for 8.8.8.8:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Estimated round trip time in milliseconds:
Minimum = 64ms, Maximum = 65ms, Average = 64ms
$ 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 (69 sent) Time=64ms TTL=49
Reply from 8.8.8.8: Bytes=68 (69 sent) Time=64ms TTL=49
Reply from 8.8.8.8: Bytes=68 (69 sent) Time=64ms TTL=49
Reply from 8.8.8.8: Bytes=68 (69 sent) Time=64ms TTL=49
Reply from 8.8.8.8: Bytes=68 (69 sent) Time=64ms TTL=49
Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Estimated round trip time in milliseconds:
Minimum = 64ms, Maximum = 64ms, Average = 64ms
The actual packet capture result of Wireshark is as follows
The Windows Ping data length is 69, and the ICMP Request packet length is still 111 (14+20+8+69), but Google DNS 8.8.8.8 will truncate the Ping ICMP Reply data length to 68 , making the entire packet length 110. Because the following two points are defined RFC 792in :Echo or Echo Reply Message
The data received in the echo message must be returned in the echo reply message. The identifier and sequence number may be used by the echo sender to aid in matching the replies with the echo requests.
Because the Echo reply data length 68 is inconsistent with the Echo request data length 69, Wireshark will follow RFC and display no response found!the information. However, the judgment logic of the Windows system (macOS system is similar) will be that the id and seq num are the same, and the length of some data matches, so it is considered to be a corresponding group echo request 和 echo reply, so it will be displayed as Ping success and a friendly prompt will be given 字节=68 (已发送 69).
Continuing with Google DNS 8.8.8.8, Windows Ping data lengths are 1472 and 1473.
$ ping -l 1472 8.8.8.8
Pinging 8.8.8.8 with 1472 bytes of data:
Reply from 8.8.8.8: Bytes=68 (1472 sent) Time=35ms TTL=114
Reply from 8.8.8.8: Bytes=68 (1472 sent) Time=35ms TTL=114
Reply from 8.8.8.8: Bytes=68 (1472 sent) Time=36ms TTL=114
Ping statistics for 8.8.8.8:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Estimated round trip time in milliseconds:
Minimum = 35ms, Maximum = 36ms, Average = 35ms
$ ping -l 1473 8.8.8.8
Pinging 8.8.8.8 with 1473 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 8.8.8.8:
Packets: Sent = 3, Received = 0, Lost = 3 (100% loss),The actual packet capture result of Wireshark is as follows
Although they are both no response found!, Ping 1472 and 1473 have completely different meanings. As analyzed above, 1472 is because the Echo reply length is truncated, but the system still shows that the Ping is successful, while 1473 is because the maximum MTU is exceeded, resulting in IP fragmentation. Due to various reasons of Google security protection, the relevant messages are blocked, so no Echo reply message is returned, so it is a real Ping failure.
Summary of Google DNS Ping Truncation Issues
Various strange Ping results, taking into account different clients, servers, Ping programs, packet capture tools, etc., need to be analyzed in detail based on the actual environment.