Why your 802.11r deployment is failing — reading status code 53 in Wireshark

You deploy 802.11r. You test roaming. The controller log shows the roam completed. Voice calls are still dropping. You open a ticket with the vendor. The vendor asks for logs. The logs show success. The call drops continue.

This is the most common 802.11r failure pattern I see — and the reason it's so hard to diagnose is that the controller and the PCAP are looking at different things.

What the controller actually logs

When a client roams, the controller logs the Reassociation Response as transmitted — not as accepted by the client. The frame went out. From the controller's perspective, the roam is done. It has no visibility into whether the client accepted the response or what status code was inside it.

Meanwhile, at the 802.11 layer, the client received that Reassociation Response, read the status code field, saw a value other than zero, and rejected the roam. It either retried, fell back to full re-authentication, or deauthenticated entirely. The controller logged success. The client experienced failure.

The status code that causes this most often is status code 53 — "Invalid PMKID."

What status code 53 actually means

In an 802.11r Fast BSS Transition deployment, the AP holds a hierarchy of keys: PMK-R0 at the top (derived from the original authentication), PMK-R1 distributed from R0 to each AP in the mobility domain. When a client roams to a new AP, it presents a PMKR0Name — a fingerprint of its PMK-R0 — in the Reassociation Request. The target AP uses this to look up the corresponding PMK-R1 it should have received.

Status code 53 means the target AP looked up that PMKR0Name and found nothing. The PMK-R1 was never distributed to that AP. The client showed up with credentials the AP had never seen.

The authentication framework is intact. The client's key derivation is correct. The problem is the key distribution between controllers — the R0KH to R1KH pathway is broken.

Finding it in Wireshark — two minutes

Start with this filter to isolate all Reassociation Responses:

Then add the status code filter to find non-zero responses — anything that isn't success:

If status code 53 appears, expand the Reassociation Response frame and look at the Fixed Parameters section. You will see:

Also check the Reassociation Request immediately before it. Expand the RSN Information Element and look for the PMKID field. That PMKR0Name is what the client presented — and what the AP could not match to any distributed PMK-R1.

The three most common root causes

1. Mixed mobility domain IDs (MDID)

All APs participating in FT roaming must share the same two-byte Mobility Domain ID. A single AP with a different MDID — from a misconfigured template or a firmware default — silently breaks roaming for any client that tries to roam to it. Check the Mobility Domain IE (Element ID 54) in the beacon frames of every AP in the deployment. They must all match.

2. R0KH to R1KH key distribution not configured

The controller must be configured to distribute PMK-R1 keys to every AP in the mobility domain at association time — not on demand. Some deployments have FT enabled at the SSID level but the key holder configuration is incomplete. The client associates successfully to the first AP, roams, and the target AP has no key to match. Fix: verify R0KH and R1KH IDs are consistent across all APs and the controller has the correct key distribution policy.

3. Mixed firmware versions in the mobility domain

This is the one that causes the most head-scratching. Two APs, identical configuration, same controller, same SSID — one roams cleanly, the other returns status 53. Check the firmware version. A firmware delta between APs in the same mobility domain can cause incompatible key derivation implementations. The PCAP will show correct MDID on both, correct PMKID presented by the client, and still status 53 from the target AP.

One thing to remember

The controller log is not wrong. The Reassociation Response was transmitted. But logging transmission is not the same as logging acceptance. The 802.11 status code lives in the frame body — and most controllers never surface it in their management plane logs.

When roaming is broken and the controller says it isn't, open a PCAP. Filter for Reassociation Responses. Check the status code. If it's 53, you have a key distribution problem, not an RF problem — and no amount of adjusting transmit power or roam thresholds will fix it.