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.
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.
the declaration of "utimes()" collides with the declaration that SunOS
5.5.1 and later, at least, *do* have. (5.5.1 doesn't declare
"snprintf()", even though it has "snprintf()", so we declare it here; we
declare some others that don't cause problems.)
"linux-includes/netinet/if_ether.h" to "ethertype.h", and remove
includes of <netinet/if_ether.h> from files that only include it to get
ETHERTYPE_ values defined.
change the directory mode to 755 after making the directory, so that the
directory is publicly readable and searchable even if the user doing the
"make install" has a umask that takes away public read and search
permissions. (I think that's been a problem at least once - somebody
had trouble configuring and building Ethereal, probably because
"/usr/local/include/net" wasn't publicly readable and searchable, and my
suspicion is that somebody did "make install-incl" or "make install" of
libpcap when their umask was 027.)
Fix the check for directory existence done before making
"$(DESTDIR)$(includedir)" and "$(DESTDIR)$(includedir)/net" to check for
the existence of those directories, not for the existence of
"$(DESTDIR)$(libdir)".
names, e.g. "alphaev56", rather than just "alpha", so, in
"AC_LBL_UNALIGNED_ACCESS", we should check for "alpha*", rather than
"alpha", in our test for platforms we *know* shouldn't do unaligned
accesses (Digital^H^H^H^H^H^H^HTru64 UNIX, by default, may just catch
the alignment trap, complain on the console, and then simulate the
unaligned access, but that's slow - and, in one test, didn't appear to
prevent all the faults from unaligned accesses).
FDDI headers to align the payload on a 4-byte boundary; for example,
Linux/Alpha doesn't appear to do so, which causes filter expressions not
to work correctly on FDDI on Linux/Alpha.
The "__alpha" test was really intended to check for DEC
OSF/1^H^H^H^H^H^H^H^H^HDigital UNIX^H^H^H^H^H^H^H^H^H^H^H^H Tru64 UNIX,
so test "__osf__" instead.
on the asbestos suit). As we don't have a bug tracking system or
task manager we need some way to record a list of tasks. I think this
is the easiest way. Discussion on -workers please.
the equivalent PCAP_ENCAP_ codes to the corresponding PCAP_ENCAP_ code
so that the code generator need check only the PCAP_ENCAP_ codes.
Handle PCAP_ENCAP_PPP_HDLC just like PCAP_ENCAP_PPP.
DLT_NULL in OpenBSD's libpcap, and I'm not sure what the right way to
handle it is yet - for now, this lets the OpenBSD folk merge their
DLT_LOOP support in if, as, and when they pick up the next version of
libpcap.
RFC 1662, or Cisco point-to-point with HDLC framing, as per seciont
4.3.1 of RFC 1547; there's always an address and control octet at the
beginning of these packets, but they're not necessarily 0xff 0x03),
which we map to PCAP_ENCAP_PPP_HDLC.
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.
format (file header or per-packet header format, or interpretation of
any of the fields in those headers) without getting a new magic number
from "tcpdump-workers@tcpdump.org", and to make sure that libpcap can
still read files with the existing magic numbers, not just files with
the new magic number and record formats.
(There have been at least three libpcap changes I know of that have
changed the header formats, or the interpretation of fields in those
headers, without changing the magic number. I would like not to ever
have any other such changes happen ever again.)
network device, so that
1) you can infer from the message whether the program is using
the old version of the code to get the PPA (which didn't work
all that well) or the newer version, without having to prod a
user complaining about tcpdump/Ethereal/whatever not working
to tell you which version of libpcap they're using;
2) programs can perhaps check the error message returned by
libpcap and, if it's the old error message, tell the user
that the problem may be that they're using an old libpcap.
#ifdef __cplusplus
extern "C" {
#endif
...
#ifdef __cplusplus
}
#endif
so that C++ code can include these header files and correctly call the
C-language routines they declare.
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.)
Don't put the entire SUNOS4 directory into the tarball, as that may drag
in the CVS directories; instead, put in the files that actually belong
there.
Put "config.h.in" into the list in sort order.
the classic BSD "F" flag, which tells it to *exclude* certain files, is
unnecessary; furthermore, some versions of tar may not support it, and
GNU tar, as appears in FreeBSD and perhaps other BSDs, and in Linux,
interprets the "F" flag as meaning "run, at the end of each archive
volume, the script whose name is given as an argument to the flag", so
it's not even syntactically compatible with the classic "F" flag.
The latter problem causes "make tar" to fail; we remove the "F" flags to
fix the problem.
guy