// reference · association state machine
802.11 Association State Machine
Three states. Every frame class that's allowed in each. Click any transition or state to see the exact frames, what can go wrong, and the Wireshark filter to find it.
— Shankar K. · Source: IEEE 802.11-2020, Clause 11.3 + CWNA-109 Study Guide
State 1
Unauthenticated
Unassociated
Unassociated
Class 1 frames only
State 2
Authenticated
Unassociated
Unassociated
Class 1 + 2 frames
State 3
Authenticated
Associated
Associated
Class 1 + 2 + 3 frames
🔒 + EAPOL → encrypted data
State 3 → 4-way EAPOL handshake → encrypted data (WPA2/WPA3) · Deauth from any state → back to State 1
// frame class reference — ieee 802.11-2020 clause 11.3.3
Class 1
Allowed in: All states
Probe Request / Response
Beacon
Authentication
Deauthentication
Announcement Traffic Indication (ATIM)
Management frames (broadcast/multicast)
RTS / CTS / ACK
CF-End
Class 2
Allowed in: State 2 + 3
Association Request / Response
Reassociation Request / Response
Disassociation
PS-Poll
Class 3
Allowed in: State 3 only
Data frames (all subtypes)
QoS Data frames
Action frames (QoS/HT/VHT/HE)
Block ACK / Block ACK Request
Deauthentication (from associated STA)
// why this matters for security
If an AP receives a Class 3 frame (data) from a station in State 1 or 2, it responds with a Deauthentication frame (reason code 6 — Class 2 frame from unauth STA, or 7 — Class 3 frame from unassoc STA). This is the basis of the deauthentication flood attack — an attacker in State 1 can forge Deauth frames to push legitimate clients back to State 1. Without PMF (802.11w), these frames are unauthenticated. With PMF enabled, Deauth frames from State 3 are encrypted and cannot be forged.
// complete join sequence — state transitions
| Step | Frame | Direction | State change | Wireshark filter |
|---|---|---|---|---|
| 1 | Probe Request (optional) | Client → Any AP | Stays in State 1 | wlan.fc.type_subtype == 0x04 |
| 2 | Probe Response | AP → Client | Stays in State 1 | wlan.fc.type_subtype == 0x05 |
| 3 | Authentication Request | Client → AP | Stays in State 1 | wlan.fc.type_subtype == 0x0b |
| 4 | Authentication Response (status 0) | AP → Client | State 1 → State 2 | wlan.fc.type_subtype == 0x0b |
| 5 | Association Request | Client → AP | Stays in State 2 | wlan.fc.type_subtype == 0x00 |
| 6 | Association Response (status 0) | AP → Client | State 2 → State 3 | wlan.fc.type_subtype == 0x01 |
| 7 | EAPOL M1 (if WPA2/WPA3) | AP → Client | Stays in State 3 | eapol |
| 8 | EAPOL M2, M3, M4 | Client ↔ AP | Stays in State 3 | eapol |
| 9 | Encrypted data frames | Client ↔ AP | State 3 (data flowing) | wlan.fc.protected == 1 |
| — | Deauthentication (any time) | AP or Client → other | → State 1 (any state) | wlan.fc.type_subtype == 0x0c |
| — | Disassociation (from State 3) | AP or Client → other | State 3 → State 2 | wlan.fc.type_subtype == 0x0a |
| — | Reassociation Request (roaming) | Client → New AP | Stays in State 2 | wlan.fc.type_subtype == 0x02 |
| — | Reassociation Response (status 0) | New AP → Client | State 2 → State 3 | wlan.fc.type_subtype == 0x03 |
See state transitions in a real PCAP
WiFi Analyser tracks state transitions per client — shows exactly where in the state machine a client failed to join.
// share this page
// also on this site
SK
— Shankar K., Wi-Fi engineer, Irving TX
Building WiFi Analyser V2 · CWNA-109 in progress · one post every two weeks
Building WiFi Analyser V2 · CWNA-109 in progress · one post every two weeks
// leave a comment