I don't see any beacon in your capture, only Probe Response (which can contain info seen in Beacon + more).
It looks like this:Usually it's filtered by default, have to enable their capture (can be very annoying)
I find a little bit strange those ACKs and CTSs coming from different MAC addresses, but could be valid in your setup.
It looks like you are using protected management frames ( lowercase 'p' flag) .1.. .... = Protected flag: Data is protected
Maybe events 49 are related, in this case also these frames are using encryption, and if there is a mismatch DEAUTH and DISSOCIATE messages are going to be ignored (as a protection). I think this is part of the newer WPA3:
It looks like this:
Code:
208912108.931096191Beacon frame, SN=714, FN=0, Flags=........C, BI=500, SSID=... Broadcast802.11
What do you mean by "the QoS messages are NOT consistent" ?usage: airodump-ng <options> <interface>[,<interface>,...]
Options:
--ivs : Save only captured IVs
--gpsd : Use GPSd
--write <prefix> : Dump file prefix
-w : same as --write
--beacons : Record all beacons in dump file
--update <secs> : Display update delay in seconds
--showack : Prints ack/cts/rts statistics
...
I find a little bit strange those ACKs and CTSs coming from different MAC addresses, but could be valid in your setup.
It looks like you are using protected management frames ( lowercase 'p' flag) .1.. .... = Protected flag: Data is protected
Maybe events 49 are related, in this case also these frames are using encryption, and if there is a mismatch DEAUTH and DISSOCIATE messages are going to be ignored (as a protection). I think this is part of the newer WPA3:
Protected Management Frames (PMF) protects unicast and broadcast management frames and encrypts unicast management frames. This means wireless intrusion detection and wireless intrusion prevention systems now have fewer brute-force ways to enforce client policies.
Statistics: Posted by gmx — Tue Dec 31, 2024 7:36 pm