When running TCPDUMP on modern Linux systems (especially 64-bit architectures), you'll frequently encounter packets marked with "incorrect checksum" messages like:

cksum 0xe61f (incorrect (-> 0x8c37))

These messages appear because modern NICs often handle checksum offloading - the checksum calculation is performed by hardware rather than the kernel. When TCPDUMP captures packets before they reach the NIC, the checksums haven't been calculated yet, resulting in these false positives.

Most modern network cards support these offload features:

• TX Checksum Offloading (checksum calculation on transmission)
• RX Checksum Offloading (checksum validation on reception)

You can verify your NIC's capabilities with:

ethtool -k eth0 | grep checksum

Typical output would show:

tx-checksumming: on
rx-checksumming: on

While these checksum errors might look alarming, they don't indicate actual network problems or affect performance when:

• They appear on local captures
• The network communication works normally
• No actual packet loss occurs

However, if you're seeing checksum errors and experiencing network issues, you should investigate further.

For accurate packet analysis, you have several options:

Option 1: Disable Checksum Offloading

Temporarily turn off checksum offloading during captures:

ethtool -K eth0 tx off rx off

Remember to re-enable afterward:

ethtool -K eth0 tx on rx on

Option 2: Use TCPDUMP Filters

Filter out checksum-related messages:

tcpdump -i eth0 -vvv not ip[10:2] = 0x0000

Option 3: Capture at Different Points

Use alternative capture methods:

# Capture after checksum calculation
tcpdump -i any -s0 -w capture.pcap

# Use AF_PACKET for raw captures
tcpdump -i eth0 -s0 --immediate-mode -w capture.pcap

To confirm whether checksum errors are real or false positives:

# Check for real errors in kernel log
dmesg | grep -i checksum

# Verify with alternative tools
tshark -i eth0 -Y "tcp.checksum_bad == 1"

Genuine checksum errors typically indicate:

• Faulty network hardware
• Driver issues
• Network corruption
• Malicious packet manipulation

Monitor these metrics to identify real problems:

netstat -s | grep -i "failed\|checksum"
ip -s link show eth0

---

When running tcpdump on a Linux server, encountering checksum errors like:

cksum 0xe61f (incorrect -> 0x8c37)

is surprisingly common. These messages indicate that TCP checksum verification failed for about 50% of packets in your capture.

The majority of these "errors" are actually false positives caused by checksum offloading. Modern network cards calculate checksums in hardware for performance reasons, but when we capture packets:

1. The packet is processed by the NIC
2. Checksum is calculated in hardware
3. tcpdump captures the packet before checksum insertion

Check your NIC settings with:

ethtool -k eth0 | grep checksum
tx-checksumming: on
rx-checksumming: on

To temporarily disable for testing:

ethtool -K eth0 tx off rx off

While checksum errors in captures look alarming, they typically don't affect actual network performance because:

• The checksums are actually correct when transmitted
• This is purely a capture artifact
• Hardware offloading improves throughput significantly

Genuine checksum errors would appear when:

# Capture with checksum verification disabled
tcpdump -vvv -i eth0 'ip[10:2] & 0xffff != 0'

Legitimate causes include:

• Faulty network hardware
• Driver issues
• Malformed packets from malicious sources

To exclude these false positives:

tcpdump -i eth0 'not (ip[10:2] = 0 and ip[12:2] = 0)'

Or for more detailed analysis:

tcpdump -i eth0 -XX -vv -n 'tcp[tcpflags] & (tcp-syn|tcp-ack) != 0'

For production troubleshooting, consider:

# Use libpcap with checksum verification disabled
sudo tcpdump -i eth0 -s 0 -w /tmp/capture.pcap -C 100 -W 10

Or use Wireshark's preference setting: Validate the TCP checksum if possible

Inspect kernel messages for NIC issues:

dmesg | grep -i eth0

Monitor interface statistics:

ethtool -S eth0 | grep -i error