-
Notifications
You must be signed in to change notification settings - Fork 542
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
pcap_create() on a non-existent device returns an error #586
Comments
Note that a fix to #175 might also fix this, as |
dmiller-nmap
pushed a commit
that referenced
this issue
Apr 28, 2022
Previous approach would store names, addresses, and device type when PacketGetAdapterNames was first called. Device type was used to choose appropriate routine during PacketOpenAdapter, but addresses were not used outside PacketGetNetInfoEx. That function forced a refresh of the adapter info in question, so there was no reason to have cached it. Furthermore, the only non-NDIS device types we handle can be distinguished by the adapter name. Changes: * PacketOpenAdapter no longer results in a call to GetAdaptersAddresses (via the removed PacketUpdateAdInfo function). The adapter is attempted to be opened directly, allowing passthrough of appropriate error codes instead of simply ERROR_BAD_UNIT. See #587 * PacketGetAdapterNames no longer requests address information from GetAdaptersAddresses, which ought to reduce the buffer space needed. * PacketGetNetInfoEx calls GetAdaptersAddresses directly, only requesting devices with addresses configured, also reducing buffer. * PacketGetNetInfoEx will quickly respond for AirPcap devices (no addresses) and the Npcap Loopback device (static loopback address; previously no address was returned). Closes #169. Closes #61 (together with e9eccab and b76ca89). Related #586, #569.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
To quote the commit message for the-tcpdump-group/libpcap@e8c0f49:
This is, perhaps, an indication that we need a better API than
pcap_create()
, so that if it fails it can give more than a message string as a "why it failed" indication, but, for now, we're stuck with it.On the other hand, another advantage of deferring the failure until
pcap_activate()
time is that it allows an application to provide lists of interfaces, perhaps even with list of settable options for them, even for interfaces that the user doesn't have permission to open, so that, if they're running without sufficient permission, they report "I get told that I don't have sufficient permission to capture on XXX" rather than "XXX doesn't show up in the list of interfaces", making it more obvious what the underlying problem is when an issue pops up. (I made a bunch of libpcap changes to make that the case, because it eliminated a bunch of "I'm not seeing any interfaces" errors in Wireshark, replacing them with more obvious "I'm getting told I don't have permission to capture on an interface" errors, for which the response may be something such as "run the blahblahblah command on the command line" to get dumpcap installed with the appropriate capabilities on a Debian-flavored Linux.)I'll be backporting that change to the 1.10 branch, and we may be coming out with a 1.10.2 release at some point, but you can pick up that change in advance of that.
The text was updated successfully, but these errors were encountered: