| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This will avoid some differences when checking in different time zones.
We now run the tests without the '-t' option. This will allow to get
problems/changes in time printing functions.
Update the output of the tests accordingly.
Moreover:
Add the '-#' option to better identify a packet when there is a difference
in output.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Process bits 29, 30, and 31 in code that's independent of what namespace
we're in:
If we're switching to the radiotap namespace, reset the bit numbers to
start back at 0.
If we're switching to a vendor namespace, get the vendor OUI and
subspace, and the skip length.
Keep trace of which namespace we're in.
If we're *in* a vendor namespace, skip over the data specified by the
skip length (and reset it, as we've processed all the vendor namespace
data and, if there's a subsequent bitmap in the same namespace,
there's nothing more to process. Use cpack_align_and_reserve() to
skip that, so we check that we don't go past the end of the packet
data.
Fixes GitHub tcpdump issue #498.
This removes some bogus errors; update the test output to reflect that.
|
| |
|
|
| |
Fix test file while we're at it.
|
| | |
|
| |
|
|
| |
"dB".
|
| |
|
|
|
| |
We don't print anything from the MAC header without -e, even with -v -
except for the Protected flag, which we print regardless of -e or -v.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
I modified the mac80211 and ath9k kernel module such that extra
information regarding rssi, etc are available, which is why I needed the
extra bitmap. Capturing the packets is simply a matter of using tcpdump
-i wlan0 -w dumpfile.
|
