"pcap_next_ex()" a pointer to pointer to const u_char, to squelch
compiler warnings and to let the caller know that they're not supposed
to modify the data), and additional explanation in "pcap_next_ex()" of
the return-code conflict.
with some interfaces (see bug 599857 in the SourceForge list of libpcap
bugs), and, even if it doesn't cause problems, it's different from
what's done on other platforms.
where we wire in the idea that it can't handle unaligned accesses. (I
don't know why the test program doesn't work - but perhaps the test
program is the wrong answer anyway, as it doesn't work when
cross-compiling.)
is not defined by the configure or build procedure, e.g. building for
WinCE SuperH, this probably won't work, as it'll assume unaligned
accesses are OK.
"__arm__" to the list of #defines we check for if LBL_ALIGN isn't
defined, so that on ARM we assume unaligned accesses are unsafe (which
they are, on at least some ARM processors).
non-".devel" builds, with no automatically-generated dependencies,
"version.h" will be built before we try to build "pcap.o" ("pcap.c"
includes "version.h", so we need it to be built).
probably true in all versions), "sbh_drops" is "the cumulative number of
input messages that this instance of bufmod has dropped due to flow
control or resource exhaustion."
"Cumulative" presumably means "don't add it to the count of drops, as
it's *already* a count since the capture started; just set the count of
drops to the value". Do so.
version of Red Hat Linux, HP-UX 11.00, and MacOS X 10.1, if a string in
a shared library is static, and returned by a function in that library,
the return value of that function, when called from a program, will
reflect the contents of the string in the version of the shared library
with which the program is running, not the version with which it's
linked.
Therefore we can just generate a definition of the version string and
put it into "version.h", which means that VERSION can contain any string
(as long as " and \ are escaped with \) rather than having to be N.M or
N.M.MM.
libpcap; it generates the string at run time on the first call, so that
it's not a constant string - in at least some UNIXes, constant data in a
shared library is kept separate from the library code, and is bound into
applications linked with that library at link time, not at run time, so
a constant string (such as "pcap_version[]") can reflect the version of
the library with which the application was built, not the version with
which it's running.
Document it, in the hopes that vendors will be less likely to omit it
from their libpcaps (unlike "pcap_version[]", which is absent from some
vendors' libpcaps).
AIX, we choose BPF, not DLPI, by default; we won't necessarily choose
BPF if no libpcap-based program has been run since booting, as libpcap
(both IBM's and, now, ours) create BPF devices and load the driver if
that hasn't already been done since booting).
create the BPF device nodes if necessary, and rename our "bpf.h" to
"pcap-bpf.h" and install it in "/usr/include", so that "pcap-bpf.c" gets
the system's bpf.h file if it includes <net/bpf.h> - on AIX, it needs to
get an AIX-specific structure from that header in order to support
loading the driver and creating the nodes.
Update "packaging/pcap.spec".
beginning of the packet if the packet has an 802.2+SNAP header (3 bytes
802.2, 5 bytes SNAP), and 3 bytes from the beginning of the packet if it
has only an 802.2 header, just as is the case for DLT_ATM_CLIP, so go
back to handling them both with the same case.
Restore some comments asking whether we need to check the SSAP when
testing the 802.2 header for protocol types.
Clean up white space.
RFC 1188, RFC 1042, and RFCs 1483 and 2225 specify that SNAP
encapsulation is used for IP, not LLC encapsulation with LLCSAP_IP and,
in fact, that's what most if not all IP traffic over FDDI, 802 networks,
and LLC-encapsulated ATM use; go back to treating those link-layer types
the same way other link-layer types are handled.
chunk we ask bufmod to send upstream.
Yes, uint_t is always 32 bits, at least as I read the Solaris 8 code.
The chunk size is 8192, not 0, by default.
Don't do the chunk size stuff if we don't have bufmod.
673958, make two changes on Solaris:
don't set SB_NO_DROPS - doing so means that bufmod doesn't drop
packets, so it can't report the number of drops, but packets
probably still get dropped *somewhere*, if for no other reason
than that the system refuses to allocate more mblks/dblks, even
if it doesn't discard messages that arrive at the stream head if
it's full;
set the chunk size to 65536, as otherwise packets are dropped
too easily.
snoop also appears not to set SB_NO_DROPS and also appears to set the
chunk size to 65536, so that's probably the right thing to do.
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.)
guy