Interesting Traces - Bogus checksum errors

This trace was taken by Network Monitor on a Microsoft Windows Server 2003 Enterprise Edition with Service Pack 1. In the detail frame you can see that the IP checksum is 0 and the TCP checksum while not 0 is incorrect. In the interest of space I am not showing the other frames sent by the system but all of them show the same pattern, both IP and TCP chechsums are incorrect.

What makes the trace so interesting? The bytes transmitted in packets with IP and TCP checksum errors are all acknowledged. In the summary window you can see that frame 397 ACKs the bytes in frames 395 and 396, frame 399 ACKs the bytes in frame 398, and frame 402 ACKs the bytes in frames 400 and 401.

So what is going on? How can packets with errors have bytes that are acknowledged? IP and TCP checksuming has been offloaded to the Ethernet card. Since the checksums aren't calculated until the card transmits the packet any host based analyzer will show the checksums as incorrect. A network based analyzer or an analyzer on the target system would show the correct checksums.

This figure is an Ethereal trace taken on the other host. Paranoia forces me to block out the IP address. It shows frame 395 from the above Network Monitor trace. We know its the same frame because the IP Identification field matches (0x5CED) and the sequence number matches (0xF587EFD2), we have to look at the hex dump of the packet because Ethereal shows only a relative sequence number in its detail window. Note that it shows the IP and TCP checksums with correct values.

This page was last modified on 06-08-08

Send comments and suggestions
to ndav1@cox.net