// reference · 802.11 frame types

Every 802.11 frame starts with two bits that tell you everything

The Frame Control field's Type and Subtype bits identify every frame on the air. Type tells you the category - Management, Control, or Data. Subtype tells you the exact function. Know these and you can read any 802.11 capture.

— Shankar K. · Source: IEEE 802.11-2020 + field notes

// FRAME CONTROL - TYPE FIELD

00

Management

wlan.fc.type == 0

01

Control

wlan.fc.type == 1

10

Data

wlan.fc.type == 2

Type = 0 · Used to discover, join, and leave the BSS. These are the frames you read first in any troubleshooting capture.

0x04

Probe Request

wlan.fc.type_subtype == 4

Sent by a client scanning for networks. Broadcast (null SSID) means the client is looking for any AP. Directed (specific SSID) means it's looking for a saved network - only used for hidden SSIDs in modern devices. More than 10 per second from one device = scan storm.

0x05

Probe Response

wlan.fc.type_subtype == 5

AP's unicast reply to a Probe Request. Contains SSID, supported rates, RSN IE, HT/VHT/HE capabilities, BSS Load, and RNR (in 802.11ax). If you see Probe Requests but no Probe Responses - band mismatch, hidden SSID name wrong, or AP is at capacity.

0x08

Beacon

wlan.fc.type_subtype == 8

Broadcast by every AP every 102.4ms (100 TUs). The loudest frame in any capture - filter it out first when troubleshooting (not wlan.fc.type_subtype == 8). Contains everything a client needs to decide whether to associate: SSID, rates, RSN IE, TIM, DTIM, BSS Color, RNR for 6 GHz discovery. Missing beacons = AP radio problem.

0x09

ATIM

wlan.fc.type_subtype == 9

Announcement Traffic Indication Message. Used in IBSS (ad-hoc) networks to notify sleeping stations that buffered frames are waiting. Rare in enterprise captures - only relevant in peer-to-peer 802.11 topologies.

0x0A

Disassociation

wlan.fc.type_subtype == 10

Softer than Deauthentication - moves the client from State 3 to State 2 (authenticated but not associated). Client can reassociate without re-authenticating. Common during normal roaming. Contains a Reason Code - see Status & Reason Codes reference. If sent by client with Reason 3 or 8, it's a planned disconnect or roam.

0x0B

Authentication

wlan.fc.type_subtype == 11

The first step in joining a BSS. For WPA2/WPA3 networks this is Open System Authentication - a simple two-frame exchange (Algorithm 0) that provides no real security. For WPA3-SAE, Algorithm 3 is used with Commit and Confirm sub-exchanges. For 802.11r FT, these frames carry the FT IE for pre-roam key derivation.

0x0C

Deauthentication

wlan.fc.type_subtype == 12

Resets the client to State 1 - unauthenticated and unassociated. Always contains a Reason Code. Reason 2 = previous auth expired (AP reboot, RADIUS timeout). Reason 15 = 4-way handshake timeout (wrong PSK). Reason 23 = 802.1X failure. A burst of deauths with Reason 1 targeting all clients = deauth flood attack. With PMF required, these frames are cryptographically protected.

0x00

Association Request

wlan.fc.type_subtype == 0

Client declares its full capabilities to the AP - supported rates, HT/VHT/HE capabilities, RSN IE (cipher suites and AKM suites), PMF bits, power save mode, and supported channel widths. This is the frame to inspect when debugging security failures: check the RSN IE against what the AP advertised in the Beacon. Mismatch = Status Code 23 or 24.

0x01

Association Response

wlan.fc.type_subtype == 1

AP's reply to Association Request. Status Code 0 = success. Any non-zero code = rejected. Contains the Association ID (AID) assigned to the client. If rejected, the Status Code tells you exactly why - see Status & Reason Codes reference. This is the frame that closes the 802.11 state machine transition to State 3.

0x02

Reassociation Request

wlan.fc.type_subtype == 2

Used when a client is roaming - it includes the previous AP's BSSID, signalling this is a handoff not a fresh join. Contains the same capability fields as Association Request. For 802.11r FT roaming, look for the FT IE and PMKID list here. Seeing Reassoc instead of Assoc = client previously had an association - confirms a roam event.

0x03

Reassociation Response

wlan.fc.type_subtype == 3

Target AP's reply during a roam. Status Code 0 = roam successful. Status Code 53 = Invalid PMKID - the most misdiagnosed roaming failure. Controller may say "roam successful" but Status Code 53 followed by full re-auth means the FT key hierarchy failed. Not the same roam.

0x0D

Action

wlan.fc.type_subtype == 13

