This can prevent bizarre failures if, for example, you've done a
configuration in the top-level source directory, leaving behind one
config.h file, and then do an out-of-tree build in another directory,
with different configuration options. This way, we always pick up the
same config.h, in the build directory.
Add EXTRACT_IPV4_TO_HOST_ORDER() and EXTRACT_IPV4_TO_NETWORK_ORDER();
the former extracts a possibly-unaligned IPv4 address, in network byte
order, returning a uint32_t in host byte order, and the latter extracts
a possibly-unaligned IPv4 address, in network byte order, returning a
uint32_t in *network* byte order. Some APIs take an address in network
byte order, and some operations are more easily done in host byte order,
so both are useful.
Remove the structure wrappers around nd_ipv4 and nd_ipv6; that makes it
easier to pass variables of those types to functions/macros that take a
byte pointer as an argument (because they might be used either with
pointers to structure members or raw buffer pointers), and the structure
probably wouldn't do much to prevent people from using EXTRACT_BE_U_4()
when they really want to extract the value in *network* byte order;
using the above EXTRACT_IPV4_ calls should do more to encourage that.
Have separate cpack_ routines for signed and unsigned numbers, with the
signed ones using _S_ extract macros. That way, we can do more type
checking.
Add EXTRACT_LE_S_ macros.
Use signed variables for IEEE80211_RADIOTAP_TX_ATTENUATION and
IEEE80211_RADIOTAP_DB_TX_ATTENUATION, rather than using unsigned
variables that we cast to int.
Also, use EXTRACT_U_1() in cpack_uint8.
Now all the macros have a name meaning a count in bytes.
With _S_: signed, _U_: unsigned
e.g.:
EXTRACT_BE_32BITS -> EXTRACT_BE_U_4
EXTRACT_LE_32BITS -> EXTRACT_LE_U_4
...
EXTRACT_BE_INT32 -> EXTRACT_BE_S_4
and have:
EXTRACT_8BITS -> EXTRACT_U_1
EXTRACT_INT8 -> EXTRACT_S_1
The purpose of this macro was to enable the file-by-file switch to NDO,
after which only tcpdump.c had a use of it and the definitions guarded
by it. Update tcpdump.c not to require them any more and dismiss the
unused definitions.
And, as we require at least autoconf 2.61, and as autoconf 2.61 and
later have AC_TYPE_UINTn_T and AC_TYPE_INTn_T macros, we use them to
define the uintN_t and intN_t macros if the system doesn't define them
for us.
This lets us get rid of bitypes.h as well.
This bug was discovered and pinned down by Wim Torfs.
The code in question handles DLT_IEEE802_11_RADIO datalink type, which
consists of a variable-sized header, a variable number of fields and the
actual 802.11 frame. The integers contained in the fields are aligned,
properly extracting them is exactly the purpose of the existing "cpack"
module. The issue with the current code is that it sets alignment base
for cpack at the end of the variable-sized header, in other words,
64-bit integers would be properly extracted only so long as the header
is 64-bit long, which only happens when the total number of bitmaps in
it is odd (the minimum number of bitmaps is one). Once this condition
isn't met, as is with two bitmaps, decoding becomes incorrect. The
reporter's point that the alignment base must be the beginning of the
variable-sized header is accurate.
This commit adds a new cpack_advance() function to fast-forward the
"c_next" pointer of a cpack_state context by an arbitrary number of
octets. The ieee802_11_radio_print() function now uses it to skip the
header and all its bitmaps, and the alignment base is now the header
start.
Based on patches from an anonymous donor, support the radiotap RX flags and
MCS fields, and the vendor namespace, and, if Channel and XChannel are
both present, use XChannel, not Channel.
Do not try to look up a rate for an MCS value from the Rate field; you
cannot map an MCS value to a rate without also knowing the channel width
and guard interval length.
from a buffer. The cpack library expects for words to appear on
their natural boundaries.
The radiotap (802.11 + radio information) capture format uses cpack
to extract the radio information fields.
