Sometimes, A ‘TCP Checksum Incorrect’ error was indicated by a client in a trace as the source of a problem, You may have been told that these ‘errors’ could be ignored, Because the task to calculate checksum is done by the NIC. you may have cases in which you need to empirically prove that checksum offloading is the cause of the ‘error’ in the trace, and explain this to the customer.
First, let’s examine what a ‘TCP Checksum Incorrect’ error looks like:
Figure 1: TCP Checksum Incorrect
In this decoding tree view, you can see the issuer. The checksum of each packet ware calculated by Ax3soft Unicorn. If the checksum listed in the captured segment does not equal what it computes as the correct checksum, it will generate a event to notify you. If this checksum is truly incorrect, the packet is discarded by the receiving system at the Transport layer, according to Standard 7.
However, these ‘errors’ will not be errors at all in the vast majority of the cases. If the network card is capable of calculating the TCP checksum in hardware and User select the “Rx & Tx Enabled” option to enables the adapter port to compute the checksum of transmitting IPv4 packets and verify the checksum of receiving IPv4 packets, taking load off from the CPU. This means that the checksum sent from the OS to the NIC driver is necessarily incorrect, as the OS is not processing the checksum. Please see figure below.
Figure 1: Rx & Tx Enabled
Since protocol analyzers hook in above the network card driver, they are only capable of capturing data sent to the driver (from the source system) and received from the driver (on the destination system). For this reason, if checksum offloading is implemented on the source system, all TCP segments sent from that system will show up with this ‘TCP Checksum Incorrect’ error on traces taken from that system.
You again may be asked to prove empirically that this is the case. One method of doing this would be to simply disable offloading and take a new trace. However, this may reduce system performance somewhat and is a bit intrusive. Another method would be to take simultaneous traces from the problem system and another system while they are involved in TCP communications. Find out these frames are matched as being the same by the sequence and acknowledgement numbers. You will also note that the local side is incorrect while the remote side received a correct checksum. This proves that the remote system received a correct checksum, which means the NIC sent the correct checksum, regardless of what the traces from the source side show.