A catch-all frame for protocol actions that don't fit other subtypes. Category field inside defines what it is: Cat 0 = Spectrum Management (DFS), Cat 1 = QoS, Cat 5 = Radio Measurement (802.11k Neighbor Report), Cat 6 = Fast BSS Transition (802.11r), Cat 10 = WNM (802.11v BSS Transition Management), Cat 19 = Robust AV Streaming. Most roaming protocol interaction happens in Action frames.

Type = 1 · No frame body - header only. Control frames manage access to the shared wireless medium and acknowledge data delivery.

0x1D

ACK

wlan.fc.type_subtype == 29

Acknowledgment - sent immediately after every successfully received unicast frame (SIFS gap, ~16µs). If the sender doesn't receive an ACK, it assumes the frame was lost and retransmits. High retransmission rate = ACKs being lost = RF problem. ACK frames are the pulse of the wireless medium - their absence is the primary indicator of link quality degradation.

0x1B

RTS

wlan.fc.type_subtype == 27

Request to Send - optional mechanism to reserve the medium before a large frame transmission. Sender broadcasts RTS to the AP. All stations that hear it set their NAV (Network Allocation Vector) timer and defer. Solves the hidden node problem. Only triggered for frames above the RTS threshold (configurable - default often disabled). RTS without a following CTS = AP didn't hear it.

0x1C

CTS

wlan.fc.type_subtype == 28

Clear to Send - AP's broadcast reply to an RTS, or used as CTS-to-Self to protect a transmission in mixed-mode environments (when 802.11b clients are present). Every station hearing the CTS defers for the Duration value specified. CTS-to-Self adds overhead but prevents legacy clients from corrupting 802.11n/ac frames they can't decode.

0x19

Block ACK Request (BAR)

wlan.fc.type_subtype == 24

Sent after a burst of aggregated frames (A-MPDU) to request a Block ACK covering the entire burst. This is how 802.11n/ac/ax aggregation works - instead of ACKing every frame individually, the receiver sends one Block ACK for up to 64 frames. Essential for understanding high-throughput captures.

0x19

Block ACK (BA)

wlan.fc.type_subtype == 25

Bitmap-based acknowledgment for a burst of aggregated frames. Each bit in the bitmap represents one frame in the A-MPDU - 1 = received, 0 = missing (needs retransmission). In a PCAP, the BA bitmap tells you exactly which frames in a burst were lost - far more precise than individual ACK loss analysis.

0x1A

PS-Poll

wlan.fc.type_subtype == 26

Power Save Poll - legacy power save mechanism. A sleeping client wakes, reads the TIM in the beacon (which tells it frames are buffered), then sends a PS-Poll to the AP to retrieve each buffered frame. Each PS-Poll retrieves one frame - inefficient. Replaced by U-APSD (WMM Power Save) and TWT in 802.11ax. Seeing lots of PS-Polls = legacy device with basic power save.

ToDS / FromDS bits - what they actually mean

The To DS and From DS bits in the Frame Control field tell you the direction of the frame and how to interpret the four address fields. Getting this wrong leads to misreading address fields in Wireshark.

ToDS	FromDS	DIRECTION	TYPICAL USE
0	0	STA → STA (IBSS)	Ad-hoc / management frames
1	0	STA → AP → DS	Client uplink to internet
0	1	DS → AP → STA	Client downlink from internet
1	1	DS → AP → AP → DS	WDS / mesh backhaul links

Frame sequence - complete connection lifecycle

Every Wi-Fi connection follows this sequence. Match this against your PCAP to find exactly where a failure occurred.

1Probe Request→ APClient scanning
2Probe Response← APAP advertising capabilities
3Authentication Request→ APOpen System (Algo 0) or SAE Commit (Algo 3)
4Authentication Response← APStatus 0 = proceed
5Association Request→ APClient declares all capabilities + RSN IE
6Association Response← APStatus 0 = State 3 - associated
7EAPOL M1← APANonce from AP
8EAPOL M2→ APSNonce + MIC from client
9EAPOL M3← APGTK encrypted, RSN IE
10EAPOL M4→ APHandshake complete - keys installed
11DHCP Discover→ BCClient requesting IP
12DHCP Offer / Request / ACK← →IP assigned - DORA complete
13QoS Data↔ APNormal traffic - connection established

WiFi Analyser decodes every frame automatically

Upload a PCAP and every management frame, EAPOL sequence, and failure reason code is identified, explained, and mapped to the relevant client session.

try it free ↗

— Shankar K., Wi-Fi engineer, Irving TX
Building WiFi Analyser V2 · CWNA-109 in progress · one post every two weeks

Preparing for a Wi-Fi interview? - 71 questions, spoken engineer answers, free PDF.

Request the guide →

// leave a comment

// share this page

← previous

next →

SK

— Shankar K., Wi-Fi engineer, Irving TX
 Building WiFi Analyser V2 · CWNA-109 in progress · one post every two weeks 