The Roam That Fell Back to 802.1X
An enterprise uses two APs in one FT mobility domain. The WLC has FT-802.1X enabled, but AP-2 was recently replaced and runs older firmware in which FT is disabled. A voice client roams from AP-1 to AP-2. The capture shows a Reassociation Request containing an RSNE with an MDE and a PMKID count of 1, plus an FTE with an R1KH-ID. AP-2 returns a Reassociation Response with a failure status. The client then performs a full EAP exchange and a 4-way handshake, and the outage is 1.4 s; the call drops. Before the roam, the client was associated to AP-1 for 12 minutes. The client's RSSI to AP-2 is -61 dBm. The SSID and security policy are identical on both APs.
1. What in the Reassociation Request shows that the client attempted FT, and what does AP-2's failure response imply about the FT key hierarchy?
Read the worked answer
The MDE in the RSNE identifies the mobility domain, and the FTE with an R1KH-ID plus a PMKID count of 1 shows the client is attempting an FT-802.1X roam using a PMK-R1 key hierarchy. The client expects the target AP either to hold a PMK-R1 security association or to derive one from the PMK-R0 held by the key holder. AP-2's failure response means it cannot validate or derive the needed key material, or it does not support FT at all. The failure is not explained by RF: -61 dBm is adequate, and the SSID/security policy match. The subsequent full EAP exchange confirms the client fell back to non-FT authentication. In FT terms, the target AP could not complete the FT key derivation, so the fast transition was rejected before the 4-way handshake.
2. What should be checked on AP-2 and the WLC, and what is the least disruptive fix?
Read the worked answer
Verify that FT is enabled on AP-2, that its mobility domain ID matches AP-1, and that the WLC's FT-802.1X policy is applied to that AP. Check that the PMK-R0 key holder is reachable and that the R1KH-ID is consistent across the mobility domain. Confirm AP-2 firmware supports the configured FT mode; older firmware may lack it or may not interoperate. The least disruptive fix is to enable or upgrade FT on AP-2 so it can derive the PMK-R1 and accept the FT Reassociation Request. If that is not immediately possible, remove AP-2 from the FT-enabled WLAN or steer the voice client to a non-FT SSID until the AP is corrected. Validate by repeating the roam and confirming a successful FT Reassociation Response with no full EAP exchange.
3. If FT had succeeded, which frames in the capture would be absent, and which would remain?
Read the worked answer
A successful FT roam would eliminate the full EAP/802.1X authentication exchange, because the client and target AP use the FT key hierarchy instead of full authentication. The Reassociation Response would show success and carry the appropriate FTE. The 4-way handshake would still occur to install the PTK and GTK, so those EAPOL frames would remain. This distinction matters when judging a capture: seeing a 4-way handshake after a roam does not prove FT failed. The diagnostic marker for FT failure is the EAP exchange plus the failed Reassociation Response, not the presence of the 4-way handshake alone.