1

We are currently investigating a strange behavior of different devices: if we send "empty" ICMP packets (that is, ICMP-SEQ and ICMP-ID are 0x0000 and no ICMP payload), for example using

nping --icmp --icmp-seq=0 --icmp-id=0 8.8.8.8

then different systems reply differently:

  • an Asus router, Windows 7 PC, Fritz!Box, Kali Linux box, all reply with checksum 0xFFFF, which is correct according to wireshark
  • However, 8.8.8.8 and heise.de (193.99.144.80) both reply with 0x0000, which is marked as wrong by wireshark.

I am pretty sure that I have also seen 0xFFFF from 8.8.8.8, but I currently can't reproduce this.

SO, my Questions:

  • What's the correct Internet Checksum for a packet consisting only of Zeros
  • Is this behavior different if the packed is relayed via NAT (i.e. relayed through our router)?

Note: This ICMP packet is valid according to RFC 792

PS: I hope serverfault is the correct forum to ask. If not, I apologize in advance ;)

  • I can confirm this issue is still alive and well in 2018, the output on my mac shows invalid checksum responses from google.com with the OP's same command. `wrong icmp cksum 0 (->ffff)!`. I think this comes down to how the checksum is calculated on the remote host versus the machine that sent the request. – ocket8888 Jan 23 '18 at 21:27

1 Answers1

0

After digging around with tcpdump, nping and nmap for about three hours, I've managed to determine the following: Windows calculates the checksum properly, and basically nobody else does. When you have a packet that's all 0's, you should get a checksum of 0xffff (source), but every linux/BSD machine I've pinged has returned a checksum of 0x0000. I think this just comes down to an error in how the checksum is being calculated on many servers.

ocket8888
  • 101
  • 2
  • I'm not putting this in my answer because I'm not sure about it, but I think the reason *nix reports the sum incorrectly is because a number of exploits have historically used checksum manipulation with icmp requests having an id of 0. – ocket8888 Jan 24 '18 at 17:22