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

pcap_create() on a non-existent device returns an error #586

Open
guyharris opened this issue Mar 11, 2022 · 1 comment
Open

pcap_create() on a non-existent device returns an error #586

guyharris opened this issue Mar 11, 2022 · 1 comment

Comments

@guyharris
Copy link
Contributor

guyharris commented Mar 11, 2022

To quote the commit message for the-tcpdump-group/libpcap@e8c0f49:

npf: don't have pcap_create() fail if the device doesn't exist.

Also, don't have it fail if the user doesn't have permission to open it.

To quote the comment (which opens with a paragraph taken directly from the equivalent code in pcap-linux.c):

If we can't open the device now, we won't be able to later, either.

If the error is something that indicates that the device doesn't exist, or that they don't have permission to open the device - or perhaps that they don't have permission to get a list of devices, if PacketOpenAdapter() does that - the user will find that out when they try to activate the device; just return an empty list of time stamp types.

Treating either of those as errors will, for example, cause tcpdump -i <number> to fail, because it first tries to pass the interface name to pcap_create() and pcap_activate(), in order to handle OSes where interfaces can have names that are just numbers (stand up and say hello, Linux!), and, if pcap_activate() fails with a "no such device" error, checks whether the interface name is a valid number and, if so, tries to use it as an index in the list of interfaces.

That means pcap_create() must succeed even for interfaces that don't exist, with the failure occurring at pcap_activate() time.

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.

@guyharris
Copy link
Contributor Author

Note that a fix to #175 might also fix this, as pcap_create() could open the device with a "succeed even if not running as Administrator, but the handle won't let you capture or inject" call, so that the user not allowing the capture wouldn't prevent fetching the time stamp types and thus wouldn't cause pcap_create() to fail.

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant