preface

In a word, Google DNS 8.8.8.8 will truncate the packet length of Ping response, and there will be different results on the system, but Wireshark packet capture results will show that Ping is not responding.
​

163 example

Start with www.163 Com as an example, Windows defaults to Ping, and the data length is 32.

$ ping www.163.com

Is Ping z163picipv6.v.bsgslb.cn [180.97.232.124] Data with 32 bytes:
From 180.97.232.124 Reply from: byte=32 time=8ms TTL=53
 From 180.97.232.124 Reply from: byte=32 time=8ms TTL=53
 From 180.97.232.124 Reply from: byte=32 time=8ms TTL=53
 From 180.97.232.124 Reply from: byte=32 time=8ms TTL=53

180.97.232.124 of Ping statistical information :
    data packet: has been sent = 4，Received = 4，lose = 0 (0% lose)，
Estimated round trip time(In Milliseconds ):
    minimum = 8ms，Longest = 8ms，average = 8ms
    

​
The data length of Windows Ping is 1472. The packet capturing result shows 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

Is Ping z163picipv6.v.bsgslb.cn [180.97.232.124] Data with 1472 bytes:
From 180.97.232.124 Reply from: byte=1472 time=9ms TTL=53
 From 180.97.232.124 Reply from: byte=1472 time=9ms TTL=53
 From 180.97.232.124 Reply from: byte=1472 time=8ms TTL=53

180.97.232.124 of Ping statistical information :
    data packet: has been sent = 3，Received = 3，lose = 0 (0% lose)，
Estimated round trip time(In Milliseconds ):
    minimum = 8ms，Longest = 9ms，average = 8ms
    

The length of Windows Ping bytes is 1473. Because it exceeds the maximum MTU, IP fragmentation occurs, but the Ping result is still normal.

$ ping -l 1473 www.163.com

Is Ping z163picipv6.v.bsgslb.cn [180.97.232.125] Data with 1473 bytes:
From 180.97.232.125 Reply from: byte=1473 time=7ms TTL=53
 From 180.97.232.125 Reply from: byte=1473 time=7ms TTL=53
 From 180.97.232.125 Reply from: byte=1473 time=7ms TTL=53

180.97.232.125 of Ping statistical information :
    data packet: has been sent = 3，Received = 3，lose = 0 (0% lose)，
Estimated round trip time(In Milliseconds ):
    minimum = 7ms，Longest = 7ms，average = 7ms

You can see that three packets of Ping request are divided into six packets. Similarly, three packets of reply are also divided into six packets.

Google example

Google DNS 8.8.8.8, Windows default Ping, data length 32.

$ ping 8.8.8.8

Is Ping 8.8.8.8 Data with 32 bytes:
From 8.8.8.8 Reply from: byte=32 time=35ms TTL=114
 From 8.8.8.8 Reply from: byte=32 time=35ms TTL=114
 From 8.8.8.8 Reply from: byte=32 time=36ms TTL=114
 From 8.8.8.8 Reply from: byte=32 time=36ms TTL=114

8.8.8.8 of Ping statistical information :
    data packet: has been sent = 4，Received = 4，lose = 0 (0% lose)，
Estimated round trip time(In Milliseconds ):
    minimum = 35ms，Longest = 36ms，average = 35ms

Google DNS 8.8.8.8, Windows Ping data length 68 and 69. Note the difference. Ping 69 will be displayed as byte = 68 (sent 69) on the system, and the result is still Ping successful.

$ ping -l 68 8.8.8.8

Is Ping 8.8.8.8 Data with 68 bytes:
From 8.8.8.8 Reply from: byte=68 time=65ms TTL=49
 From 8.8.8.8 Reply from: byte=68 time=64ms TTL=49
 From 8.8.8.8 Reply from: byte=68 time=64ms TTL=49

8.8.8.8 of Ping statistical information :
    data packet: has been sent = 3，Received = 3，lose = 0 (0% lose)，
Estimated round trip time(In Milliseconds ):
    minimum = 64ms，Longest = 65ms，average = 64ms



$ ping -l 69 8.8.8.8

Is Ping 8.8.8.8 Data with 69 bytes:
From 8.8.8.8 Reply from: byte=68 (Sent 69) time=64ms TTL=49
 From 8.8.8.8 Reply from: byte=68 (Sent 69) time=64ms TTL=49
 From 8.8.8.8 Reply from: byte=68 (Sent 69) time=64ms TTL=49
 From 8.8.8.8 Reply from: byte=68 (Sent 69) time=64ms TTL=49

8.8.8.8 of Ping statistical information :
    data packet: has been sent = 4，Received = 4，lose = 0 (0% lose)，
Estimated round trip time(In Milliseconds ):
    minimum = 64ms，Longest = 64ms，average = 64ms

​
The actual packet capture results of Wireshark are shown in the figure below

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 whole packet length 110.

Since the definition of Echo or Echo Reply Message in RFC 792 describes the following two points:

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, the RFC will be followed in Wireshark to display no response found! In the Windows system (similar to the macOS system), the judgment logic will think that it is the corresponding group of echo request and echo reply because the id and seq num are the same, and some length data match. Therefore, it will be displayed as Ping success, and a friendly prompt byte = 68 (sent 69).
​

Continue with Google DNS 8.8.8.8 and Windows Ping data lengths 1472 and 1473.

$ ping -l 1472 8.8.8.8

Is Ping 8.8.8.8 Data with 1472 bytes:
From 8.8.8.8 Reply from: byte=68 (1472 sent) time=35ms TTL=114
 From 8.8.8.8 Reply from: byte=68 (1472 sent) time=35ms TTL=114
 From 8.8.8.8 Reply from: byte=68 (1472 sent) time=36ms TTL=114

8.8.8.8 of Ping statistical information :
    data packet: has been sent = 3，Received = 3，lose = 0 (0% lose)，
Estimated round trip time(In Milliseconds ):
    minimum = 35ms，Longest = 36ms，average = 35ms



$ ping -l 1473 8.8.8.8

Is Ping 8.8.8.8 Data with 1473 bytes:
The request timed out.
The request timed out.
The request timed out.

8.8.8.8 of Ping statistical information :
    data packet: has been sent = 3，Received = 0，lose = 3 (100% lose)，

​
The actual packet capture results of Wireshark are shown in the figure below

no response found, But Ping 1472 and 1473 have completely different meanings. 1472 according to the above analysis, because the Echo reply length is truncated, the system still shows that Ping is successful, while 1473 is because it exceeds the maximum MTU, resulting in IP fragmentation. Due to various reasons of Google security protection, the relevant messages are blocked, so there will be no Echo reply message returned, so the real Ping is impossible.

summary

Various strange Ping results, considering different clients, servers, Ping programs and packet capture tools, need to be analyzed in combination with the actual environment.