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

Error code 433, "A device which does not exist was specified." error when opening the loopback device? #1948

Open
guyharris opened this issue Mar 5, 2020 · 4 comments

Comments

@guyharris
Copy link

@guyharris guyharris commented Mar 5, 2020

Some Wireshark users have been reporting an error "\Device\NPF_Loopback' (Error opening adapter: A device which does not exist was specified. (433)". See, for example, this question on the Wireshark Q&A site, as well as issues #1793 and #1944.

A Google search for

"A device which does not exist was specified." 433

found a bunch of other reports of that issue not mentioning Wireshark or Npcap and not having anything to do with packet capture.

Microsoft's page for Windows error codes from 0 to 499 doesn't list 433. This answers.microsoft.com page shows an NT status code of 0xc000000e being associated with that error; Microsoft's list of NT status codes shows 0xc000000e as STATUS_NO_SUCH_DEVICE.

The master branch of npcap doesn't show any code checking for, or returning, or doing anything else with STATUS_NO_SUCH_DEVICE, nor does it show any reference to 433.

Any idea what could be going on here? The "Error opening adapter" part of the message comes from pcap_activate_npf() - it calls PacketOpenAdapter() and, if that returns NULL, if the error code is ERROR_BAD_UNIT, it returns PCAP_ERROR_NO_SUCH_DEVICE, but, for any other error code, it returns PCAP_ERROR and, at least in the master libpcap branch, formats an error message using pcap_fmt_errmsg_for_win32_err(), which uses FormatMessageA() to get an error message for the error code, so I guess Microsoft's FormatMessage code turns 433 into "A device which does not exist was specified.", even though 433 isn't documented.

@guyharris

This comment has been minimized.

Copy link
Author

@guyharris guyharris commented Mar 5, 2020

433 is ERROR_NO_SUCH_DEVICE, which is in winerror.h but is NOT documented on the 0-499 error code page. Currently, nothing in the tip of the npcap master branch has ERROR_NO_SUCH_DEVICE in it.

So where would that error code come from? Presumably either 1) some kernel API is being called by the driver and returning that, the driver's returning that from, for example, an NtCreateFile() ntdll API and that's getting handed back to userland (CreateFile() in kernel32 or csrss or whatever) and getting mapped to ERROR_NO_SUCH_DEVICE, and PcapOpenAdapter() is failing because CreateFileA() is failing, and pcap_activate_npf() is seeing that failure, getting ERROR_NO_SUCH_DEVICE from GetLastError(), and saying "weird error, here's PCAP_ERROR and a message string for the error".

@dmiller-nmap

This comment has been minimized.

Copy link

@dmiller-nmap dmiller-nmap commented Mar 8, 2020

This particular one is probably a result of the behavior of Npcap 0.9983 - 0.9987 where the \Device\NPF_Loopback device will be returned from a call to PacketGetAdapterNames() (or pcap_findalldevs()) even if the npcap driver is not running. Npcap 0.9988 changes this so that the loopback device will only be displayed if it can successfully be opened for capture (nmap/npcap@63f7e3e).

I'm basing this guess on #1944, where the user determined that the driver service was not running. There may be a separate issue causing the driver to not run on those systems, so we'll see if that is reported for Npcap 0.9988.

@guyharris

This comment has been minimized.

Copy link
Author

@guyharris guyharris commented Mar 8, 2020

This particular one is probably a result of the behavior of Npcap 0.9983 - 0.9987 where the \Device\NPF_Loopback device will be returned from a call to PacketGetAdapterNames() (or pcap_findalldevs()) even if the npcap driver is not running.

So is the issue here that, if you try to open an interface, Packet32.dll checks whether it knows about it, in the sense of "would pcap_findalldevs() return it?" and, if not, returns ERROR_BAD_UNIT, but if it knows about it, it (or the helper) makes a CreateFileA() call on a device symbolic link, expecting it to succeed, given that it's already determined whether the interface exists, but it doesn't exist, so ERROR_NO_SUCH_DEVICE is returned by the NT kernel because it fails to find the symbolic link in question due to the Npcap driver not running?

@dmiller-nmap

This comment has been minimized.

Copy link

@dmiller-nmap dmiller-nmap commented Mar 9, 2020

Yes, that sounds correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.