nmap / nmap/npcap

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

Open
#586 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C
Stars
3.6k
Forks
592
PR merge metrics
No merged PRs in 30d

Description

To quote the commit message for https://github.com/the-tcpdump-group/libpcap/commit/e8c0f491649c5067299b976b6b49b82814fb4c9a:

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.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by comparing Npcap's pcap_create() behavior with the referenced libpcap commit, then trace the related pcap_activate() path for nonexistent devices and permission failures. Done means pcap_create() succeeds in those cases and the appropriate failure is reported when pcap_activate() is attempted.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
networking
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.