A reauthentication the phone left unanswered while asleep¶
The symptom¶
Nobody complained: the disconnect came during a live session on 2026-10-29, 11:24 to 12:09 CET, with the developer's own iPhone (a private address on eduroam) beside the sensor. A video played on it for a while, then its screen went black, and it lay untouched. At 12:05 the app showed the AP deauthenticating it and the phone joining again; Mist showed two authentication failures and a login, and no deauthentication. An earlier disconnect in the same session, at 11:26, the developer made on the phone; its login is the test session ap45-radius-slow-login.
The environment¶
The AP45 at home in the work org, eduroam on 5 GHz ch 104/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 11/20. The phone at −54 dBm at the AP (Mist), the AP at −40 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 45 min; capA wrote 136,939 frames with no drop.
The phone was idle from about 11:54: a frame each way every 30 s (at 12:04:33.46, 12:05:03.46 and 12:05:33.47), with the Null frames around it, and a few short bursts, the last at 12:03:32 to 12:03:43. Sensor times below are corrected by the session's clock measurements (the Pi 4.53 s behind the Mac around 12:05).
What the air shows¶
The reauthentication the phone left unanswered¶
As on 2026-10-26 (the case), the AP45 sends its EAPOL after the 4-way encrypted on TID 5, which it uses for nothing else to this client, and an EAP-Request Identity of 99 bytes becomes 115 with CCMP. The beacon's TIM, the bitmap of the AIDs with frames waiting, shows when the AP queued one for the dozing phone (AID 53).
| Queued (TIM) | Fetched | Phone dozes again | Answer |
|---|---|---|---|
| 12:04:32.79–32.89 | 12:04:33.462 | 23 ms later | none |
| 12:04:35.86–35.96 | 12:04:36.997 | 15 ms later | none |
| 12:04:41.80–41.90 | 12:04:42.528 | 16 ms later | none |
| 12:04:53.89–53.99 | 12:04:55.636 | 16 ms later | none |
| 12:05:13.96–14.06 | 12:05:14.069 | 16 ms later | none |
Each time the phone woke with a Null frame (PM 0), the AP sent the 115-byte request, the phone acknowledged it 44 to 45 µs later, and dozed again with a Null frame (PM 1). It sent no data in between: every uplink frame of it would have drawn an ACK or a Block Ack from the AP, and there was none. The AP queued each request anew, with a new sequence number, after 3.1, 5.9, 12.1 and 20.1 s, and never got past the identity: its next request in a login would have been the EAP-TLS Start, 116 bytes. The frames were good: their PNs ran in order with the AP's other frames to the phone, and the phone's keepalive at 12:05:03 went through in the same key, its frame and the AP's answer each acknowledged by a Block Ack.
The phone no longer woke for every beacon. It fetched the requests 0.01 to 1.65 s after the first beacon that flagged them; at 12:04:33 its regular wake came first.
The same request at 11:39 and 11:51, answered¶
| Queued (TIM) | Fetched | Phone's answer | Certificate flight to the AP's next request |
|---|---|---|---|
| 11:39:21.15–21.25 | 11:39:21.252 | 3 ms, 161 bytes | 20 ms |
| 11:51:52.47–52.57 | 11:51:52.670 | 4 ms, 161 bytes | 9.28 s |
Both times the phone was dozing as well, at 11:51 after a minute without traffic, and woke on the first or second beacon that flagged the request. Each reauthentication ran the full EAP-TLS handshake, to EAP-Success at 11:39:21.443 and 11:52:02.123.
The drop, unseen¶
The beacons flagged a frame for the phone from 12:05:21.23 to 12:05:22.25, 48.3 s after the first request was queued. The phone did not wake for it, and the next beacon no longer flagged it: the AP had dropped the frame with the phone. Which frame it was the air does not show; Mist's reason 2, previous authentication no longer valid, is the deauthentication the AP meant to send. The 48 s match the case of 2026-10-26, where the RADIUS server left the reauthentication unanswered and the AP's deauthentication went on the air about 48 s after its first request.
Reason 7¶
At 12:05:33.465 the phone woke for its keepalive and sent its frame, which the AP's hardware still acknowledged with a Block Ack. 1.2 ms after that Block Ack the AP sent a deauthentication in the clear with reason 7, class 3 frame from a non-associated station: it no longer held the phone as associated, and had no keys for it. The phone, with PMF, did not take an unprotected deauthentication on trust: it sent an SA Query at 12:05:33.468, 33.878 and 34.281, 4 bytes each by their size, which the AP left unanswered, and disassociated itself at 12:05:34.680, protected.
The logins after it¶
| First attempt | Second attempt | |
|---|---|---|
| Authentication, association | 12:05:34.992, AID 54 | 12:05:42.141, AID 55 |
| RADIUS round trips to the client's certificate flight | 22, 20, 20, 17, 15 ms | 20, 19, 18, 19, 19 ms |
| Client's certificate flight | 12:05:35.218 | 12:05:42.436 |
| The AP's next request | none | 12:05:52.009, after 9.57 s |
| End | the phone starts over 6.92 s later, no frame between | EAP-Success 12:05:52.040, the 4-way after it |
After the first attempt nothing went over the air for 6.92 s, from either side; then the phone authenticated and associated again, without a deauthentication or disassociation first. The server's step after the client's certificate took 9.96 s in the login at 11:26, 9.28 s in the reauthentication at 11:51, 9.57 s here, and 20 ms in the reauthentication at 11:39. The phone waited 9.3 to 10.0 s three times and gave up after 6.9 s once.
Mist¶
| Time | Event | Fields | The portal's text |
|---|---|---|---|
| 12:05:35.009 | MARVIS_EVENT_CLIENT_AUTH_FAILURE |
reason 2, authorization_reason_code 23, time_since_assoc 2,335,164 ms |
Reauthorization STA restarts 802.11 authentication/association, before authorization complete(768). 802.1x Auth Fail(23). |
| 12:05:42.158 | MARVIS_EVENT_CLIENT_AUTH_FAILURE |
reason 2, authorization_reason_code 23, time_since_assoc 7,148 ms |
STA restarts 802.11 authentication/association, before authorization complete(768). 802.1x Auth Fail(23). Timeout, Radius Server Failed to respond to request(514). |
| 12:05:52.082 | CLIENT_AUTH_ASSOCIATION |
time_since_assoc 9,911 ms |
|
| 12:05:52.13–52.55 | ARP, DHCP, DNS | dns_latency 103 ms |
Mist logs each failure as the phone's next association comes in, and words both as the station restarting before authorization was complete. The first belongs to the association of 11:26:39.83, after the reauthentication had run 62 s; the second to the first attempt, which RADIUS had not answered in 6.9 s. mist.json keeps the codes, text_codes 768 and 23, and 514 for the second; the word "Reauthorization" is in the text alone, the large time_since_assoc in the fields. Mist logged no CLIENT_DEAUTHENTICATION, where on 2026-10-26 it logged one with reason 2.
The answers¶
The cause. The phone left the AP's reauthentication unanswered. It fetched five EAP-Request Identity frames on its wakes, acknowledged each at the MAC layer, and sent nothing back; the AP did what 802.1X asks of it, asked again with a growing interval, and dropped the phone after 48 s. Twice before in the session the phone answered the same request within 4 ms of fetching it. What differs on the air is the phone's state: idle for eleven minutes, waking every 30 s and between them for every few beacons only. The developer's account adds that the screen had gone black after the video. The side is the client's.
Reason 7. The AP's answer to the phone's first frame after the drop. It says the AP no longer held the phone as associated, not why: the code ties the frame to that event and to the AP as its sender, and the event came 12 s after the AP had ended the connection without the phone hearing of it.
The time without a connection. The phone had no data path from the drop at 12:05:21.2 to 22.4 until its 4-way at 12:05:52.05, about 30 s. It knew of the drop only from 12:05:33.47: until then it held itself connected. During the 48 s of the reauthentication its traffic still went through.
The reauthentication interval. The AP started each reauthentication 751 s after the previous EAP-Success: 751.2 s after the login at 11:26:50.044, 751.1 s after the first reauthentication, 750.8 s after the second (to the beacon that flagged the request, which the AP queued at most 102 ms before). From the association it was 761.4 s the first time only because that login took 10.2 s. The case of 2026-10-26 counted 760.4 to 760.5 s from an association whose login the capture did not hold; with a login of ten seconds, as here, that is 751 s after its EAP-Success too.
The logins after it. Upstream, as in ap45-radius-slow-login: the server's step after the client's certificate took about 10 s, and the phone abandoned the first attempt before it ended. That made the reconnect 18.6 s long from reason 7 to the 4-way.
What the sensor can and cannot show. It sees that the phone received the requests and answered none, and that the AP stopped asking where the phone had to answer. It does not see why the phone did not: whether its supplicant ran at all in that state, or ignored a reauthentication while the phone was locked. One unanswered reauthentication is one point; whether the locked phone leaves every reauthentication unanswered is item 139's lab repeat.
The app's outcome¶
"On the AP side", from ap-disconnect: "Disconnected by the AP. Reason 7: class 3 frame from a non-associated station. The standard ties reason 7 to the AP." Beside it radius-latency, upstream, "Slow RADIUS server": 9958 ms over the whole session (the login at 11:26), 9574 ms in the two minutes around the disconnect. Neither names what ended the connection: no rule reads a reauthentication the client leaves unanswered, and ap-disconnect takes reason 7 as the AP's side.
The recording, cut to 12:04 to 12:06 and anonymized, is the test session ap45-phone-reauth-asleep (test data), with client side as its expected outcome and the AP side as a known mismatch until the rule of item 139.
What Linkside added over Mist alone¶
Mist said the station restarted its association before the reauthorization was complete, with reason 2, and no deauthentication. The capture adds that the phone fetched and acknowledged the AP's identity request five times in 41 s and answered none, where twice before in the session it answered within 4 ms; that the AP stopped asking where the phone had to answer and dropped it, its frame for the phone never on the air; that the phone learned of it 12 s later, from reason 7 to its keepalive and an SA Query nobody answered; and that the reconnect after it waited about 10 s on the RADIUS server.
To check¶
- The locked phone in the lab, against the same phone with its screen on: item 139.
- On the RADIUS side, the slow step after the client's certificate and the Session-Timeout behind the 751 s: the list of the case of 2026-10-26.