Gisle Vanem reported in GH #881 that in Windows tcpdump failed to link
with static AirPcap because the latter seems to include its own variant
of cpack code:
airpcap_static.lib(RadiotapDecode.obj) : error LNK2005: _cpack_init
already defined in cpack.obj
airpcap_static.lib(RadiotapDecode.obj) : error LNK2005: _cpack_uint16
already defined in cpack.obj
airpcap_static.lib(RadiotapDecode.obj) : error LNK2005: _cpack_uint32
already defined in cpack.obj
airpcap_static.lib(RadiotapDecode.obj) : error LNK2005: _cpack_uint64
already defined in cpack.obj
airpcap_static.lib(RadiotapDecode.obj) : error LNK2005: _cpack_uint8
already defined in cpack.obj
He confirms this change resolves the issue.
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.
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.
