Checksum offload
A bad checksum on packets the capturing host sent is usually the NIC filling in the checksum later. Confirm the direction before you report corruption.
The bytes left the stack unfinished
Many stacks hand TCP and UDP to the NIC with the checksum unfilled. The NIC writes the real checksum as the frame goes on the wire. A capture taken on that sending host records the frame before the NIC’s edit, so the checksum in the file is zero or partial. Wireshark can mark it bad if checksum validation is turned on.
Validation is off by default for this reason. Turn it on only when you are looking for a checksum question, then read the result with the capture point in mind. A partial checksum on traffic the capture host itself sent is the ordinary offload pattern. The field to notice is the checksum status, and the expert text that mentions offload.
Outbound looks bad, inbound looks fine
The pattern that confirms offload is directional. Frames sourced by the capture host show bad or partial checksums. Frames arriving from other hosts show good checksums, because those checksums were finished before they reached this NIC. Corruption on the wire does not line up that neatly with “everything I sent.”
A mirror of a link records frames after the sending NIC has filled the checksum. Widespread bad checksums on a mirror are a different note. Check the mirror NIC’s own offload and the capture filter before you file a network fault. One direction bad, on a host capture of that same direction, is offload until proven otherwise.
Worked case: the lab client “failed” only its own sends
You enable TCP checksum validation on a capture taken on 10.8.0.40. Every TCP segment the client sends is marked bad. Every segment from 10.8.0.20 is marked good. The conversations complete, including a file copy that the application accepted. The pattern matches offload on the client NIC. You turn validation off again so the colors stop shouting.
The note says “checksum validation on a host capture; outbound partial, inbound good; consistent with offload; application transfer succeeded.” You do not open a ticket that the lab switch is corrupting frames. If a future mirror capture shows bad checksums in both directions on frames that already traversed the wire, that note would be different, and it would name the mirror.
tcp.checksum.partial && ip.src == 10.8.0.40
Put the preference back
The validation toggle is a protocol preference. It lives in the profile. A teammate with validation off will not see your red checksums, and a teammate who inherited your profile will see them and may misread them. Say whether validation was on.
IP checksum offload behaves the same way. If both IP and TCP look bad only on the capture host’s sends, you have one explanation, not two faults.
Diagram
A bad checksum that follows the capture host, and one that does not
- Preference
If validation is off, a checksum question is not being asked yet.
- Direction
Compare frames the capture host sent with frames it received.
- Offload
Outbound partial, inbound good, on a host capture: the NIC finished the sum later.
tcp.checksum.partial && ip.src == 10.8.0.40
- Note
Write the capture point and the direction. Turn the preference back off when you are done.
Where the frame was copied into the file
Outbound. Checksum often partial. The NIC fills it on the way out.
Inbound. Checksum already valid. The peer’s NIC did its job earlier.
Claim. Offload, if the application transfer still succeeded.
Both ways. Checksums should already be filled.
Bad sums. Check the mirror path before you blame the endpoints.
Claim. Name the mirror. Do not copy the host-capture explanation blindly.
Check yourself
1. On a capture taken on 10.8.0.40, only segments sourced by 10.8.0.40 show a bad TCP checksum. The copy still completes. What is the likely cause?
2. Why does Wireshark leave TCP checksum validation off unless you enable it?
3. A mirror capture shows bad checksums in both directions on frames that crossed the wire. Why is the host-offload story weaker here?