Dis-Association
Overview
In IEEE 802.11b, disassociation is a MAC management procedure used by either the Station (STA) or the Access Point (AP) to terminate an existing association. After disassociation, the STA remains authenticated but is no longer associated, meaning it cannot send or receive data frames via the AP until it reassociates.
Unlike deauthentication, which removes authentication state entirely, disassociation only ends the logical data relationship between the STA and AP.
When Disassociation Occurs
Common reasons for disassociation include:
Voluntary STA departure (e.g., STA leaves the BSS or disables its radio)
Inactivity timeout — STA silent beyond a configured limit
AP resource management — AP removes STA due to load balancing or resource limits
Power management transitions
Policy or security enforcement
Mobility / roaming to another AP
State Relationships
The 802.11 MAC defines three connection states:
|--------|————-| | 1 | Unauthenticated, Unassociated | | 2 | Authenticated, Unassociated | | 3 | Authenticated, Associated |
Disassociation causes a transition from State 3 → State 2, keeping the STA authenticated but unassociated. Deauthentication, by contrast, transitions to State 1, removing authentication.
Frame Format
The Disassociation frame is a Management Frame (Type = 0, Subtype = 10).
|--------|———|-------------| | Frame Control | 2 | Type = Management, Subtype = Disassociation | | Duration | 2 | NAV (unused here) | | Destination Address (DA) | 6 | Receiver MAC address | | Source Address (SA) | 6 | Sender MAC address | | BSSID | 6 | BSS Identifier | | Sequence Control | 2 | Sequence number | | Reason Code | 2 | Explains why disassociation occurred |
No variable-length information elements (IEs) follow.
In 802.11b, disassociation frames are not encrypted or integrity protected.
Reason Codes
Reason Codes provide diagnostic context for disassociation events. Common codes are:
|-------|———-| | 1 | Unspecified reason | | 4 | Disassociated due to inactivity | | 5 | AP unable to handle all associated STAs | | 8 | STA leaving BSS (voluntary) | | 9 | STA not authenticated | | 10 | Power capability unacceptable | | 11 | Supported channels unacceptable | | 17 | Disassociated due to AP policy | | 32–35 | QoS-related (later amendments) |
In 802.11b environments, codes 1, 4, 5, and 8 are the most frequent.
Exchange Scenarios
STA-Initiated Disassociation
Used when a STA voluntarily leaves the BSS.
STA → AP : Disassociation (Reason = 8, Leaving BSS)
AP → ACK
AP clears STA’s AID, buffers, and queues.
STA becomes Authenticated, Unassociated.
Typical triggers:
User turns off Wi-Fi.
STA moves to another AP (reassociation).
STA enters deep sleep.
AP-Initiated Disassociation
Used when the AP ends a session but keeps the STA authenticated.
AP → STA : Disassociation (Reason = 4, Inactivity)
STA → ACK
STA transitions to Authenticated, Unassociated.
Typical triggers:
AP idle timeout.
Resource or load balancing.
Channel change or maintenance.
Behavior on Receipt
When a STA receives Disassociation:
Validate frame (CRC, subtype).
Read Reason Code.
Clear association data: AID, buffers, TIM index.
Move to Authenticated, Unassociated state.
Notify upper layers (network manager).
STA may reassociate automatically.
When an AP receives Disassociation:
Identify STA entry (MAC).
Free AID slot, clear queues, reset TIM bit.
Drop buffered frames for STA.
Log event and Reason Code.
Optionally inform controller or RADIUS backend.
Interaction with Power Save and AID
Each associated STA has an AID and TIM bit in the AP’s beacon.
When a STA disassociates, the AP clears the corresponding AID and TIM bit.
Buffered frames for that AID are discarded.
On reassociation, a new AID is assigned.
Timing and Retransmission
Disassociation frames follow normal DCF access rules.
The frame is ACKed if unicast.
Retries may occur if no ACK received.
Unprotected nature makes them spoofable in legacy 802.11b.
State Transitions Summary
|---------|——-|----------|————–| | Authenticated, Associated | Authenticated, Unassociated | Disassociation | Logical link removed, authentication remains | | Authenticated, Unassociated | Unauthenticated, Unassociated | Deauthentication | Full session teardown |
Comparison: Disassociation vs Deauthentication
|-----------|—————-|------------------| | Frame subtype | 10 | 12 | | State change | Associated → Unassociated | Authenticated → Unauthenticated | | Authentication | Retained | Lost | | Use case | Normal leave or inactivity | Security or session reset | | STA rejoin | Reassociation possible | Must reauthenticate | | ACK expected | Yes | Yes | | Protected (PMF)? | Optional (later) | Optional (later) |
Examples
STA-Initiated Example
STA (Associated)
-------------------------------------->
Disassociation (Reason = 8)
<--- ACK
STA → Authenticated, Unassociated
AP-Initiated Example
AP detects STA inactivity
AP ------------------------------>
Disassociation (Reason = 4)
<--- ACK
AP clears AID, buffers
STA becomes Authenticated, Unassociated
Sequence Diagram
+-----------+ +-----------+
| STA | | AP |
+-----------+ +-----------+
| |
|<---------- Association ------------>|
| (Established) |
| |
|--- Disassociation (Reason=8) -----> | (STA leaving)
|<-------------- ACK -----------------|
| |
| (Authenticated, Unassociated) |
| |
Security Implications
In 802.11b, disassociation frames are not protected and can be spoofed.
Attackers can inject fake disassociation frames to disconnect users.
Mitigation came with 802.11w / PMF, which authenticates management frames.
Mitigation
Enable Protected Management Frames (PMF) where available.
Use WPA2/WPA3 with PMF required mode.
Ignore unprotected disassociation frames if PMF negotiated.
Implementation Guidelines
Access Point (AP): - Transmit disassociation only when necessary (policy, timeout, etc.). - Immediately clear AID, buffers, and per-STA queues. - Log reason codes for debugging.
Station (STA): - On receipt, clear state and notify OS. - Reassociate or roam if AP still within ESS. - Rate-limit reassociation attempts to avoid loops.
Debugging and Analysis
Capture frames using Wireshark filter:
wlan.fc.type_subtype == 0x000aInspect Reason Code field.
Check if disassociation is followed by reassociation (indicates roaming).
Repeated disassociations with identical Reason Codes may imply DoS or configuration issues.
Common Scenarios
|-----------|————|--------|————–| | STA leaving | STA | 8 | STA voluntarily leaves BSS | | Inactivity timeout | AP | 4 | STA inactive | | Resource overload | AP | 5 | AP capacity reached | | Power off | STA | 8 | User disables Wi-Fi | | Policy enforcement | AP | 17 | Security/policy rule | | Signal loss | AP | 4 | STA deemed inactive |
Summary
|----------|————-| | Purpose | Graceful termination of association | | State change | Associated → Unassociated | | Authentication | Remains valid | | Frame protection | None in 802.11b (added in 802.11w) | | Trigger | Inactivity, leaving BSS, policy enforcement | | ACK | Yes, if unicast | | Spoofable | Yes (legacy networks) | | Remedy | Use PMF-enabled WPA2/WPA3 |
References
IEEE Std 802.11b-1999, Clause 18.2.3.9 (Disassociation Procedure)
IEEE Std 802.11-2020, Clause 9.3.3.8 (Disassociation Frame)
Gast, M. 802.11 Wireless Networks: The Definitive Guide, O’Reilly
Tanenbaum & Wetherall, Computer Networks, 5th Edition
Wireshark Filter:
wlan.fc.type_subtype == 0x000a
Figures
Disassociation message flow between STA and AP with ACK and state transition.