Investigating TCP Checksum Issues With Wireshark

Protocol analysis is an ever changing art because of 2 significant variables:

Protocols

• Every time an application gets an update it might affect the way it interacts with protocols.

• Operating system upgrades may change the actual protocols or drivers.

• Certain applications might come with its own ‘built in protocols’

Tools

• Every protocol analyzer will have its own different GUI, protocol dissector or decoder and presentation

• Even when you think you got the hang of the tool, that vendor may decide it’s time for an upgrade which may remove, add or break some significant features

In this example I will focus on Wireshark and TCP checksum issues.

Quick review a checksum is calculated and included by the sender of the data. The receiver performs the same math, using the same formula and should get the same checksum value. If this is not the case the receiver ‘may’ decide to discard that packet. I say may because the behavior is based entirely on the vendor and specific protocol in question.

When it comes to TCP I have seen scenarios where a bad driver miscalculates the checksum and the received discarded it. In most cases the receiver will discard the packet if there is a TCP checksum issue.

This is the important bit, if you see TCP checksum errors, take a moment and verify if the corrupted packets have responses, with no retransmissions or large delta times. If that is the case, then the packets are not truly corrupted.

Depending where Wireshark/npcap captured the packet, it is entirely possible that the checksum was not calculated when it was captured. In some cases TCP checksum is enabled on the card which creates the same symptom.

This is yet another reason why I prefer to capture packets after it has left the device.