Npcap 1.71 and later: unable to obtain DHCP lease when adapter is removed and restored

[dmiller-nmap]

Reported by a Npcap OEM licensee. If a capture handle is open, disconnecting and reconnecting a WiFi adapter appears to prevent any packets from being received by that adapter until the npcap service is restarted. Reproduction steps provided by the user:

Windows 10 LTSC 2021 VM (21H2), with Npcap 1.71.
NETGEAR - AC1200 USB adapter, but also reproduced on a laptop with built-in WiFi.

1. Ensure WiFi adapter is enabled and associated with an access point.
2. Launch a program that:
   • opens a pcap handle for the WiFi adapter (pcap_create)
   • activates the handle (pcap_activate)
   • sleeps forever
3. Disable the WiFi adapter (e.g. via PowerShell Disable-NetAdapter)
4. Enable the WiFi adapter (e.g. via Enable-NetAdapter)
5. Re-associate with the WiFi access point

External packet capture indicates that DHCP request is sent and response is received, but Windows is unable to assign an IP address, indicating that the packet was not delivered up the stack. Interestingly, performing a netsh trace capture during the test prevented the issue from presenting.

[dmiller-nmap]

Current progress:

• We have been unable to reproduce this issue locally with the same hardware. The remaining differences between our test setup and the user's are the Windows version (we tested on Windows 11 and Windows 10 22H2) and the test program (ours being a modified version of pcap_filter.exe that may perform other actions on the capture handle that may interfere).
• We have a crash dump manually generated by the user at the point when the connection is interrupted. We hope to identify inconsistencies with the state of the driver and the stack at this point to indicate the cause of the problem.
• The user has provided a copy of the VM where the issue presents. We hope to use this to reproduce locally where we can use a live debugger.

[dmiller-nmap]

The manual memory dump revealed that the miniport packet filter was unset, meaning that no packets were being delivered up the stack. When we changed our test program to avoid setting promiscuous mode (which is done via hardware packet filter), we were able to reproduce the issue. Using a debug build and DbgView, we saw that the protocol drivers were sending OID_GEN_CURRENT_PACKET_FILTER Set requests while our filter module was in a Paused state, and that Npcap was not propagating these requests because its internal state assumed that the effective filter had already been set (not knowing it had been reset during the pause/detach/attach sequence). As a result, the hardware filter was never set, and the miniport would not deliver any packets.

The fix to this issue was to remove the code that attempted to short-circuit such OID requests on the assumption that they were redundant. Instead, all such requests will be propagated. The change is in e9e59b8.

[Jwdat]

3cfd