The Story That Explains 802.11 Management Frames
Every one of those actions — announcing the venue, checking IDs, issuing wristbands, logging exits, ejecting troublemakers — is a Management frame in Wi-Fi. The bouncer never touches the actual conversations happening inside the club (that's Data frames), and never manages the queue physics of who talks when (that's Control frames). His entire job is administering membership.
Understanding this one analogy is 80% of understanding 802.11 Management frames.
Management frames are the category of 802.11 frames identified by Type = 00 in the Frame Control field. They handle everything about the wireless connection itself — discovery, joining, leaving, and identity — but never carry your actual data. They are also the frames most involved in Wi-Fi attacks that have made international headlines, because for most of Wi-Fi's history they were sent in the clear with no authentication whatsoever.
A quiet, idle laptop with Wi-Fi turned on will still transmit and receive hundreds of Management frames per minute — asking "are any of my saved networks nearby?", listening for Beacons, refreshing associations. Every one of those frames is a potential leak or attack surface if handled naively.
The Complete Management Subtype Map
Management frames all share Type = 00, but the 4-bit Subtype field tells the radio exactly which management job is being done. Here is the complete list you'll actually see in a modern capture.
| Subtype | Hex | Frame Name | Who Sends It | Purpose |
|---|---|---|---|---|
| 0000 | 0x00 | Association Request | Client (STA) | "I'd like to formally join your network" |
| 0001 | 0x01 | Association Response | Access Point | "Welcome — here's your AID" (or refused) |
| 0010 | 0x02 | Reassociation Request | Client | "I'm roaming — please move me from that AP to you" |
| 0011 | 0x03 | Reassociation Response | Access Point | "OK, I've picked up your session" |
| 0100 | 0x04 | Probe Request | Client | "Is any network within earshot? Answer me directly" |
| 0101 | 0x05 | Probe Response | Access Point | "Yes I am — here are my details" |
| 1000 | 0x08 | Beacon | Access Point | Broadcast advertisement, ~10 per second |
| 1001 | 0x09 | ATIM | Client (ad-hoc) | Announcement in ad-hoc mode (rarely seen) |
| 1010 | 0x0A | Disassociation | Either side | "I'm leaving the network — polite goodbye" |
| 1011 | 0x0B | Authentication | Either side | Identity handshake (host of WPA3's SAE exchange) |
| 1100 | 0x0C | Deauthentication | Either side | "Get off — session terminated immediately" |
| 1101 | 0x0D | Action | Either side | Extended requests — Block ACK setup, radio measurements, etc. |
Anatomy of a Beacon Frame — Every Byte Explained
The Beacon (subtype 0x08) is the most-transmitted management frame on Earth. Every AP sends one roughly every 100 milliseconds. It is what puts a network name in your Wi-Fi list without you doing anything.
Probe Requests — How Your Phone Leaks Its History
When your device is not connected to Wi-Fi, it does not just sit and wait for Beacons. It actively transmits Probe Request frames (subtype 0x04) asking "is anyone I know here?". Older devices did this by literally naming every saved network in the request itself — a passive listener at an airport could reconstruct where you had been by watching your phone shout for "Starbucks_London", "OfficeGuest_Paris", and "Airbnb_Reception_Berlin".
| Probe Contains | Leaks |
|---|---|
| Directed SSID: "HomeWiFi_Smith" | Home network name |
| Directed SSID: "BA_Lounge_LHR" | Recent travel |
| Real MAC address | Unique device identity |
| Vendor IE fingerprint | Device manufacturer |
| Probe Contains | Leaks |
|---|---|
| Wildcard SSID (broadcast) | Almost nothing |
| Locally-administered random MAC | Rotates per network |
| Randomized sequence numbers | Harder to correlate |
| Fewer distinguishing IEs | Harder to fingerprint |
A MAC address has 48 bits. The second-least-significant bit of the first byte is the locally-administered flag. If it is 1, the MAC is randomised or manually set — not the factory-burned one. Every randomised MAC generated by iOS or Android has this bit set, which is how you can tell a real MAC from a randomised one at a glance.
Authentication & Association — Status Codes
Once a device has found a network via Beacon or Probe Response, it goes through two handshakes: Authentication (proving identity) followed by Association (formally joining). Both request/response pairs carry a Status Code field that tells you whether the step succeeded — and if not, why.
| Status Code | Meaning | When You'd See It |
|---|---|---|
| 0 | Successful | Normal join — the vast majority of frames |
| 1 | Unspecified failure | Vague — often driver-side incompatibility |
| 10 | Cannot support all capabilities | Client requested a mode the AP does not offer |
| 12 | Association denied — other reason | MAC filtering, AP full, etc. |
| 15 | 4-Way Handshake timeout | Wrong Wi-Fi password (WPA/WPA2/WPA3) |
| 17 | AP unable to handle additional STAs | Access point is at its client-count limit |
| 37 | Request declined | Enterprise 802.1X policy refusal |
Deauthentication & Disassociation — Reason Codes
Deauthentication (subtype 0x0C) is the "you're out, now" frame. Disassociation (subtype 0x0A) is its politer sibling — the authentication state is preserved, only the current session is dropped. Both carry a Reason Code saying why.
| Reason | Meaning | Typical Trigger |
|---|---|---|
| 1 | Unspecified reason | Generic — often what attack tools send |
| 2 | Previous authentication no longer valid | Session key expired or rotated |
| 3 | Deauth because leaving | Sent when a client roams away legitimately |
| 4 | Disassoc due to inactivity | Idle timeout — client went silent too long |
| 5 | AP unable to handle all STAs | AP is overloaded, dropping clients |
| 6 | Class 2 frame from non-authenticated STA | Protocol violation |
| 7 | Class 3 frame from non-associated STA | Protocol violation |
| 15 | 4-Way Handshake timeout | Key negotiation failed |
Until 802.11w (2009) added Protected Management Frames, anyone with a Wi-Fi radio in monitor mode could forge a deauthentication frame claiming to be from your AP, and your device would obey it without question. This one design decision is the root cause of every deauth-based attack in the news since 2010.
Information Elements — The TLV Payload System
Everything inside a Management frame's body is packed as Information Elements (IEs) in a classic Type-Length-Value structure. This is how Wi-Fi has stayed extensible for 25 years — a new feature just gets a new IE number without breaking old parsers.
Example — Encoding the SSID "HomeWiFi"
# Raw bytes on the air
00 # Tag: SSID (element ID 0)
08 # Length: 8 bytes follow
48 6F 6D 65 57 69 46 69 # 'H' 'o' 'm' 'e' 'W' 'i' 'F' 'i'Example — Hidden Network (SSID cloaking)
00 # Tag: SSID
00 # Length: 0 — network name deliberately omitted
# No value bytes at allA cloaked SSID is only missing from Beacon frames. The moment any client legitimately connects to that network, its own Probe Request contains the real name in cleartext. Anyone in radio range can capture it. Hiding the SSID is a convention, not a security control.
Animated Diagram — An Evil Twin Attack Step by Step
This is the attack that ties SSID, MAC address, and deauthentication together. Watch how a rogue access point uses all three Management frame concepts to hijack a victim.
Practical Example — Reading Management Frames in Wireshark
Filters — Catch Only What You Want
# All management frames
wlan.fc.type == 0
# Only Beacons
wlan.fc.type_subtype == 0x08
# Only Probe Requests — see what devices are asking for
wlan.fc.type_subtype == 0x04
# Only Deauth frames — highlight potential attacks
wlan.fc.type_subtype == 0x0c
# Beacons for a specific SSID
wlan.fc.type_subtype == 0x08 and wlan.ssid == "HomeWiFi"
# Any frame claiming to come from a specific AP MAC
wlan.sa == aa:bb:cc:11:22:33Attack tools like aireplay-ng and Wi-Fi Pineapple firmware almost always emit deauthentication frames with Reason Code 1 ("Unspecified"). Real APs typically send more specific codes (3, 4, 15). A sudden burst of Reason-Code-1 deauths in a capture is the single most reliable signature of an active deauth attack.
Real-World Cases — When Management Frames Made the News
According to the U.S. Department of Justice indictment later filed against the same officers, the same kit had already been used in Rio de Janeiro, Lausanne, and Kuala Lumpur against anti-doping bodies and the MH17 investigation team. The technique relied on exactly what this tutorial covers: capturing Beacons and Probe Requests to map the target's networks, spoofing SSIDs and MAC addresses to impersonate trusted APs, and injecting deauthentication frames to force targeted devices onto rogue networks the attackers controlled.
Guests kicked off their own hotspots by these forged deauth frames were then forced to pay Marriott between $250 and $1,000 per device to use the hotel's Wi-Fi. The FCC Enforcement Bureau later issued a formal advisory stating that Section 333 of the Communications Act prohibits weaponising management frames this way, regardless of whether the equipment was originally sold as a "security" product.
The reason the attack keeps working is baked into the design of Management frames: SSID strings and MAC addresses in Beacons are cleartext identifiers with no cryptographic binding to the network operator. Any radio can transmit any SSID. Client devices are then trained to auto-associate to whichever AP advertising a saved SSID has the strongest signal — a default that rewards the closer, louder attacker.