used to clean up after a failed pcap_activate() call. Convert the
existing close_op routines to cleanup_op routines, and use them to clean
up; rename pcap_close_common() to pcap_cleanup_live_common(), and use it
directly if there's no platform-dependent cleanup needed. That means we
don't have to write the same cleanup code twice (and possibly forget
stuff in the version done on a failed pcap_activate() call).
Have the cleanup routines do whatever is necessary to indicate that
cleanup has been done, and not do any particular cleaning up if it's
already been done (i.e., don't free something if the pointer to it is
null and null out the pointer once it's been freed, don't close an FD if
it's -1 and set it to -1 once it's been closed, etc.).
For device types/platforms where we don't support monitor mode, check
for it and return PCAP_ERROR_RFMON_NOTSUP - but do so after we've
checked whether we can open the device, so we return "no such device" or
"permission denied" rather than "that device doesn't support monitor
mode" if we can't open the device in the first place.
Fix a comment.
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).
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.
no_optimize - we check, instead, whether the kernel rejected the
program).
Move the initialization of the bpf_dltlist structure right before its
first use.
Add some additional checks to bpf_validate(), from OpenBSD.
Use bpf_validate() in install_bpf_program(), so we validate programs
even when they're being processed by userland filters; we make
bpf_validate() not reject backward branches, as we use them for the
protochain operator.
For BPF, don't assume that, just because no_optimize was set, we have a
program that we can't hand to the kernel; the user of the application
might have specified no optimization (e.g., tcpdump with -O), or we
might have generated code to handle 802.11 headers (the optimizer can't
handle that code). Instead, try handing the filter to the kernel and,
if that fails, try it in userland.
Get rid of BPF_MAXINSNS - we don't have a limit on program size in
libpcap.
guy