Skip to content

tap: fix radiotap TSFT 8-byte alignment (fixes wholesale frame drops on EXT radiotap) - #1499

Open
hectornvm wants to merge 1 commit into
nzymeorg:masterfrom
hectornvm:fix/radiotap-tsft-alignment
Open

hectornvm wants to merge 1 commit into
nzymeorg:masterfrom
hectornvm:fix/radiotap-tsft-alignment

Conversation

@hectornvm

Copy link
Copy Markdown

Fixes #1498

What

Add the radiotap-spec-required 8-byte alignment before the TSFT field in tap/src/protocols/parsers/dot11/dot11_header_parser.rs. When the present-flags word carries the EXT bit (e.g. ath9k_htc emits two present words), the field area starts at a 4-byte-misaligned offset; without the alignment, the channel field is read 4 bytes early and lands on 0x0000, tripping the frequency == 0 bail — discarding every frame.

Why

See #1498 for full detail. Symptom: a tap only ever records the single strongest AP while raw tcpdump on the same interface sees dozens; deauth/disconnect timeline events never fire because frames never make it past the header parser.

Verification

Tested with a USB Atheros AR9271 (ath9k_htc) tap on Ubuntu, pinned channel:

before after
"bad reported frequency" failures / 30 s 6,783 0
beacons parsed / 30 s 0 1,744
distinct BSSIDs recorded (5 min) 2 (hours) 42+

The radiotap parser read the TSFT field without applying the spec's
8-byte alignment. With extended present-words (EXT bit set, e.g. on
ath9k_htc), the field chain shifts by 4 bytes and the channel field
reads 0, causing every frame to bail with 'bad reported frequency'
and no 802.11 data to be recorded.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

tap: frames dropped wholesale ('bad reported frequency') on EXT-extended radiotap (missing TSFT 8-byte alignment)

1 participant