tcpdump无法直接过滤异常校验和，因内核通常静默丢弃错误包，且网卡卸载导致校验和字段为0或无效；可通过禁用offload、-vvv观察[bad checksum]提示、结合Wireshark分析或/proc/net/snmp计数器间接排查。
tcpdump 本身不直接提供“过滤异常校验和”的语法支持。它工作在数据链路层之上（通常是网络层或传输层），默认不会验证或标记 IP/TCP/UDP 校验和是否错误；内核通常在接收路径中已静默丢弃校验和错误的包，或由网卡硬件卸载（checksum offload）导致抓到的包校验和字段为 0 或无效值——此时看到的不是“异常包”，而是“未校验”或“伪校验和”。
为什么看不到真正的校验和异常包
大多数情况下，你无法用 tcpdump 直接捕获到校验和真正出错且被上层协议栈接受的数据包，原因如下：
- 网卡硬件常启用 checksum offload（如 tx offload / rx offload），发送时由硬件填校验和，接收时也由硬件校验并只把正确包交给内核；tcpdump 抓到的是硬件处理后的包，校验和字段可能为 0 或占位值
- Linux 内核在 IP 层或 TCP 层会对校验和做二次验证，错误包通常被直接丢弃，根本不会进入抓包路径
- tcpdump 过滤表达式不支持对 IP header 中的 checksum 字段、TCP header 中的 checksum 字段做数值比对或有效性判断
能间接识别校验和问题的线索
虽然不能“过滤异常校验和”，但可通过以下现象辅助怀疑校验和相关异常：
-
大量 TCP retransmission 或 dup ACK：用
tcpdump -i eth0 'tcp[tcpflags] & (tcp-rst|tcp-syn) == 0 and (tcp[12:1] & 0xf0) >= 0x50'配合-vvv观察重传标志、序列号乱序、窗口突变等，可能是底层校验失败引发重传 -
IP 头部 checksum 字段为 0 且非 offload 场景：先禁用网卡 offload：
ethtool -K eth0 rx off tx off gso off，再抓包看tcpdump -i eth0 -xx -c 10 | grep -A2 "IP.*checksum"，若仍见checksum 0x0000 (incorrect)类提示（需 -vvv 输出），说明该包校验和明显非法 -
Wireshark 后分析标红警告：保存为 pcap 文件（
tcpdump -i eth0 -w badsum.pcap），用 Wireshark 打开 → 点击某 IP/TCP 包 → 查看 Protocol Tree 中 “IPv4” 或 “TCP” 节点下是否有 "Bad checksum" 提示（Wireshark 可软件校验）
实战建议：定位疑似校验和问题的步骤
若业务出现间歇性连接中断、小包丢失、服务端收不到请求等现象，可按顺序排查：
- 确认网卡是否启用 offload：
ethtool -k eth0 | grep checksum；如开启，临时关闭后复现问题 - 抓基础流量并观察异常行为：
sudo tcpdump -i eth0 -nn -tttt -vvv -c 200 'tcp and port 8080' > http.log 2>&1 - 检查输出中是否频繁出现
[bad checksum]、[tcp sum ok]不一致、或ip checksum 0x0000等字样 - 对比同一通信对，在客户端和服务端分别抓包，看哪一侧先出现校验和字段异常或丢包
- 结合
cat /proc/net/snmp中TcpInErrs、IpInCksumErrors计数器确认内核是否已统计到校验错误
本质上，校验和异常属于底层链路或驱动问题，tcpdump 是观察者而非检测器。真要验证，得靠关闭 offload + 内核日志 + 硬件诊断协同判断。
