Young <dyoung@ojctech.com>, with some minor changes by Jason R. Thorpe
<thorpej@netbsd.org>, and further changes by me to support it on BPF
systems lacking BIOCGDLTLIST and other platforms lacking an equivalent
feature.
Update Jason Thorpe's e-mail address (Zembu is going away, if it hasn't
done so already).
Add APIs to map DLT names to DLT values and vice versa.
if, as I suspect is the case, that causes no timeout to be set, and if
that's the same as explicitly clearing the timeout with SBIOCCTIME, that
would appear to mean that it'd wait forever for a full chunk's worth of
packets to arrive.
can have one of two different behaviors, depending on the OS (it means
"don't return from a read until enough data has arrived" on BSD and
Digital/Tru64 UNIX, and means "return immediately" on Solaris, for
example, at least according to the man pages on Digital/Tru64 UNIX and
Solaris and the code in BSD).
"pcap_dispatch()" and "pcap_loop()", give more details on the effect of
the "snaplen" argument to "pcap_open_live()", and suggest 65535 as a
value if you want to capture the entire packet.
particular, point out that it's only used when checking for IPv4
broadcast addresses, and that if you don't care whether those checks are
done correctly, you can supply 0 if the netmask isn't known or isn't
available.
"pcap_dispatch()", giving the members of a "struct pcap_pkthdr", and
specifying which of those arguments are "const" pointers.
Describe the return value of "pcap_loop()".
the current state of non-blocking mode; this allows us to implement, for
example, memory-mapped capture devices, where "pcap_read()" uses
"select()" or "poll()" to wait for packets to arrive, and hide that
implementation detail from applications using this API
("pcap_setnonblock()" would set or clear a non-blocking mode flag in the
"pcap_t", and the "select()" or "poll()" would not be done if the
"pcap_t" is in non-blocking mode).
field, and make a PCAP_IF_LOOPBACK flag be the first flag bit in that
field, specifying whether the interface is a loopback interface; this
allows us to add more flags without changing the layout of the
structure.
Add a new "pcap_findalldevs()" routine to get a list of all
interfaces that can be opened with "pcap_open_live()", and a
"pcap_freealldevs()" routine to free the list.
Make "pcap_lookupdev()" use it, which also arranges that it will
not return a device that cannot be opened by "pcap_open_live()".
Allow the "any" device to be opened, on Linux, with "promisc"
non-zero; ignore the request for promiscuity, and return a
warning message indicating that promiscuous mode isn't supported
on the "any" device.
Document "pcap_findalldevs()" and "pcap_lookupdev()", and clean up some
items in the libpcap man page.
reality ("pcap_dispatch()", on a live capture, never reads more than one
bufferful of packets).
Break the description of "pcap_dispatch()" into multiple paragraphs.
Move the description of "pcap_loop()" right after the descriptionof
"pcap_dispatch()", and note that "pcap_dump()" can be used as the
callback function for either of them.
that "pcap_dispatch()" will always return within that many milliseconds;
some platforms don't support a read timeout, meaning the read timeout
argument is ignored, and, on other platforms (SunOS 5.x and possibly
SunOS 4.x and 3.x), the timer starts when the first packet arrives, so
the timeout doesn't expire until at least one packet arrives.
"pcap_compile()" and "pcap_compile_nopcap()" return -1 on
failure;
if "pcap_compile()" or "pcap_setfilter()" fails, you can get the
error string with "pcap_geterr()";
if "pcap_compile_nopcap()" fails, you can't get the error
string, but, as it's just a wrapper around "pcap_open_dead()",
"pcap_compile()", and "pcap_close()", you can use those routines
yourself if you want the error string;
you have to use, or copy, the string you get back from
"pcap_geterr()" before closing the "pcap_t" you hand to
"pcap_geterr()", as the string you got back from "pcap_geterr()"
doesn't remain valid after the "pcap_t" whence you got it is
closed.
filter, always attach a copy, as "pcap-linux.c" does; that way, after a
program uses "pcap_setfilter()", it can safely use "pcap_freecode()" to
free up the BPF instructions allocated by "pcap_compile()". Also,
always free it up when the "pcap_t" is closed.
Get rid of the "pcap_t *" argument to "pcap_freecode()", as it's not
necessary.
Document "pcap_freecode()", for the benefit of programs that might
repeatedly compile filter programs and attach them, so that they can
free them up after attaching them and avoid leaking memory for them.
application won't build with any other version of libpcap, which means
that a lot of applications won't use them. In addition,
"pcap_linktype()" needs to return DLT_ values, so that platforms that
build libpcap as a shared library won't break binary compatibility if
they update to this version of libpcap.
Instead, we map from DLT_ values to LINKTYPE_ values when writing
savefiles, and map from LINKTYPE_ values to DLT_ values when reading
savefiles, so that savefiles don't have platform-dependent DLT_ values
in the header as the link type, they have platform-independent LINKTYPE_
values.
This means we don't need to make DLT_ATM_RFC1483, DLT_RAW, etc. have
platform-independent values starting at 100 - only the values in the
savefile header need to be like that.
For those PCAP_ENCAP_ codes corresponding to DLT_ codes that are
(believed to be) the same in all BSDs, the PCAP_ENCAP_ codes have the
same values as the corresponding DLT_ codes.
For those PCAP_ENCAP_ codes corresponding to DLT_ codes that were added
in libpcap 0.5 as "non-kernel" DLT_ codes, or had their values changed
in libpcap 0.5 in order to cope with the fact that those DLT_ codes
have different values in different systems, the PCAP_ENCAP_ codes have
the same values as the corresponding DLT_ codes.
We add some additional PCAP_ENCAP_ codes to handle IEEE 802.11 (which
currently has its link-layer information turned into an Ethernet header
by at least some of the BSDs, but John Hawkinson at MIT wants to add a
DLT_ value for 802.11 and pass up the full link-layer header) and the
Classical IP encapsulation for ATM on Linux (which isn't always the same
as DLT_ATM_RFC1483, from what I can tell, alas).
"pcap-bpf.c" maps DLT_ codes to PCAP_ENCAP_ codes, so as not to supply
to libpcap's callers any DLT_ codes other than the ones that have the
same values on all platforms; it supplies PCAP_ENCAP_ codes for all
others.
In libpcap's "bpf/net/bpf.h", we define the DLT_ values that aren't the
same on all platforms with the new values starting at 100 (to keep them
out of the way of the values various BSDs might assign to them), as we
did in 0.5, but do so only if they're not already defined; platforms
with <net/bpf.h> headers that come with the kernel (e.g., the BSDs)
should define them with the values that they have always had on that
platform, *not* with the values we used in 0.5.
(Code using this version of libpcap should check for the new PCAP_ENCAP_
codes; those are given the values that the corresponding DLT_ values had
in 0.5, so code that checks for them will handle 0.5 libpcap files
correctly even if the platform defines DLT_RAW, say, as something other
than 101. If that code also checks for DLT_RAW - which means it can't
just use a switch statement, as DLT_RAW might be defined as 101 if the
platform doesn't itself define DLT_RAW with some other value - then it
will also handle old DLT_RAW captures, as long as they were made on the
same platform or on another platform that used the same value for
DLT_RAW. It can't handle captures from a platform that uses that value
for another DLT_ code, but that's always been the case, and isn't easily
fixable.)
The intent here is to decouple the values that are returned by
"pcap_datalink()" and put into the header of tcpdump/libpcap save files
from the DLT_ values returned by BIOCGDLT in BSD kernels, allowing the
BSDs to assign values to DLT_ codes, in their kernels, as they choose,
without creating more incompatibilities between tcpdump/libpcap save
files from different platforms.
having a pcap open. One could argue that this and the existing
compiler should be factored in common routines, but I was trying to
make it clear that this wouldn't break the existing code.
from Greg Troxel <gdt@ir.bbn.com>
guy