How 802.11 Management Frames Work (And Why They're a Security Problem)

WiFi looks simple from the outside. You pick a network, type a password, and you're connected. Under the hood, your device and the access point are exchanging dozens of frames before a single byte of your data moves. Most of those frames have no authentication, no integrity protection, and can be spoofed by anyone within radio range.

This isn't a bug. It was a deliberate design decision made in the early 1990s - one that has caused decades of wireless security problems. To understand why, you need to understand how 802.11 frames are structured and what management frames actually do.

802.11 network architecture: stations communicate through access points connected to a distribution system. (Diagram: Wikimedia Commons, CC BY-SA 3.0)

Table of Contents

1. The Three 802.11 Frame Types
   
2. Management Frame Subtypes
   
3. Why Management Frames Are Unauthenticated
   
4. The Deauthentication Frame in Detail
   
5. Security Implications
   
6. 802.11w PMF: The Fix
   
7. BLEShark Nano and Management Frames
   
8. Shiver Mesh: Distributed Detection

The Three 802.11 Frame Types

Every 802.11 frame belongs to one of three categories. These categories are encoded in bits 2-3 of the Frame Control field at the start of every frame header.

Management frames (type 00) handle the overhead of wireless networking: finding networks, joining them, leaving them. They carry no user data. They exist purely to establish and maintain the wireless relationship between a client (station, or STA) and an access point (AP).

Control frames (type 01) manage access to the radio medium. RTS (Request to Send), CTS (Clear to Send), and ACK frames are all control frames. They coordinate who transmits when and confirm that frames were received. Without them, every device would try to transmit simultaneously.

Data frames (type 10) carry actual payload - your HTTP requests, TCP segments, DNS queries. Everything you think of as "internet traffic" rides in data frames. Data frames are encrypted after the WPA2 handshake completes.

The critical distinction: data frames benefit from WPA2 encryption. Control and management frames, in legacy 802.11, do not.

ARP spoofing uses forged frames to redirect traffic - similar to how forged management frames redirect WiFi clients. (Diagram: Wikimedia Commons, CC BY-SA 3.0)

Management Frame Subtypes

Within the management frame category, the subtype field (bits 4-7 of Frame Control) identifies exactly what the frame does. The most important subtypes are:

Beacon (subtype 0x08): The AP broadcasts beacons roughly 10 times per second. Each beacon contains the SSID, supported rates, channel, capability info, and various information elements (IEs). Beacons are how your device discovers networks. They're unencrypted by design - if they were encrypted, you couldn't see a network unless you already knew its key.

Probe Request (subtype 0x04): A client actively looking for a specific network (or any network) sends probe requests. The frame contains the SSID being searched for, or a wildcard SSID. Passive sniffers use probe requests to build maps of what devices are looking for.

Probe Response (subtype 0x05): An AP that matches a probe request responds with a probe response. Structurally similar to a beacon, but directed at the requesting client rather than broadcast.

Authentication (subtype 0x0B): Despite the name, 802.11 authentication (as used in WPA2 networks) is mostly a formality - an exchange of "open system authentication" frames that just says "yes, let's proceed." The actual credential verification happens at the EAPOL layer later. Pre-WPA networks used shared-key authentication here, which was cryptographically broken.

Association Request (subtype 0x00) and Association Response (subtype 0x01): After authentication, the client sends an association request listing its capabilities. The AP responds with an association ID (AID) and the agreed-upon parameters. The client is now associated.

Deauthentication (subtype 0x0C): Either side can send this to terminate the authenticated state. It includes a reason code explaining why. More on this below.

Disassociation (subtype 0x0A): Similar to deauthentication, but terminates the association while maintaining the authenticated state. In practice, most implementations treat these interchangeably - a disassociation frame kicks a client off the network just as effectively.

graph TD
    WIFI["802.11 Frame"] --> MGT["Management Frames
Type 00"]
    WIFI --> CTL["Control Frames
Type 01"]
    WIFI --> DATA["Data Frames
Type 10"]
    MGT --> BEACON["Beacon
0x08"]
    MGT --> PROBE_REQ["Probe Request
0x04"]
    MGT --> PROBE_RES["Probe Response
0x05"]
    MGT --> AUTH["Authentication
0x0B"]
    MGT --> ASSOC["Association
Req 0x00 / Res 0x01"]
    MGT --> DEAUTH["Deauthentication
0x0C"]
    MGT --> DISASSOC["Disassociation
0x0A"]
    CTL --> RTS["RTS"]
    CTL --> CTS["CTS"]
    CTL --> ACK["ACK"]
    style MGT fill:#333,color:#fff
    style DEAUTH fill:#633,color:#fff

802.11 frame type hierarchy - management frames (highlighted) are unencrypted and unauthenticated, making subtypes like deauthentication frames exploitable

sequenceDiagram
    participant C as Client (STA)
    participant AP as Access Point
    Note over AP: Beacon frames broadcast
SSID, channel, capabilities
    C->>AP: Probe Request
    AP->>C: Probe Response
    C->>AP: Authentication Request
    AP->>C: Authentication Response
    C->>AP: Association Request
    AP->>C: Association Response
    Note over C,AP: Client is now associated
    Note over C,AP: 4-Way Handshake follows for WPA2

Normal WiFi client association sequence - all management frames in this exchange are sent unencrypted, even on WPA2 networks

Why Management Frames Are Unauthenticated

The IEEE 802.11 standard was ratified in 1997. The design committee was solving hard problems with the technology available: unreliable radio propagation, limited processing power, power-constrained devices. Crypto was considered expensive - both in CPU cycles and battery life.

More fundamentally, management frames exist to bootstrap the connection. Before you've authenticated, before you've exchanged any keys, you need a mechanism to find APs and start the join process. Bootstrapping authenticated communication requires... communication to already be established. Something has to come first.

The designers chose simplicity: management frames would be sent in the clear. Any device can receive beacons. Any device can respond to probe requests. Authentication and security would happen at a higher layer, once the link was established.

This made sense in 1997 when WiFi was a convenience feature in office buildings. It became a significant problem when WiFi became the primary network connection for billions of people.

The consequence: anyone with a radio can send management frames that appear to come from any AP or client. There's no signature, no MAC, no HMAC. The source address field is just bytes - writable by anyone.

The Deauthentication Frame in Detail

The deauthentication frame is the most commonly abused management frame. Here's what it contains:

Frame Control (2 bytes): Type = 00 (management), Subtype = 1100 (0x0C = deauthentication). The To DS and From DS bits are both 0 for station-to-AP or AP-to-station deauth.

Duration (2 bytes): Network Allocation Vector (NAV) value. Controls medium reservation.

Address 1 (6 bytes): Destination address. If the AP is sending a deauth, this is the client's MAC. If a client is sending it, this is the AP's BSSID.

Address 2 (6 bytes): Source address / transmitter address. This is the MAC that the frame claims to be from. This is the field that gets spoofed in attacks.

Address 3 (6 bytes): BSSID. The AP's MAC address.

Sequence Control (2 bytes): Fragment number and sequence number. Used for reassembly and duplicate detection.

Frame Body (2 bytes minimum): Contains the reason code. The reason code is a 16-bit value indicating why the deauthentication is being sent.

Common reason codes:

• 1: Unspecified reason
• 2: Previous authentication no longer valid
• 3: Station is leaving (or has left) the IBSS or ESS
• 6: Class 2 frame received from non-authenticated station
• 7: Class 3 frame received from non-associated station

In deauth attacks, reason code 1 ("unspecified reason") or reason code 3 is most common. The reason code doesn't matter much - the client doesn't validate it. Receipt of the frame is what triggers disconnection.

FCS (4 bytes): Frame Check Sequence. A CRC-32 over the entire frame. This verifies frame integrity against radio corruption, but it's trivially recalculated for any crafted frame.

Total frame size: typically 26 bytes. Small, fast to craft, devastating in effect.

Security Implications

Deauthentication attacks: An attacker sends deauth frames with a spoofed source address (the AP's BSSID) to a specific client, or to the broadcast address to hit all clients simultaneously. The client has no way to verify these frames didn't come from the AP. It disconnects. If the attacker keeps sending deauth frames, the client can't stay connected. This is a Layer 2 denial-of-service attack.

Deauth attacks are commonly used as a precursor to other attacks. Force a client off a WPA2 network, and when it reconnects, you can capture the 4-way handshake. That handshake is what you need for offline password cracking.

Evil twin / rogue AP detection: An attacker sets up a second AP with the same SSID and BSSID as a legitimate AP. Clients may associate with the fake AP instead, especially if the attacker uses deauth to kick them off the real one. Detecting evil twins requires monitoring for duplicate BSSIDs transmitting from different physical locations - something only possible if you're watching the spectrum.

sequenceDiagram
    participant ATK as Attacker
    participant C as Client
    participant AP as Access Point
    ATK->>C: Deauth frame (spoofed as AP)
    Note over C: Client disconnects
    C->>AP: Re-authentication Request
    ATK->>C: Deauth frame (repeated)
    Note over C: Denial of service
    Note over ATK: Can also capture
WPA2 handshake
during re-auth

Deauthentication attack flow - the attacker spoofs the AP address to force client disconnection, enabling denial-of-service or handshake capture

Probe request tracking: Clients actively probing for specific SSIDs reveal their network history. A device probing for "HomeNetwork-5G" and "CoffeeShopWifi" tells an observer a lot about where it's been. This is a passive surveillance vector that requires no attack - just listening.

Beacon spoofing: An attacker can broadcast fake beacons to create phantom networks. This can confuse automated scanning tools, clutter airspace analysis, or be used to lure clients to attacker-controlled networks.

802.11w PMF: The Fix

IEEE 802.11w, ratified in 2009 and incorporated into the 802.11 standard in 2012, introduced Protected Management Frames (PMF). PMF adds cryptographic protection to certain management frames - specifically deauthentication and disassociation.

With PMF enabled, deauth and disassoc frames are encrypted using the same PTK (Pairwise Transient Key) derived during the 4-way handshake. An attacker without the PTK can't generate a valid encrypted deauth frame. A client that has negotiated PMF will reject unprotected deauth frames.

PMF also adds a Security Association Teardown Protection (SATP) mechanism using the SA Query procedure. If a client receives an unprotected deauth frame (which PMF-capable clients recognize as potentially forged), it can initiate an SA Query with the AP to verify the association is still valid.

The catch: PMF only protects clients that have negotiated it. Mixed environments where some clients don't support PMF are still vulnerable for those non-PMF clients. WPA3 mandates PMF, which is why WPA3 deployment is important for closing this attack surface. WPA2 networks can enable PMF as optional or required, but "required" can break compatibility with legacy devices.

Another limitation: PMF doesn't protect beacon frames. Beacon spoofing remains possible even on PMF-enabled networks.

BLEShark Nano and Management Frames

The BLEShark Nano puts management frame analysis and testing in your pocket. Starting at $36.99+, it's a purpose-built wireless security research tool that handles both WiFi and Bluetooth.

On the WiFi side, BLEShark Nano can operate in monitor mode to passively capture all management frames on a channel. Beacon frames from nearby APs are decoded and listed - SSID, BSSID, channel, signal strength, capability flags. Probe requests from nearby devices are captured along with the SSIDs being searched for.

For authorized deauth testing on networks you own or have explicit permission to test, BLEShark Nano can send targeted or broadcast deauthentication frames. This is the standard mechanism for forcing clients to reconnect so you can capture the 4-way handshake - essential for WPA2 password auditing on your own infrastructure. The deauth implementation crafts properly structured 802.11 management frames with the correct Frame Control field, spoofed source address, and reason code.

Monitoring mode also lets you observe client behavior: which devices are probing for which networks, how quickly they reconnect after deauth, whether they validate PMF or accept spoofed frames. This is useful for understanding the security posture of devices you're responsible for.

Shiver Mesh: Distributed Detection

A single BLEShark Nano sees one radio's worth of spectrum at a time. For serious monitoring, that's often not enough. A large office, a multi-floor building, or an outdoor campus all have coverage gaps where a single device misses frames.

Shiver mesh lets multiple BLEShark Nano units operate as a coordinated sensor network. Each node captures management frames independently and reports to a central view. This means:

Physical-location deauth detection: A deauth flood typically originates from one physical location. With multiple sensors reporting frame timestamps and signal strength, you can triangulate the approximate origin of spoofed frames. A single sensor sees the attack. Multiple sensors help you locate it.

Rogue AP correlation: If two nodes see the same BSSID at significantly different signal strengths, or from slightly different angles, you have a signal that something is off. A legitimate AP is in one place. A rogue AP transmitting the same BSSID should appear anomalous across the sensor grid.

Probe request mapping: In high-traffic environments, probe request monitoring across multiple nodes builds a real-time picture of device movement and network-seeking behavior. Useful for both security monitoring and understanding how your own clients behave.

The mesh communication happens over ESP-NOW (not WiFi), so nodes don't need to be on the same WiFi network they're monitoring. They operate independently and sync their findings.

The Bottom Line

802.11 management frames are the foundation of wireless networking - and a persistent security weakness. The lack of authentication was a reasonable trade-off in 1997 and a significant liability now. 802.11w PMF closes the most critical gaps, but only when properly deployed on both the AP and client side.

Understanding how these frames work - their structure, their purpose, and their limitations - is the starting point for any serious wireless security work. Whether you're auditing your own network's PMF deployment, testing client behavior, or building detection capability, you need a tool that can see and interact with management frames at the raw level.

BLEShark Nano is designed for authorized security research and educational use. Always ensure you have explicit permission before testing on any network you do not own.

Get BLEShark Nano - $36.99+