Skip to content

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

@guyharris

Description

@guyharris

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions