Npcap should perhaps not report a zero RSSI value

[guyharris]

It appears that, for some devices, the signal strength is reported as 0 dBm; this probably means that the device doesn't report the signal strength, not that the signal strength was 1 milliwatt.

See, for example, this ask.wireshark.org question.

[dmiller-nmap]

Raw WiFi capture support is problematic right now for a few reasons, but I'm hopeful we'll be able to improve things.

First, Npcap makes use of the Native 802.11 Wireless API which is deprecated in Windows 10. Newer drivers will be using the WLAN Device Driver Interface (WDI), and I haven't figured out how a NDIS filter driver like ours would be able to get similar information for packets under that API.

Also, support is dependent on the device driver delivering accurate information. This can break down a number of ways:

1. The hardware may not make some information available to the driver.
2. The driver may not make the information available to higher layers.
3. The driver may use a different API (WDI, Native 802.11, etc.) than we expect to make the information available.
4. The driver may provide incorrect information (zero, uninitialized, stale, etc) to higher layers.

The change I just pushed ought to prevent us from interpreting uninitialized or zeroed memory as out-of-band media-specific information, but there's no guarantees that the underlying drivers are behaving correctly.

[guyharris]

Raw WiFi capture support is problematic right now for a few reasons

It appears to be even more problematic with WDI. To quote "Features not carried over in WDI":

The following features are available in the previous Native WLAN driver model, but are not available in WDI.

...

• Netmon

[gpotter2]

I've asked about this on MicrosoftDocs/windows-driver-docs#1476, and they answered that they will look into it.

Feel free to add any additional concerns/infos, or ping the thread.

Edit:

Netmon was not carried over to WDI as it did not fall into the category of required functionality when the Wi-Fi driver team was making design decisions for WDI. In addition, the team discovered that many drivers did not implement this well enough to make it reliable. In a related vein, the Native 802.11 miniport driver model was indeed officially deprecated with the release of Windows 10, which supports WDI instead.

As for alternatives, I don't know of any personally but the team did say this:

"Currently, we expect customers to use the available commercial solutions, but if there is sufficient ask for it, we can consider it for the next driver model update."

So, I'd recommend submitting a feature request through the Feedback Hub or through the "This Product" feedback button on this page. However, keep in mind that they did say that they would consider this for the next driver model update, not the next WDI update, and the timeline of that is completely unknown at this point.

It looks worse than what I expected :/