8 frames that tell you whether 802.11r actually fired
"Every vendor dashboard shows 802.11r enabled. Most roams I see in PCAPs are not using it." ·
802.11r enabled on a controller means the AP advertises FT capability. Whether a specific roam used FT is only visible in the PCAP. Eight frames, in sequence.
Frame 1 — Beacon: does MDIE exist?
Mobility Domain IE. All APs in the FT domain must share the same 2-byte MDID. One AP with a different MDID silently breaks roaming for all clients that try to roam to it.
Frame 3 — Auth Request: Algorithm == 2?
Algorithm 2 = Fast BSS Transition. Algorithm 0 in the Auth Request to the target AP means full re-authentication fired — 802.11r did not fire. This is the most decisive single check.
Frame 4 — Auth Response: Status 0?
Status 53 (INVALID_PMKID) = PMK-R1 was never distributed to the target AP. Status 78 = FTIE MIC check failed. Both trace to configuration, not client capability.
Frame 6 — ReassocResp: GTK in FTIE?
Successful FT delivers the GTK in the FTIE of the Reassociation Response — no separate EAPOL exchange. GTK in FTIE = FT completed in 4 frames. If EAPOL follows Reassoc, FT key derivation failed.
Latency target
With 802.11r: Auth Req → Auth Resp → Reassoc Req → Reassoc Resp. Four frames. Under 50ms. Without: ten frames minimum, 200-500ms. Above 150ms from Reassoc Req to first data frame = voice call dropped.