A reauthentication the RADIUS server left unanswered¶
The symptom¶
Nobody complained: the disconnect came unprovoked during a live session on 2026-10-26, 15:59 to 16:17 CET, while the developer walked through the app. The developer's own iPhone (a private address on eduroam) lay idle next to the sensor playing a video. At 16:12:30 Mist showed the AP deauthenticating it, and an authentication failure that reads in the portal "Reauthorization AP deauthenticate STA, before authorization complete(771). 802.1x Auth Fail(23). Timeout, Radius Server Failed to respond to request(514)." In the same second the phone joined again on its own. Nobody touched it.
The environment¶
The AP45 at home in the work org, eduroam on 5 GHz ch 128/20 (key_mgmt WPA3-EAP-FT/CCMP, the phone on AKM 3, FT over 802.1X, EAP-TLS), its 2.4 GHz radio on ch 1/20. The phone at −58 dBm at the AP (Mist), the AP at −45 dBm at the sensor. capA on the client's BSS, capB on the AP's 2.4 GHz BSS (another band of the client's AP). A live session of 17:50 min; capA wrote 113,239 frames with no drop. The phone had associated at 15:59:01.7, before the session started (Mist's time_since_assoc), so its first login is not in the capture.
Sensor times below are corrected by the session's clock measurements (the Pi 0.51 to 0.52 s behind the Mac). The deauthentication lands at 16:12:30.13 on the air and 16:12:30.150 in Mist.
What the air shows¶
The reauthentication is encrypted, and still readable¶
After the 4-way handshake the AP sends its EAPOL frames encrypted, like any data frame: the engine sees no EAP and no EAPOL-Key in them, and the app showed only the deauthentication and the login after it. Two things give them away. The AP45 sends EAPOL on TID 5, which it uses for nothing else to this client; and the lengths are those of the unencrypted EAP of the login 18 s later plus the 16 bytes of CCMP (header and MIC): an Identity Request of 99 bytes becomes 115, the EAP-TLS Start 100 becomes 116, a 1114-byte fragment 1130. The AP's QoS sequence number on TID 5 confirms the count: it stood at 10 at the first reauthentication, the 10 frames of a login (8 EAP, M1, M3) at 15:59:01, and restarted at 0 with the new association.
The phone dozed between the two bursts; the AP holds each request until the phone wakes. The beacon's TIM marks the phone's AID first in the beacon at 16:11:42.20 and not in the one 102 ms before: the AP queued the Identity Request in that interval.
The first attempt, 16:11:42¶
| Time | From | Bytes | Message | RADIUS round trip |
|---|---|---|---|---|
| 42.10–42.20 | AP | Identity Request queued (TIM) | ||
| 42.205 | AP | 115 | EAP-Request Identity | |
| 42.208 | phone | 161 | EAP-Response Identity | |
| 42.226 | AP | 116 | EAP-TLS Start | 17.7 ms |
| 42.233 | phone | 272 | ClientHello | |
| 42.255 | AP | 1130 | ServerHello, certificate (fragment 1) | 21.6 ms |
| 42.257 | phone | 116 | fragment ack | |
| 42.274 | AP | 1130 | fragment 2 | 16.7 ms |
| 42.277 | phone | 116 | fragment ack | |
| 42.294 | AP | 1130 | fragment 3 | 16.9 ms |
| 42.296 | phone | 116 | fragment ack | |
| 42.313 | AP | 797 | fragment 4 (last) | 16.7 ms |
| 42.345 | phone | 1359 | client certificate, key exchange, CertificateVerify, Finished | |
| AP | nothing |
The AP acknowledged the phone's last frame (an ACK 50 µs after it). Then the AP sent nothing to the phone on TID 5 for 29.9 s.
The second attempt, 16:12:12¶
The AP queued a new Identity Request between 16:12:12.21 and 16:12:12.31 (TIM), 29.86 to 29.97 s after the phone's certificate flight, and the exchange ran the same way: 115, 161, 116, 272, three times 1130 against 116, 796, and the phone's 1360-byte certificate flight at 16:12:12.453, acknowledged by the AP. RADIUS round trips 20.7, 20.5, 17.8, 21.9 and 17.9 ms. Again no answer to the certificate flight.
At 16:12:30.13 the AP deauthenticated the phone, 17.68 s after its second certificate flight and about 48 s after it queued the first Identity Request. The frame is encrypted (PMF); Mist gives reason 2, previous authentication no longer valid.
The login right after¶
| After the deauthentication | Frame |
|---|---|
| 61 and 72 ms | the phone's probe requests, the AP's responses |
| 112 ms | Open System authentication |
| 114 ms | association request (not a reassociation: no FT, no PMKID) |
| 119 ms | EAP-Request Identity |
| 327 ms | EAP-Success, after a full EAP-TLS handshake |
| 336 ms | M4 |
The same seven round trips as the reauthentication, the AP's server-side step now answered: 18, 20, 20, 19, 17, 20 and 26 ms (linkside-cli replay, radius_ms). The round trip after the phone's certificate flight took 19.8 ms, the one that never came back twice in the minute before. Mist: CLIENT_AUTH_ASSOCIATION status 0 at 227 ms after the association, CLIENT_DNS_OK at 1,316 ms (dns_latency 102 ms), CLIENT_GW_ARP_OK later at 16:13:44; no CLIENT_IP_ASSIGNED.
The answers¶
The reauthentication. The AP started it at 16:11:42.1 to 42.2 with an EAP-Request Identity, encrypted, on TID 5. The phone answered every request within 2 to 32 ms, on the first try, and the AP acknowledged each answer. RADIUS answered five times in 17 to 22 ms: the TLS Start and the four fragments of the server's certificate chain. It did not answer the phone's certificate flight, the step where the server checks the client's certificate and decides. The AP waited 29.9 s, started over with a new Identity Request, got to the same step with the same round trips, waited 17.7 s more, and deauthenticated the phone with reason 2. No EAP retransmission went over the air: the phone had answered, the AP waited for the server.
The login after it. A full EAP-TLS handshake in 207 ms, from Identity Request to EAP-Success, every RADIUS round trip 17 to 26 ms, the last step included. RADIUS was reachable and quick throughout: the failure was one step of the server's work, twice in a row, and then fine 18 s later.
An earlier reauthentication. None in the recording: the AP's TID 5 sequence number went from 9 at the login at 15:59:01 to 10 at 16:11:42, with no frame between, and the capture ran from 15:59:55. The reauthentication came 760.4 to 760.5 s (12 min 40 s) after the association, the first one of it. After the new login at 16:12:30 the session ran 5 min 15 s more without one. One interval is one point: a fixed RADIUS Session-Timeout, a randomized one and a reauthentication the server asked for (CoA) look the same over the air. A fixed 760 s would put the next one at about 16:25:10, after the session.
What the sensor can and cannot show. It sees the air between the phone and the AP: that the phone answered every request at once, that every frame of it arrived, and which of the AP's requests came back from RADIUS and after how long. It does not see the AP's RADIUS traffic: the AP's own proxy (Mist's auth_server 127.0.0.1), the path to the RADIUS servers and the servers themselves are behind the AP. The air rules out the Wi-Fi link and the client: the phone did its part of the handshake twice, and the AP's requests stopped exactly where the server had to answer. Mist's 514 names the server. The verdict should name upstream / not Wi-Fi, not the AP side.
The app's outcome¶
"On the AP side", from ap-disconnect: "Disconnected by the AP. Reason 2: previous authentication no longer valid." The other finding, downlink-loss as a note (the AP's frames sent again after the phone's wakes from power save, BA success downlink 98.6 % over the session), has nothing to do with the disconnect. The developer approved on 2026-10-26 that a RADIUS timeout names upstream / not Wi-Fi; the rule is being built.
Two things for that rule. mist.json keeps authorization_reason_code (23 here) but not the message with 771 and 514, since MistSeries keeps no event text: from the recording alone, the timeout is the auth failure with reason 2 together with the deauthentication in the same second and a successful login right after, unless MistSeries keeps the 514 as a code. The encrypted EAP on the AP's TID 5 is the sensor's own evidence of where the exchange stopped, but it rests on the AP45's choice of TID and on lengths: a fingerprint of this AP, not something to build a rule on before the AP47 has been seen doing the same.
The recording, cut to the two minutes around the disconnect and anonymized, is the test session ap45-radius-timeout-reauth (test data), with upstream as its expected outcome and the AP side as a known mismatch until the rule is in.
What Linkside added over Mist alone¶
Mist said the RADIUS server failed to respond. The capture adds where: after the client's certificate, the server's work, with RADIUS answering every step before it in about 20 ms, on both attempts; that the client and the air did their part; and the AP's timing, 29.9 s before it started over and 17.7 s before it gave up. It missed the reauthentication itself: the engine saw only the encrypted deauthentication and the login.
The same step on 2026-10-29¶
Three days later the same phone (a new private address, the same EAP-TLS identity) on the same AP, now on 5 GHz ch 104/20, in two live sessions with the phone's reconnects. The step after the phone's certificate flight, against the other round trips of the same login (Mac time):
| Login | The other round trips | After the certificate flight |
|---|---|---|
| 11:18:21, the phone's reconnect | 17 to 23 ms | no answer; the AP asked for the identity again 29.88 s later (ap45-radius-unanswered-login) |
| 11:18:51, the AP's second attempt | 16 to 26 ms | 22 ms |
| 11:26:39, the phone's reconnect | 17 to 28 ms | 9958 ms (ap45-radius-slow-login) |
| 12:05:35, after the AP's disconnect | 15 to 22 ms | no answer; the phone associated again 6.9 s later, Mist's auth failure naming 514 |
| 12:05:42 | 18 to 25 ms | 9574 ms |
In each the AP acknowledged the certificate flight and did not send its request again: the server's work again. In four sessions of 2026-10-24 to 27 the same identity's logins took 18 to 21 ms at that step. Mist's CLIENT_AUTH_ASSOCIATION gives the time from the association to the end of the login as time_since_assoc (30327, 10231 and 9911 ms), the stall within it, and logs no failure for the slow ones.
The disconnect at 12:05 is another thing: a reauthentication the phone left unanswered while asleep, after which the AP answered its next frame with reason 7 (the case).
To check on the RADIUS side¶
- The RADIUS server's log for the phone's outer identity at 16:11:42 and 16:12:12, and on 2026-10-29 at 11:18:21, 11:26:40 and 12:05:35: the Access-Requests carrying the client's certificate flight, whether they arrived, and what the server did with them (OCSP or CRL check, a directory lookup for authorization, a policy step, a proxy to another server).
- Whether those Access-Requests went to one server or to both of a pair: the AP's retransmissions and failover within the 30 s are invisible to the sensor. The Mist WLAN's RADIUS timeout and retries against the 29.9 s and 17.7 s measured here.
- The Session-Timeout and Termination-Action in the Access-Accept of the phone's logins, to know the reauthentication interval, and whether 760 s is it.
- Whether the server answers a reauthentication differently from a first login (the same full handshake both times here, no TLS resumption), and how often a reauthentication fails across the org: Mist's auth failures with reason 514.