Google pings corrupts

RouterOS General
1

Hi,

Not strictly a Mikrotik related question, but just want to see if you guys get the same. This started recently, can’t ping any Google services with packets bigger than 92, if I do, packets gets corrupted. I get this from 2 locations which has nothing in common except using Mikrotik routers, different ISPs, etc
Sniffer reports “no respond found”.

Is this by design, security reasons?? Or is there a problem?

> ping 8.8.8.8 do-not-fragment size=100 count=3
SEQ HOST SIZE TTL TIME STATUS
0 8.8.8.8 92 56 5ms (corrupted)
1 8.8.8.8 92 56 5ms (corrupted)
2 8.8.8.8 92 56 5ms (corrupted)
sent=3 received=3 packet-loss=0% min-rtt=5ms avg-rtt=5ms max-rtt=5ms

> ping www.google.com do-not-fragment size=100 count=3
SEQ HOST SIZE TTL TIME STATUS
0 172.217.170.36 92 56 5ms (corrupted)
1 172.217.170.36 92 56 4ms (corrupted)
2 172.217.170.36 92 56 4ms (corrupted)
sent=3 received=3 packet-loss=0% min-rtt=4ms avg-rtt=4ms max-rtt=5ms

> ping www.microsoft.com do-not-fragment size=100 count=3
SEQ HOST SIZE TTL TIME STATUS
0 2.23.106.83 100 51 189ms
1 2.23.106.83 100 51 187ms
2 2.23.106.83 100 51 187ms
sent=3 received=3 packet-loss=0% min-rtt=187ms avg-rtt=187ms max-rtt=189ms

2

Ping from a linux host, completely unrelated to MT products (basically a Cisco-infested network), shows wicked game as well:

$ ping -s 100 -M do 8.8.8.8 -c 10
PING 8.8.8.8 (8.8.8.8) 100(128) bytes of data.
72 bytes from 8.8.8.8: icmp_seq=1 ttl=42 (truncated)
72 bytes from 8.8.8.8: icmp_seq=2 ttl=42 (truncated)
72 bytes from 8.8.8.8: icmp_seq=3 ttl=42 (truncated)
72 bytes from 8.8.8.8: icmp_seq=4 ttl=42 (truncated)
72 bytes from 8.8.8.8: icmp_seq=5 ttl=42 (truncated)
72 bytes from 8.8.8.8: icmp_seq=6 ttl=42 (truncated)
72 bytes from 8.8.8.8: icmp_seq=7 ttl=42 (truncated)
72 bytes from 8.8.8.8: icmp_seq=8 ttl=42 (truncated)
72 bytes from 8.8.8.8: icmp_seq=9 ttl=42 (truncated)
72 bytes from 8.8.8.8: icmp_seq=10 ttl=42 (truncated)

--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9010ms
rtt min/avg/max/mdev = 50.932/53.282/59.167/2.612 ms

wireshark dump also shows “no response found” while in reality responses do come back, but truncated as ping correctly informs. Truncation is not a result of some internet wrong-doing as the ICMP checksum of truncated echo reply packets is correct.

Could be some cunning scheme by google to save on bandwidth by sending back short replies to all those using ICMP echo requests longer than (sensible) default size. The echo replies are truncated to 56 bytes (net payload without ICMP headers) regardless the size of original packet (if it’s larger than 56 bytes net).