for -o and Flex's support for it in a way that lets us more easily fail
if Lex/Flex fails (so that we don't try to compile a bogus scanner.c
that might be generated; that appears to have happened on at least one
occasion, with the resulting scanner.o missing some functions, causing
weird errors in configure scripts for programs using libpcap), and also
prepares us to handle newer versions of Flex where we want Flex to
generate a header file so we don't get "defined but not declared"
warnings.
always 144 bytes long. However, some drivers on Linux use
ARPHRD_IEEE80211_PRISM, but sometimes or always supply an AVS header, so
we have to check whether the radio header is a Prism header or an AVS
header, so, in practice, it's variable-length.
Treat DLT_PRISM_HEADER as having a variable-length header, and generate
code to find the length of the Prism header that first checks for an AVS
header and, if we have an AVS header, gets the length from the header,
and otherwise just gets a length of 144. This fixes Sourceforge bug
1847574.
Sort various references to the radio headers (case labels, functions,
etc.) into the same order (Prism, AVS, radiotap), for consistency. Put
PPI after them all.
Handle 802.11 and 802.11-plus-radio-header with a common case when
initializing.
hopefully I'm inferring correctly from the mon_bin_poll() routine that,
even with purely-mmapped access, you can use select() or poll() to wait
for packets to arrive.
some sscanf() calls:
The first change involves a sscanf() that has '%n' in the format
string, which shouldn't be checked for in the return value
(stored in "ntok"). This is done correctly elsewhere in the code
(and even commented on) such that the return value is checked for
everything but the %n modifier.
And a few lines after this, a sscanf() is done for '%d' and the
return value is stored in "ret". However, the same exact line
from the above mishap is used here, not even checking the right
variable or number of conversions! It checks "ntok" for 2 when
it should check "ret" for 1.
Changing the behaviour when the ERF type is unknown, and for ERF
TYPE_PAD.
Unknown ERF types can always be captured as DLT_ERF. TYPE_PAD
records are dropped silently.
payload, the existing value of that offset is *not* in the X register -
the offset of the MAC header is in the X register. Load the register
containing the offset of the MAC payload, add 2 to it, and store the
result back in that register.
802.11 headers - we only handle the QoS bit and fields, for now.
Clean up various other things either in the process of doing that or as
a requirement for doing that.
before compiling an expression; pcap_compile() can be called more than
once, and some registers can now be allocated and not freed in the
process of code generation (for example, the register allocated to hold
the length of a radiotap header, which can't be freed until we're
finished generating all the code).
field in a capture file into:
a 16-bit link-layer type field (it's 16 bits in pcap-NG, and
that'll probably be enough for the foreseeable future);
a 10-bit "class" field, indicating the group of link-layer type
values to which the link-layer type belongs - class 0 is for
regular DLT_ values, and class 0x224 grandfathers in the NetBSD
"raw address family" link-layer types;
a 6-bit "extension" field, storing information about the
capture, such an indication of whether the packets include an
FCS and, if so, how many bytes of FCS are present.