skip to content

On a Linux server, `tcpdump -v` marks outgoing TCP checksums incorrect and shows 28,960-byte segments on a 1500-byte MTU link; is traffic being corrupted?

level: seniorimportance: should knowfreq 12%

answer

  1. where the capture tap sits
  2. only the host's own sends
  3. the NIC finishes the job
  4. superpackets in both directions

basics

~20 s

Almost certainly not. tcpdump sees outgoing packets before the NIC fills in checksums or splits large buffers, so checksum offload and segmentation offload produce exactly these lines. Receive offload likewise merges inbound segments before the capture.

solid answer

~50 s

These are capture-point artefacts of NIC offloads. tcpdump checks TCP checksums only with `-v`, printing `cksum 0x... (incorrect -> 0x...)` when they fail; on the sending host the packet is captured before the hardware computes the real checksum, which is why the tcpdump manual says outgoing TCP checksums will be flagged as bad on such interfaces and offers `-K` (`--dont-verify-checksums`). Segments far above the MTU come from **segmentation offload** — the kernel hands the NIC one large buffer that the hardware cuts into MTU-sized packets after the tap — and, on the receiving side, from **receive offload** merging consecutive segments before the stack sees them. With `-v` the IP header may even show `[was 0, presumed TSO]`. The evidence that settles it: the bad checksums are only on this host's own sends, its received packets check correctly, and a capture taken beyond the NIC shows normal-sized packets with valid checksums.

go deeper

for a junior

Recall that incorrect checksums on a host's own outgoing packets are a well-known capture artefact and that tcpdump checks checksums only with -v.

for a middle

Explain where the capture tap sits relative to the NIC and how checksum and segmentation offload produce the flagged and oversized lines.

for a senior

Separate artefact from corruption with evidence — direction of the bad packets, the peer's capture, a mirror port — before anyone touches hardware or offload settings.

for a principal

Weigh the CPU cost of disabling offloads against capture fidelity, and prefer capture points beyond the NIC for evidence that must stand up in a review.

## What the capture shows Run on a server that is sending a large response, `tcpdump -v -n` might print: ``` IP (tos 0x0, ttl 64, id 40112, offset 0, flags [DF], proto TCP (6), length 29012) 198.51.100.20.443 > 192.0.2.10.51514: Flags [.], cksum 0x2f1c (incorrect -> 0x8a41), seq 1:28961, ack 518, win 506, options [nop,nop,TS val 1033404840 ecr 3196613511], length 28960 ``` Two things look alarming: a checksum tcpdump calls **incorrect**, and a 28,960-byte TCP payload on a link whose MTU is 1500. Neither proves anything is wrong on the wire. ## Where the tap sits tcpdump receives a copy of each outgoing packet from the operating system **before** it is handed to the network card. Modern NICs and drivers take over work the stack used to do: | Offload | What the hardware or driver does | What tcpdump sees on the capturing host | |---|---|---| | **Checksum offload** | computes the TCP checksum while transmitting | an empty or partial checksum, flagged incorrect | | **Segmentation offload (TSO / GSO)** | splits one large buffer into MTU-sized segments | one segment far larger than the MTU | | **Receive offload (GRO)** | merges consecutive received segments into one | inbound segments far larger than the MTU | For checksums the effect is well documented: packets being transmitted are captured before the hardware fills the checksum in, so they display as invalid while carrying valid checksums on the wire. On Linux the stack often places a partial sum covering the pseudo-header in the field, which still fails a full check. ## How tcpdump reports it - **Checksums are checked only with `-v`.** Without it, no `cksum` text appears at all, so a capture without `-v` neither shows nor rules out the artefact. - **The format is** `cksum 0xNNNN (incorrect -> 0xMMMM)` — the value in the header, then the one tcpdump computed — or `(correct)`. - **`-K` / `--dont-verify-checksums`** stops the check; the tcpdump manual recommends it for interfaces that compute checksums in hardware, "otherwise, all outgoing TCP checksums will be flagged as bad". - **Oversized IP packets** may be printed in the `-v` IP header as `length N [was 0, presumed TSO]` when the IP total-length field was left at zero for the hardware to fill, or `[was 0, presumed BIG TCP]` above 65,535 bytes in tcpdump 4.99.7. - **`length 28960`** at the end of the TCP part is the payload size — here exactly twenty 1,448-byte segments, a strong hint that it is a superpacket built from MSS-sized pieces. ## The receiving side looks similar On the host receiving that response, receive offload can merge several consecutive segments before the stack and the capture see them. tcpdump there may print inbound `[.]` segments with `length 14480` or more, even though the sender's NIC put ten separate MTU-sized packets on the wire. The oversized length is again a statement about the capture point, not about the network: the merge happened inside the receiving host, after the packets had already crossed the link. Coalesced inbound segments are also a case where a checksum tcpdump flags on received traffic can be an artefact rather than a real error, so check their size before suspecting the path. ## Deciding: artefact or real corruption 1. **Check direction.** If only the capturing host's own outgoing packets are flagged, offload is the likely explanation. Received packets have crossed a NIC and should normally verify. 2. **Check the peer.** Captured on the receiving host, or anywhere past the sender's NIC, the same data should appear as MTU-sized packets with correct checksums — unless the receiver's own receive offload merges them again. 3. **Capture beyond the NIC when it matters.** A mirrored switch port or a tap sees what really crossed the wire; delivering packets there is a capture-infrastructure topic. 4. **Turn offloads off only briefly.** Disabling them in the NIC driver settings gives an exact view on the host but moves the work back onto the CPU, so do it for the test, not permanently. ## Why interviewers ask The question separates people who have read captures on real servers from those who have only read textbook ones. A strong answer names the mechanism, says which side of the capture point each conclusion is about, and asks for one piece of evidence — the peer's view or the direction of the flagged packets — before anyone opens a hardware ticket.

  • Would running tcpdump with -K fix the problem?
    -K (`--dont-verify-checksums`) only stops tcpdump from computing and printing the checksum verdict; the packets are unchanged. It is reasonable once offload is established as the cause, but it also hides a genuinely bad checksum on inbound traffic, so do not start an investigation with it.
  • How do you show that the segments really on the wire are MTU-sized?
    Capture somewhere past the sending NIC and before any receive offload: a mirrored switch port or a tap, or a host with its receive offload turned off. Packets there show normal lengths and correct checksums, which proves the large, badly-checksummed segments existed only at the sender's capture point.

saying these in an interview costs you the question

  • Incorrect checksums on the host's own outgoing packets prove the NIC is faulty.
  • A segment longer than the MTU in tcpdump means jumbo frames are on the wire.
  • -K makes the NIC calculate checksums correctly.
  • tcpdump verifies TCP checksums on every line, even without -v.
  • Disable all offloads permanently so captures are always accurate.