tcpdump Shows 64KB Packets: Offload and Capture Point

Capturing on a host can show a 64 KB packet on an interface whose MTU is 1420, and the obvious conclusion is that the tunnel ignored its size limit. That conclusion is usually wrong. Host capture points sit inside the processing path, where segmentation, aggregation and checksum work may not have happened yet. Read the position of the observer before reading the packet size.

Where You Capture Changes What You See

Transmit offload lets the stack hand a large unit to the network device, which cuts it into wire-sized pieces later. Receive aggregation does the opposite on the way in, joining segments before a host-side observer sees them. A capture therefore records the host's internal view at that point, not necessarily the frames on the link. Both mechanisms depend on the device and the path.

ethtool -k eth0 | grep -E 'tso|gso|gro'

Capture at a second point, ideally an independent receiver or a mirror, before treating the size as a fault. If the large unit appears only on the sending host, the wire may never have carried it. Two vantage points are stronger than one file, especially when the question is what actually left the machine.

Separate the Inner and Outer Interfaces

A tunnel adds its own interface, and the outer and inner views differ in encapsulation and in processing. A capture on the tunnel device shows the inner packet; a capture on the physical adapter shows the outer one. Size, addresses and checksum state can differ between them for reasons that have nothing to do with a fault.

Record which interface produced each file. A size seen on the tunnel device describes the inner packet, not the frame the adapter eventually sent. Mixing them in one analysis is how a normal encapsulation difference becomes a mystery.

A Checksum Warning Is Also Positional

A transmit-side capture can show a checksum field before the hardware fills it in, which produces a warning that no receiver would ever see. That is different evidence from a remote host rejecting a damaged packet. The direction and the capture point decide which of the two you have.

When an actual transfer fails, compare observations at a receiver or at another point on the path. Keep the direction, interface and encapsulation layer with the record, because a screenshot without them cannot be interpreted later.

Disable Offload Only as a Controlled Test

Turning offload off changes performance and packet processing, so it is not the first response to an odd size display. If you test it, change one setting and record the baseline first. A run that also changes MTU, firewall rules and the client profile cannot attribute the result to offload. Restore the setting afterwards.

ethtool -K eth0 tso off gro off
ping -M do -s 1400 example.com

A genuine large-transfer stall is a separate question about path MTU and the feedback the application receives. A host's aggregated unit neither proves nor disproves a downstream size limit, and a low CPU percentage does not identify offload as the cause.

The useful outcome is an explained capture point plus a reproducible application observation. With those separated, an MTU change can target a real constraint instead of the shape of an internal buffer.