How does TCP offload NIC cause the TCP checksum to be invalid?

Question

A tcpdump pcap exported and being investigated on another machine with wireshark is showing a lot of invalid TCP checksum messages. This is a known and documented phenomenon when using TCP offload functionality: https://wiki.wireshark.org/TCP_Checksum_Verification

The only thing that is unclear is why the checksum is incorrect?

TCP checksums are calculated over the entire TCP segment with the help of a pseudo header and using the temporary checksum value of all zeros durring the process of checksum calculation (http://www.tcpipguide.com/free/t_TCPChecksumCalculationandtheTCPPseudoHeader-2.htm#Figure_218). The pseaudoheader is then discarded. Where does the difference creep in?

Solution 1

A TCP segment is located in computer RAM. It contains all the fields required for the TCP segment.

When TCP checksum offload is used, this is what happens when transmitting a segment:

The OS fills out every field in the TCP segment in the memory, EXCEPT for the checksum. The checksum field is not computed by the OS, it contains whatever data there was before in that memory location.

Now, packet capture tools like Wireshark capture the contents of this memory location, which contains a TCP segment without a computed checksum.

When the OS sends the segment to the NIC, the NIC hardware then performs the checksum computation, and puts the computed checksum to the particular TCP segment field. This checksum is never seen by the OS or capture tool.

This is the reason why Wireshark reports those errors.

Solution 2

Because, the checksum is being calculated by the NIC, and not by the operating system.

The wiki page you linked to did explain this:

If you capture on a recent Ethernet NIC, you may see many such "checksum errors". This is due to TCP Checksum offloading often being implemented on those NICs and thus, for packets being transmitted by the machine. The checksum will not be calculated until the packet is sent out by the NIC hardware, long long after your capture tool intercepted the packet from the network stack.

Comments

[lorife]

...which means that the host will not fill in the checksum field in the TCP header, and will leave whatever random value happens to be there as a result of the last time that chunk of memory was used. If that packet is being captured by the host transmitting it, the packet contents, with the random value, will be handed to the capture mechanism, and the packet will separately be handed to the NIC, which will make a copy, fill in the TCP checksum field in that copy on the NIC's memory, and transmit it - that copy will not be supplied back to the host to supply to the capture mechanism.

[Mindaugas Bernatavičius]

Sorry, but I cant accept the answer like this. It is just restatement of the question, dear sirs :) @GuyHarris I think where my understanding fails is WHY the TCP checksum is different - is it supposed to be the same if the TCP segment had not changed? Meaning - the same checksum value for the same TCP segment on every hop thoughout the network? So the same on the NIC and then on the OS?

[Michael Hampton]

@MindaugasBernatavičius Huh? This explains exactly why the checksum is invalid in your packet capture. Which is what you asked about. The checksum is valid on the network but you are not capturing the packets on the network!

[Mindaugas Bernatavičius]

@MichaelHampton well, it's not clear for me at all :) TCP checksum is calculated based on data that does not change from hop to hop as I understand ... or does it? Packet comes into the NIC is verified, processing is done, checksum is recalculated again, added to the packet and sent? The only way it could change, as far as my understanding goes is if there are changes in the TCP segment itself? ... If you could write a more detailed answer involving the flow of 1 packet thought the NIC and then to the OS I would really appreciate it.

[lorife]

The key here is that this happens for packets transmitted by the machine doing the capture, not packets received by the machine doing the capture. Those packets don't come into the NIC, they're transmitted by the NIC. For a NIC that doesn't do checksum offloading, the host has to calculate the checksum and put it into the TCP header before handing it to the NIC to transmit; for a NIC that does, the host doesn't bother calculating a checksum, it just hands the un-checksummed packet, and the NIC calculates the checksum, puts it in the header, and transmits the packet...

[lorife]

...and, as the NIC doesn't receive its own transmitted packets, in order to "capture" those packets, the host network software stack hands copies of them to the capture mechanism. If the NIC is doing checksum offloading, the copies handed to the capture mechanism do not have a valid checksum, as the host didn't calculate the checksum and put it into the packet. The packets transmitted by the NIC do have a valid checksum, but that's not what the host transmitting the packet sees in the capture.

[Mindaugas Bernatavičius]

Nice, finally connected for me. The detail that when OS does not calculate the the checksum it simlply fills in random data was crucial.