未开启Wireshark抓包时ICMP Ping失败问题排查求助

问题背景 #

使用Texas Instruments Starter Kit开发嵌入式MCU硬件，自行实现以太网驱动及ARP、IP、ICMP协议栈，MCU与Windows x86桌面通过以太网通信。开启Wireshark抓包时，ping操作正常；停止抓包后ping失败，提示“Destination host unreachable”。MCU日志显示已正确回复Windows的ARP请求，但Windows未发送ICMP请求；arp -a命令显示抓包时MCU的MAC在ARP表中，停止抓包后消失。

可能的问题原因 #

• ARP响应帧不符合标准规范：Wireshark抓包时会开启网卡混杂模式，此时网卡会接收所有帧，包括格式有微小瑕疵的帧；但关闭抓包后，网卡回到正常模式，会过滤不符合标准的帧——比如FCS校验错误、帧长度不匹配、ARP字段错误（硬件类型/协议类型值不对、操作码写错、目标MAC不是Windows网卡的MAC而是广播MAC等）。
• ARP响应时机超时：Windows发送ARP请求后有固定超时窗口，若MCU的响应在窗口之后到达，Windows会直接丢弃该响应，不更新ARP缓存；抓包时工具的延迟可能间接延长了Windows的超时判断，让延迟的响应被正常接收。
• Windows ARP缓存机制触发：抓包时Wireshark可能干扰了Windows的ARP缓存更新逻辑，停止抓包后，ARP缓存的超时清理机制启动，而MCU的响应未被正确识别，导致缓存条目被删除。
• 网卡硬件过滤生效：部分Windows网卡驱动开启硬件级帧过滤，仅接收目标MAC为自身或广播的帧；若MCU的ARP响应目标MAC字段错误，正常模式下网卡会直接丢弃，而混杂模式会绕过该过滤。

调试方法 #

• 逐字段校验ARP响应帧：对照RFC 826标准检查每一项：
  • 硬件类型必须是0x0001（以太网），协议类型必须是0x0800（IPv4）
  • 硬件地址长度为0x06，协议地址长度为0x04
  • 操作码必须是0x0002（ARP响应）
  • 发送端/目标端的MAC、IP必须完全正确，目标MAC必须是Windows网卡的实际MAC，不能用广播MAC
• 测试ARP响应发送时机：记录MCU从收到ARP请求到发送响应的时间，确保在100ms以内，避免超过Windows的ARP请求超时窗口。
• 手动绑定ARP缓存测试：在Windows命令行执行arp -s <MCU_IP> <MCU_MAC>，手动绑定ARP条目后停止抓包执行ping，若能正常通信，说明问题确实出在ARP响应未被Windows识别导致缓存未更新。
• 对比标准ARP响应帧：用正常设备（比如另一台电脑）的ARP响应帧做参考，对比MCU发送帧的二进制格式，包括帧头、ARP报文、FCS校验值是否完全一致。

Windows的丢包/过滤统计工具 #

• netsh命令集：
  • 执行netsh interface ipv4 show statistics，查看IPv4层接收/丢弃统计，包含ARP相关丢包数据
  • 执行netsh interface show interface，查看网卡的接收错误、丢弃包计数
• 事件查看器：在「系统」日志中查找来自NetBT或Tcpip服务的事件，可能会记录ARP缓存更新失败、帧过滤的相关信息
• 性能监视器：添加「Network Interface」下的Discarded Packets Received、Packets Received Discarded计数器，实时监控网卡丢包情况
• arp命令进阶：执行arp -v查看详细ARP缓存条目状态，包括条目类型（动态/静态）、超时时间

内容的提问来源于stack exchange，提问作者Bubu