This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

checksum errors when browsing the internet

0

Any ideas on what is causing all these header checksum errors... A few times a day users intermittently lose network connections to the exchange server or the internet. Upon opening IE I start to see checksum errors like the following and they stop when closing IE...

Header checksum: 0x0000 [incorrect, should be 0x54ad (maybe caused by "IP checksum offload"?)]

This is a sample of the packet traffic that get the checksum error:

20  4.223408    192.168.0.102   192.168.0.6 DNS 76  Standard query A search.yahoo.com
87  17.876965   192.168.0.102   192.168.0.6 DNS 73  Standard query A www.yahoo.com
91  17.892743   192.168.0.102   209.191.122.70  TCP 66  50355 > http [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1
93  17.893526   192.168.0.102   209.191.122.70  TCP 54  50355 > http [ACK] Seq=1 Ack=1 Win=65700 Len=0
126 20.883091   192.168.0.102   209.191.122.70  TCP 54  50356 > http [ACK] Seq=1 Ack=1 Win=65700 Len=0
127 20.883608   192.168.0.102   209.191.122.70  HTTP    297 GET / HTTP/1.1 
2811    41.858393   192.168.0.102   184.51.200.194  TCP 54  50455 > http [RST, ACK] Seq=407 Ack=1 Win=0 Len=0
2812    41.858718   192.168.0.102   184.51.200.40   TCP 54  50452 > http [RST, ACK] Seq=427 Ack=1 Win=0 Len=0
3426    49.442890   192.168.0.102   216.115.96.174  TCP 54  50422 > http [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
3427    49.550803   192.168.0.102   216.115.110.118 TCP 54  50388 > http [RST, ACK] Seq=1 Ack=1 Win=0 Len=0

Thanks, Dave

asked 05 Jun '12, 13:08

Dave's gravatar image

Dave
1111
accept rate: 0%

edited 05 Jun '12, 13:19

grahamb's gravatar image

grahamb ♦
19.8k330206


2 Answers:

1

As the error message suggests, IP checksum offload is enabled. This means that the computer’s TCP/IP stack does not calculate the checksum. Instead, it passes the packet to the NIC and the NIC driver calculates the checksum and adds it to the packet before the packet is transmitted on the wire. Wireshark sees the packet before the checksum has been added. When the packet is transmitted on the wire, the checksum is correct.

One clue that checksum offload is involved is that the packets with the errors don’t get retransmitted. If the checksum really was wrong, either the packets would be retransmitted, or the communication would fail.

This can be considered a cosmetic error. You can ignore it, or you can make it go away by turning off checksum offloading in the NIC properties, or disabling IP checksum validation in Wireshark’s properties.

To see the actual transmitted packet with the correct checksum, capture the traffic from a third PC that is not involved in the communication using a hub or a port mirroring switch, instead of capturing on one of the end points.

answered 05 Jun '12, 13:22

Jim%20Aragon's gravatar image

Jim Aragon
7.2k733118
accept rate: 24%

edited 05 Jun '12, 16:19

cmaynard's gravatar image

cmaynard ♦♦
9.4k1038142

1

The clue is in the error message: [maybe caused by "IP checksum offload"?)].

Your NIC (or NIC driver) is calculating IP checksums so the stack doesn't bother, and at the point that the capture mechanism gets hold of the packet the checksum is garbage.

You should see that the errors are only reported for outgoing packets from your machine, incoming packets will have the correct checksum.

You can remove the errors by checking the "Support packet-capture from IP TSO-enabled hardware" option in the IP dissectors preferences.

If there were actual errors in the checksums it's extremely unlikely that you would see the packets when capturing on a regular NIC as the packets would be discarded.

answered 05 Jun '12, 13:27

grahamb's gravatar image

grahamb ♦
19.8k330206
accept rate: 22%