It appears that the reason why a read from a BPF device
sometimes gets EFAULT on AIX might be that the pages into which
you're reading haven't been ZFODded into existence the first
time a read is done; "memset()"ting the buffer to all zeroes
appears to mostly mitigate the problem, so we do that on AIX.
Fix an error in a "sysconfig()" call.
"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.