Use "link-layer header type" as the term for DLT_ values; it doesn't
necessarily correspond to the actual data link type of the device
(802.11 devices, for example, can supply Ethernet headers).
In the pcap_list_datalinks() man page, refer to the
pcap_datalink_val_to_name() man page, as the routines described there
can be used to print out names and descriptive text for the values
returned by pcap_list_datalinks().
In the pcap_set_datalink() man page, refer to the
pcap_datalink_name_to_val() man page, as pcap_datalink_name_to_val() can
be used to convert a name for a link-layer header type into a value to
be handed to pcap_set_datalink().
Update the change date on some man pages while we're at it.
Pull the documentation for pcap_freealldevs() into the
pcap_findalldevs() man page, and pull the documentation for
pcap_free_datalinks() into the pcap_list_datalinks() man page.
The RA field is absent from management frames (addr1 is DA there), and
addr1 in other frames.
The TA field is absent from management frames (addr2 is SA there), and
addr2, if present, in other frames.
While we're at it, fix a font glitch in the pcap-filter man page.
Do the standard userland filtering on USB and Bluetooth captures, rather
than returning "success" when the filter is installed without doing
anything with the filter.
Also, squelch some "dereferencing type-punned pointer will break
strict-aliasing rules" warnings in pcap-bt-linux.c, by using memcpy
rather than pointer-casting.
Don't ignore them, reject them, so applications know that non-blocking
mode didn't get turned on, if they're expecting non-blocking reads from
a pipe, for example.
bpf_open() already handles returning the right PCAP_ERROR_ value and
setting p->errbuf; let it do its thing.
Enhance its thing so that it tries to do a better job of figuring out
what the problem is (no BPF devices at all, all BPF devices busy, no
permission to open BPF device, something else).
Have pcap_can_set_rfmon() return PCAP_ERROR_PERM_DENIED if you don't
have permission to check the device and PCAP_ERROR_NO_SUCH_DEVICE if
there's no such device, at least on Mac OS X. Other platforms need to
be fixed as well.
Update the documentatation to reflect that it can return
PCAP_ERROR_PERM_DENIED, fix a typo, and speak of capture sources rather
than devices.
Update from Jason (Xin) Li to reflect changes to the FreeBSD
SIOCGIFDESCR implementation - it now doesn't return an error if the
buffer is too short, it sets the buffer pointer to NULL. No FreeBSD
release has SIOCGIFDESCR, so this doesn't break on any release.
The loop, trying to increase the buffer size until it's big enough,
works only on FreeBSD, as that's the only OS where you get told what
length to use; OpenBSD clamps the description length at IFDESCRSIZE, so
we just use that.
Both of them are indications that there's no such interface, so the file
probably corresponds to something other than a device.
Reviewed-By: Guy Harris <guy@alum.mit.edu>
BPV_RVAL() is the macro to check the type of the return value of a "ret"
instruction; it tests more bits than are appropriate for a "div"
instruction, and the test fails.
We don't need or want them on UN*X (for one thing, we do fat builds on
OS X, and SIZEOF_LONG doesn't have the same value in ILP32 and LP64),
and don't need them on Windows, either (long is 32 bits in both Win32
and Win64).
In the help message for --disable-universal, note that it's for OS X.
The configure script will presumably offer that option even on other
OSes (e.g. because you might be cross-building for OS X).
Instead of requiring the user to specify -arch options on OS X to build
a universal version of libpcap, just default to universal on OS X by
default. Pick the particular targets to match the way libpcap is built
for the OS for which we're building.
They allow the user to specify flags to indicate the target
architecture(s) (yes, possibly plural - think, for example, Mac OS X)
for which we're building. Those might need to be used not only when
compiling, but also when linking and when building a shared library.
This is not for general cross-compiling, it's for use on platforms where
versions of the native OS support more than one instruction set and
where you want to build for the OS on which you're running but not for
the default build architecture on the machine on which you're running.
Guy Harris