pcap_dumper_t. (Just doing an "ftell()" on the result of
"pcap_dump_file()" won't necessarily work on Windows, as Microsoft, in
their infinite wisdom, have multiple different versions of the C library
runtime, and if a DLL is built using one version, and another DLL or an
executable is built with another version, file descriptors and FILE *'s
opened in one of them cannot be used in the other.)
encapsulation with an "MTP2 plus pseudo-header" encapsulation. Get rid
of "rawss7.h", as the LINKTYPE_RAWSS7 it's mainly dedicated to explain
was never implemented. Update savefile.c for the changes.
rename it again to DLT_PPP_PPPD, and rename other #defines to match.
Add backwards-compatibility #defines of DLT_PPP_WITH_DIRECTION and
DLT_LINUX_PPP_WITHDIRECTION for software that used them.
that require it, and make pcap_fddipad private to the code generator, as
that's the only place that needs it (ideally, all *its* state should be
local as well). This makes opening an FDDI device, on platforms where
the padding is supplied as part of the packet, and opening other types
of devices or opening savefiles in the same program work better, as you
don't have to be sure you compile the filter for a given pcap_t before
opening the next pcap_t.
we're about to apply the filter, so that if it's changed by a callback
routine, we get the current filter, rather than the one in effect when
we started the loop.
"pcap_dump_fopen()" to open a pcap_t given a FILE *, and add
"pcap_dump_fopen()" to open a pcap_dumper_t given a FILE *.
On Windows, if we're opening the standard input, put it in binary mode.
Check for errors from "sf_write_header()" and return an error if we get
an error.
capture file if the standard I/O stream is stdin (i.e., if the file name
was "-"). Thanks to Joshua Blanton <jblanton@masaka.cs.ohiou.edu> for
catching this one.
the first byte (0xff) of the PPP header (0xff03) is tweaked to accomodate
the direction 0x00 = IN, 0x01 = OUT
the DLT_ supports the libpcap tokens "inbound" and "outbound"
sure that all values from 100 to the current maximum value are in use;
put in comments to indicate for what purpose the reserved ones are
reserved.
Note in the "don't just grab a value and use it yourself" comment why
you shouldn't use values below 100 or above the maximum value you see in
the file.
DLT_IEEE802_11_RADIO_AVS for future use with the AVS radio header.
Fix a comment.
Put in reserved LINKTYPE_USERn values corresponding to the reserved
DLT_USERn values.
caplen and len fields in the pre-2.3 order).
Move the version number checking to the open-file code; store a
tri-state (definitely swapped, definitely not swapped, maybe swapped)
value in the savefile information and use that when processing packets.
reading packets from a pcap_t, and make "pcap_read()" call it. That
removes the last place where we have to check for a pcap_t that refers
to a DAG card rather than a live capture, so get rid of the "is_dag" flag.
handles setting a filter for a pcap_t. Have "pcap_setfilter()" call it,
rather than being a per-platform function. The per-platform functions
don't need to check for an offline capture any more, as they're not
called for an offline capture (and the ones that just call
"install_bpf_program()" don't need to exist at all).
getting statistics for a pcap_t. Have "pcap_stats()" call it, rather
than being a per-platform function; have stats routines for non-live
pcap_t's that return an error.
the platform-dependent part of closing a pcap_t (and the
live-vs-savefile part as well, so that function must close the file
descriptor and free up any buffers allocated).
In the Digital UNIX support, add in a check for a memory allocation
failure.
which supplies different headers from BSD ARCNET, and fixes to the
ARCNET code generator (the protocol ID field is 1 byte, so the values
for it shouldn't be byte-swapped).
Whitespace cleanups.
The "NetBSD-style" ARCNET headers are used in other BSDs as well, so
just call them "BSD-style".
supplied by Linux's ARCNET code aren't the same as the ones supplied by
NetBSD's ARCNET code.
Fix up some LINKTYPE_ values to match the corresponding DLT_ values.
(There is no released version of libpcap/tcpdump that supports their
previous values.)
unfortunately, we can't fix "pcap_dump()" and "pcap_dump_close()" to do
that, as any application that tests the return value would fail to work
correctly if linked at runtime with an older libpcap, but we should
perhaps introduce "pcap_dump_ex()" and "pcap_dump_close_ex()" routines
that do return a success-vs-vailure indication.
capture device having only an RFC 2625 Network_Header field, not a Fibre
Channel frame header; rename the constants to emphasize this and to
leave room for another "raw Fibre Channel" link-layer type, if it's ever
needed.
reserved for future use; they're being used.
Move other currently-being-used LINKTYPE_ values above the "reserved for
future use" comment, to make it clear which types are reserved and which
are already in use.
Note that 100 through 103 shouldn't be used for new DLT_ types.
live captures with a "cooked" (SOCK_DGRAM) rather than a "raw"
(SOCK_RAW) PF_PACKET socket; it includes a bunch of the fields from the
"struct sockaddr_ll" you get in a "recvfrom()", including the Ethernet
protocol field.
This requires us to rewrite the BPF program if we're stuffing it into
the kernel; as long as we're doing *ex post facto* rewriting, we might
as well also do the "ret <snaplen>" -> "ret 65535" fixup there as well,
rather than in the code generator.
means that we should "htonl()" it before using it in BPF expressions
*but*, if we're reading a capture file from a machine with the opposite
byte order from ours, we should byte-swap it before "htonl()"ing it.
Handle OpenBSD DLT_LOOP as well - it's like DLT_NULL except that the AF_
value is in *network* byte order.
Don't support checking for inbound or outbound packets except on those
data link types that supply an inbound/outbound qualifier (DLT_SLIP and
DLT_PPP) - this came from OpenBSD's libpcap, delta 1.12 to "gencode.c".
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.
Kuznetzov's patched version of libpcap; we ignore the additional fields
it adds to the per-packet header. Red Hat Linux 6.2 uses that patched
version, and some other Linux distributions might do so as well.
(This won't handle an early version of his patch, which changed the
per-packet header but didn't change the magic number; that early version
appears in Red Hat Linux 6.1.
Doing that requires a heuristic test, wherein we assume the file is
standard libpcap and try to read the first and second records, and, if
the header of the second record looks like garbage, assume that the file
came from that early version, and that we're therefore reading random
packet data when we think we're reading the header of the second packet.
As we don't then want to seek back to the first packet, because we want
to continue to allow libpcap-based programs such as tcpdump to read from
pipes, we'd have to buffer data from the file so that we can go back and
re-read it. I leave this for later.)