support Linux Frame Relay ARPHRD_FRAD as Frame Relay with an FR
header;
support Linux Frame Relay ARPHRD_DLCI in cooked mode;
current Linux kernels use the name ARPHRD_CISCO for Cisco HDLC
(513).
Fix the pcap-dag atexit() handler for non-execing child
processes. Previously a fork()/exit() would stop the packet
capture (doh!).
Add a couple of optimizations.
assume Cisco HDLC, look at the first frame to see whether it has a
PPP-in-HDLC-like-frameing header, and use DLT_PPP_SERIAL for that and
DLT_CHDLC otherwise.
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.
and if it differs from the wpcap.dll version string, report both
versions (just in case somebody happens to have different versions of
wpcap.dll and packet.dll installed).
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.)
guy