values, as those are not platform-dependent and appear in the per-file
header of capture files.
Note that the "10MB" in DLT_EN10MB, and the "IEEE802" in "DLT_IEEE802",
are historical (so people don't think DLT_EN10MB is only for 10MB
Ethernet).
Don't describe the DLT_PFLOG header - it's in the format of a "struct
pfloghdr" on the OS on which the file was saved, which is OS-dependent
and release-dependent.
Refer to the pcap-linktype man page in the pcap-savefile man page.
pcap-linktype man pages; it should be section 7 for UN*Xes using the
V7/BSD conventions (this includes *BSD, Linux, and Mac OS X), and
section 5 for UN*Xes using the System V conventions (this includes
Solaris and HP-UX, and possibly AIX).
scripts, "target" refers to the platform, presumably a compiler, linker,
assembler, etc., for which the software generates code, "host" refers to
the platform on which the software runs, and "build" refers to the
platform on which the software is being built.
soname doesn't have the full version number (as that means that programs
built with libpcap will expect *that particular version* of libpcap, not
just any compatible version).
the OS X shared library; that's what it is in OS X, and that's what gets
built into clients linked against it, so it's not going to change in OS
X as that'd break binary compatibility.
Redo some if statements to make it clearer which branch handles the
zerocopy case and which branch handles the non-zerocopy case.
Support setting the buffer size for zerocopy BPF.
equivalent to strdup(str); use that, so people don't freak out upon
seeing a strcpy() call that, out of context, looks as if it's not
buffer-overflow-safe.
before using that member.
Don't define variables if we aren't going to use them.
If we have an unknown tpacket version (this "can't happen"), return an
error.
pcap-linux: fix invalid rcvbuf size
Libpcap issues a SO_RCVBUF when the buffer size if unspecified (zero).
The intention is to set it when its *not* zero.
Similar to PACKET_AUXDATA for non-mmaped sockets, the VLAN TCI is
present in a new member of struct tpacket2_hdr. Use it to reconstruct
the VLAN header when necessary.
The tpacket_hdr is not clean for 64 bit kernel/32 bit userspace and
is not extendable because the struct sockaddr_ll following it is
expected at a fixed offset.
Linux 2.6.27-rc supports a new tpacket frame header that removes these
two limitations. Convert the mmap ring support to support both formats
and probe for availability of the new version.
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.
for it, for Mac OS X 10.4 and later. (The script could be useful for
BPF-based systems that don't use devfs as well.) We're not installing it
at this point; that might happen later.
guy