31

I find too many incorrect checksum errors from a TCPDUMP done on a GNU Linux 64bit server. There are close to 50% incorrect chekcsums in the export?

cksum 0xe61f (incorrect (-> 0x8c37)

How can we interpret this data? Does it affect performance a lot?

Vishal
  • 415
  • 1
  • 4
  • 6

1 Answers1

43

You see the "incorrect" checksums due to a feature called TCP checksum offloading. The checksum fields for outgoing TCP packets are not pre-calculated by the operating system but instead set to 0 and left for calculation by the NIC processor. The Wireshark FAQ has a more detailed explanation.

Community
  • 1
the-wabbit
  • 40,319
  • 13
  • 105
  • 169
  • I saw that but it was specific to "If the packets that have incorrect TCP checksums are all being sent by the machine on which Wireshark is running" and it was not clear how too many legitimate checksum fails would impact network performance. – Vishal Jul 08 '11 at 22:48
  • 7
    You should only see incorrect checksums on packets sent by your machine. This is not specific to Wireshark, any packet capture software working at this level will produce similar results. If you see checksum fails on received packets, there might be a problem indeed - these packets are discarded by the TCP stack and trigger a retransmission as well as congestion control algorithms - which will have a direct impact on data throughput. – the-wabbit Jul 08 '11 at 23:02
  • The checksum errors were only on the sent packets. Thanks! – Vishal Jul 08 '11 at 23:34
  • I see incorrect checksums on large incoming SMB packets that need to be re-assembled. `tcpdump` prints a first packet with "incorrect checksum" along with the comment "WARNING: Packet is continued in later TCP segments". Then there are few more with "incorrect checksum" followed by a comment ""SMB-over-TCP packet:(raw data or continuation?)". I suppose the checksum in the first packet of the set will be correct if all the subsequent packets (which actually have no checksum at the place where `tcpdump` is grabbing the checksum value) have been reassembled into their whole ≤ 64KiB whole. – David Tonhofer Jan 08 '16 at 16:52