Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Npcap should perhaps not report a zero RSSI value #64

Open
guyharris opened this issue Mar 26, 2019 · 3 comments
Open

Npcap should perhaps not report a zero RSSI value #64

guyharris opened this issue Mar 26, 2019 · 3 comments
Labels
raw wifi

Comments

@guyharris
Copy link

@guyharris guyharris commented Mar 26, 2019

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
Copy link
Contributor

@dmiller-nmap dmiller-nmap commented Mar 28, 2019

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
Copy link
Author

@guyharris guyharris commented Apr 5, 2019

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
Copy link

@gpotter2 gpotter2 commented Apr 29, 2019

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 :/

@fyodor fyodor transferred this issue from nmap/nmap May 20, 2020
@fyodor fyodor added the raw wifi label May 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
raw wifi
Projects
None yet
Development

No branches or pull requests

4 participants