DLPI device but don't have permission to put the interface in
promiscuous mode; some systems using DLPI work that way.
Change the libdlpi code to return a warning if you *are* using
physical promiscuous mode and you fail to turn on SAP promiscuous mode,
not if you *aren't* using physical promiscuous mode and you fail to turn
on SAP promiscuous mode; that matches with the no-libdlpi code does, and
matches what the comment says.
Pull dlattachreq up into dl_doattach().
don't know the netmask. (It also lets you test, at compile time,
whether you can rely on "ip broadcast" failing to compile when you pass
0xffffffff to pcap_compile().)
Don't define DLT_IPOIB with the same value as one of the DLT_USERn
definitions - it's not used, and we don't want to make anybody think
that value belongs to any particular link-layer type.
build 125 and later to use the native BPF with both IPNET and traditional
MAC (ethernet, etc) packet sniffing, the attached patches are required.
The attached patches represent what's in our internal build tree for libpcap.
Update CREDITS to give Jon Smirl credit for some of the USB fixes.
Rename DLT_USB_LINUX_MMAP to DLT_USB_LINUX_MMAPPED, and declare a
structure for the header of packets in DLT_USB_LINUX_MMAPPED captures.
try scanning the sysfs USB directory first and, if that
directory doesn't exist, try the procfs USB directory, to handle
newer kernels where the relevant director is in sysfs;
use the data length, not the URB length, as the amount of data
in the packet (the URB length is the amount of space *available*
for the data, not the actual amount of data).
For the memory-mapped interface, include the padding after the URB and
setup header in the packet lengths, and return a different link-layer
type so that code reading the packets knows that padding is there.
Author: Michael Richardson <mcr@sandelman.ca>
Date: Thu Nov 13 11:42:19 2008 -0500
added DLT_LINUX_EVDEV for David Gibson <david@gibson.dropbear.id.au>
Fix the name of the devices, and add LINKTYPE_LINUX_EVDEV.
VLAN packets sent over devices supporting VLAN tagging/stripping in
hardware don't have a VLAN header when they are received on packet
sockets. The VLAN TCI is available through the PACKET_AUXDATA cmsg,
reconstruct the entire header when necessary.
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.
check in the generated version, and don't put it into the distribution.
Fix a bunch of references to tcpdump-workers@tcpdump.org to refer to the
new address, tcpdump-workers@lists.tcpdump.org.
Fix a reference to the pcap man page from the pcap-filter(4) man page.
Note that patches should be submitted on the SourceForge site, not sent
to the spam-trap patches@tcpdump.org list.
library has to be freed by the library, as an application or other
library using that library might have been built with a different
version of the C runtime library.
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. (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.
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.