Npcap项目无线网卡重连后DHCP失效问题分析与修复

在Npcap网络抓包驱动开发过程中，开发团队发现了一个影响无线网络连接稳定性的关键问题：当用户程序持有网卡捕获句柄时，若无线网卡发生断开重连，系统将无法正常获取DHCP地址。本文将从技术原理、问题定位到解决方案进行完整剖析。

问题现象与复现条件

该缺陷出现在Npcap 1.71及以上版本中，具体表现为：

1. 用户程序通过pcap_create创建捕获句柄并激活（pcap_activate）
2. 无线网卡被手动禁用后重新启用
3. 系统虽然能完成WiFi关联，但无法获取IP地址
4. 网络流量监测显示DHCP交互过程完整，但操作系统未收到响应包

值得注意的是，当同时使用netsh trace进行诊断捕获时，该问题会神奇地消失，这一现象为后续排查提供了重要线索。

技术背景：NDIS过滤驱动

Npcap作为NDIS中间层驱动，需要正确处理网络适配器的状态变化。关键机制包括：

• 包过滤器（Packet Filter）：通过OID_GEN_CURRENT_PACKET_FILTER控制数据流向上传递
• 暂停状态（Paused State）：适配器禁用时驱动进入的临时状态
• 硬件过滤模式：特别是混杂模式（Promiscuous Mode）的特殊处理

根因分析

通过内存转储分析和调试日志，团队发现：

1. 网卡重连后，协议栈会重新发送OID_GEN_CURRENT_PACKET_FILTER设置请求
2. Npcap在暂停状态恢复时错误认为过滤器已设置，跳过了请求转发
3. 导致网卡硬件过滤器未正确配置，所有数据包被底层丢弃
4. netsh trace的介入改变了过滤器设置时序，掩盖了问题

解决方案

修复方案删除了原有的冗余检查逻辑（commit e9e59b8）：

1. 取消对OID请求的"已设置"假设判断
2. 确保所有过滤器设置请求都能透传到下层驱动
3. 特别处理了非混杂模式下的过滤器同步问题

技术启示

该案例揭示了网络驱动开发中的典型陷阱：

• 状态机设计必须考虑所有硬件事件路径
• 中间层驱动不能假设上层请求的冗余性
• 硬件过滤器需要与协议栈状态严格同步
• 诊断工具可能改变系统行为，需谨慎解读现象

此修复已合并到Npcap主分支，将包含在后续正式版本中，从根本上解决了无线网络环境下的DHCP异常问题。