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).
captures, set the socket buffer size to the value specified by
pcap_set_buffer_size() if a value was set.
Clean up if memory buffer allocation fails on Linux.
to 1.0, might as well go with the place where Red Hat stuck the header
at one point and where the header "officially" resides.
(We should put a "backwards compatibility" note into pcap.3pcap.)
functions plus an overall man page for libpcap, and put them all into
section 3PCAP. That means you can actually do "man pcap_open_live" and
get something meaningful, rather than having to do "man pcap" and then
scroll through all the other stuff in the man page.
handle" routine, an 'activate a pcap_t handle" routine, and some "set
the properties of the pcap_t handle" routines, so that, for example, the
buffer size can be set on a BPF device before the device is bound to an
interface.
Add additional routines to set monitor mode, and make at least an
initial attempt at supporting that on Linux, *BSD, and Mac OS X 10.4 and
10.5.
Have a "timeout" member of the pcap_md structure on all platforms, use
that on Windows instead of the "timeout" member of the pcap_t structure,
and get rid of the "timeout" member of that structure.
handle" routine, an 'activate a pcap_t handle" routine, and some "set
the properties of the pcap_t handle" routines, so that, for example, the
buffer size can be set on a BPF device before the device is bound to an
interface.
Add additional routines to set monitor mode, and make at least an
initial attempt at supporting that on Linux, *BSD, and Mac OS X 10.4 and
10.5. (Very much "initial" for Linux, which is a twisty little maze of
wireless drivers, many different.)
Have a "timeout" member of the pcap_md structure on all platforms, use
that on Windows instead of the "timeout" member of the pcap_t structure,
and get rid of the "timeout" member of that structure.
newline in them.
If we're in cooked mode, the packet pointer argument we pass to the callback
should point to the beginning of the constructed sll header, not to the
packet data itself. While we're at it, have a paranoid check to make
sure that we were given enough space to construct the sll header, so we
don't stomp on the tpacket header.
Note that a value of 0 for the "cnt" argument to pcap_dispatch() or
pcap_loop() is now the same as a value of -1 - and that it used to be
undefined what it meant, and that it behaved differently on different
platforms, so any application that needs to work on older versions of
libpcap should use -1, not 0. (We also explicitly say that -1 should be
used, rather than saying that a negative value should be used, as some
platforms checked explicitly for -1.)
guy