tcpdump捕获的“checksum错误”多为网卡校验和卸载导致的假阳性，无法定位物理网线故障；真实物理层问题应通过ethtool -s查看rx_crc_errors等底层计数器，并结合ping丢包率、链路状态及换线测试综合判断。
直接用 tcpdump 捕获“Checksum 错误”的报文本身并不能定位物理网线故障，因为 tcpdump 默认看到的 bad checksum 多数是假阳性——源于网卡硬件校验和卸载（Checksum Offload），而非真实线路损坏。真由网线、接口或物理层导致的校验错误，tcpdump 通常根本抓不到，因为这类包在驱动层就被丢弃了。
先区分真假 checksum 错误
Wireshark 或 tcpdump 显示 bad tcp cksum 或 incorrect checksum，95% 以上是以下原因：
- 发送方向：内核把校验和字段留空或填随机值，交由网卡在发包前计算并填充正确值；tcpdump 在网卡驱动前抓包，所以看到的是未填充/错误值
- 接收方向：网卡收到包后已验证校验和，若失败则直接丢弃，不会上送到 tcpdump；因此你几乎不可能在本机 tcpdump 中捕获到“真实损坏但被网卡放行”的包
- 物理链路问题（如网线老化、RJ45松动、电磁干扰）引发的比特翻转，大概率导致帧校验失败（FCS error），这类错误发生在数据链路层，会在网卡驱动或内核收包路径中被静默丢弃，不会出现在 tcpdump 输出里
真正能反映物理层异常的指标不在 tcpdump 包内容里
要排查网线/接口类故障，应转向网卡底层统计，而非分析 tcpdump 抓到的包头：
- 运行 ethtool -S eth0（将 eth0 替换为实际接口名），重点检查这些字段是否非零且持续增长：
rx_crc_errors（CRC 校验失败）、
rx_frame_errors（帧对齐错误）、
rx_missed_errors（ring buffer 溢出丢包）、
tx_aborted_errors（发送中止） - 对比 ifconfig eth0 输出中的 RX/TX errors、dropped、overruns 数值，重启前后是否有明显上升
- 拔插网线、更换端口或交换机侧接口，观察上述计数器是否突变或归零，是快速定位物理连接问题的有效动作
如果坚持要用 tcpdump 辅助交叉验证
可配合禁用 offload 后做一致性比对，但目的不是“抓坏包”，而是排除干扰：
- 临时关闭校验和卸载：sudo ethtool -K eth0 tx off rx off gso off
- 再用 tcpdump -i eth0 -nn -vvv -c 100 'tcp' 抓少量包，确认输出中不再出现 bad tcp cksum
- 此时若仍观察到连接频繁重传、RST、零窗口等异常行为，且 ethtool -S 中 CRC/frame 错误同步升高，则高度提示物理链路不稳定
更直接的物理层诊断步骤
不依赖 tcpdump，更快锁定网线问题：
- 用 ethtool eth0 查看 Link detected: yes/no、Speed、Duplex 状态是否正常波动
- 在两端设备上同时运行 ping -f -c 1000 目标IP，观察丢包率与延迟抖动；高丢包 + 高抖动 + ethtool 中 CRC 上升 = 典型物理层问题
- 更换网线、短距离直连测试、用专业线缆测试仪检测通断与串扰（尤其适用于千兆及以上速率）
