isn't up, so applications can report that differently from a generic
error (the latter could mean there's a bug somewhere in libpcap).
When capturing on a device without mmap on Linux, ignore ENETDOWN, so
that we can continue to capture traffic if the interface goes down and
comes back up again; comments in the kernel indicate that we'll just
block waiting for packets if we try to receive from a socket that
delivered ENETDOWN, and, if we're using a memory-mapped buffer, we won't
even get notified of "network down" events.
know that..."; currently, only pcap_activate() returns them, but we
might want some more warning returns for some other calls, such as the
ones that set filters. It's a little cleaner than "clear out the error
message buffer and, if it's not empty after a successful return, it has
a warning", and a little cleaner than spewing a warning to the standard
error (as that might not be visible to the user if they're running a GUI
application).
that often means "sorry, this platform requires you to run as root or to
somehow tweak the system to give you capture privileges", and
applications might want to explain that in a way that does a better job
of letting the user know what they have to do.
Try to return or PCAP_ERROR_PERM_DENIED for open errors, rather than
just returning PCAP_ERROR, so that the application can, if it chooses,
try to explain the error better (as those two errors are the ones that
don't mean "there's probably some obscure OS or libpcap problem", but
mean, instead, "you made an error" or "you need to get permission to
capture").
Check for monitor mode *after* checking whether the device exists in the
first place; a non-existent device doesn't support monitor mode, but
that's because it doesn't, well, exist, and the latter would be a more
meaningful error.
Have pcap_open_live() supply an error message for return values other
than PCAP_ERROR, PCAP_ERROR_NO_SUCH_DEVICE, and PCAP_ERROR_PERM_DENIED -
those all supply error strings (PCAP_ERROR because it's for various OS
problems that might require debugging, and the other two because there
might be multiple causes).
guy