Roaming between the two AP45s¶
Setup on 2026-11-02¶
| Part | Details |
|---|---|
| APs | The AP45 and the second AP45 on the home site in Mist, eduroam on both (key_mgmt WPA3-EAP-FT/CCMP in Mist's events, no MLO), channels from Mist: by Mist's events the AP45 on 5 GHz ch 132/20, the second AP45 on 5 GHz ch 36/20 and 2.4 GHz ch 6; eduroam's other BSSs in the BSS table, which no event tied to an AP, on 2.4 GHz ch 11 and 6 GHz ch 5/80 and ch 21/80 |
| Client | The phone (an iPhone with a private address on eduroam), HE, two streams, AKM 3 (FT-802.1X) |
| Sensor | The Pi next to the AP45 (its 5 GHz at −42 dBm), the Mac beside it, its Wi-Fi on 5 GHz ch 48, which the Overview's chip had overlapping ch 36, where capB listened. capA on 5660/20, the phone's BSS; capB on 5180/20, the second AP45's 5 GHz (strongest neighbor with the same SSID, 16.8 dB weaker) |
| Method | The app recorded from 15:55:04 to 16:02:20 with Mist (commit f4900f4): the phone's Wi-Fi off and on for the reconnect, a download, then the phone carried to the second AP45. The sensor stays put. The recording is outside the repo, in ~/linkside-captures/2026-11-02-1555-… |
The walk¶
By the Mac's clock:
| Time | What | Seen by |
|---|---|---|
| 15:56:13.190 | Association to the AP45's 5 GHz with a full EAP-TLS login and the 4-way: the initial mobility domain association | sensor, Mist |
| 15:56:15 | The phone carried away: from −32 dBm at the sensor at 15:56:15 to −69 dBm at 15:56:40. From then on its data at HE MCS 11 is not decoded, its Block Acks and Null frames are | sensor |
| 15:59:40.274 | Its last frame on ch 132, a Null with PM 1 | sensor |
| 15:59:40.4 | An 802.11r roam to the second AP45's 2.4 GHz BSS on ch 6: MARVIS_EVENT_STA_LEAVING on the AP45's 5 GHz BSS with reason 8 and time_since_assoc 207 s, CLIENT_AUTH_REASSOCIATION_11R on the 2.4 GHz BSS (time_since_assoc 8 ms), CLIENT_DNS_OK there 218 ms later, and MARVIS_EVENT_ROAMING_SUCCESS with the AP, band and channel and no BSSID, prev_ap the AP45, prev_channel 132 and prev_rssi −68 dBm; Mist's stats of 16:00:08 have the phone at −37 dBm at the AP |
Mist alone |
| 16:00:10.7 | Probe requests on ch 36 and on ch 132 | sensor |
| 16:00:11.012 | FT authentication to the second AP45's 5 GHz; its answer 11 ms later | sensor |
| 16:00:11.025 | Reassociation request: AKM 3 with a PMKID (the PMKR1Name), Current AP the AP45's 5 GHz BSS | sensor |
| 16:00:11.028 | Reassociation response, status 0, AID 51 | sensor |
| 16:00:11 | MARVIS_EVENT_ROAMING_SUCCESS on ch 36, prev_ap the second AP45 itself, prev_band 24 and prev_channel 6, and CLIENT_AUTH_REASSOCIATION_11R on the 5 GHz BSS (time_since_assoc 4 ms) |
Mist |
Neither radio heard the phone for 30.4 s, less than LiveOptions.searchAfter (60 s): no search ran.
The Current AP of the reassociation¶
The phone's reassociation request to the second AP45's 5 GHz named the AP45's 5 GHz BSS as its Current AP: the BSS it had left 31 s and one roam before. It came from the second AP45's 2.4 GHz BSS, where Mist had it with a DNS answer and its stats, and Mist's own event of the roam says so: prev_ap the second AP45, prev_band 24, prev_channel 6 (mist-events.md). Whether iOS names the AP of the initial mobility domain association, or keeps the last one it saw on another band, one roam does not tell.
The engine takes the Current AP as the AP the roam leaves (definitions); with this phone that can be an AP of an earlier roam. What it made of the session at f4900f4:
- One roam, from the AP45's 5 GHz to the second AP45's 5 GHz, 802.11r in 16 ms (the FT authentication to the reassociation response: the phone had not been in use on ch 132 before it, so no time off the air counts).
- A signal change of −15.4 dB in the report and a
weaker-roamanomaly of 14.3 dB, both the AP45's 5 GHz against the second AP45's 5 GHz at the sensor. The roam was the second AP45's 2.4 GHz to its 5 GHz, with the phone at −68 dBm at the sensor: the hint held back ("client away from the sensor"). - Roaming read "1 roam, up to 16 ms": Mist's roam to 2.4 GHz stood in the story as lines of Mist under "While connected" and counted nowhere.
Mist's events place the phone; the air placed it only by the field the phone fills. Taking Mist's roam events into the client's connection is item 018.
The AP's single MPDU after the phone's CTS¶
Over the session the AP45 left 170 of its 1,564 TXOPs that start with an RTS without a Block Ack after the phone's CTS; with the phone next to the sensor at −33 to −44 dBm, before 15:56:25, about 115 of 1,090 on ch 132 (counted in the capture by hand, paired as the engine pairs them). In each the AP sent one MPDU, the phone sent nothing back, and the AP sent the RTS and the MPDU again with the retry bit. The sensor captured the MPDU at −47 dBm, so it went on the air. In the window of the note (15:55:43 to 15:56:03) 31.6 % of those TXOPs failed and 28 % of the AP's frames went again, all right after the phone's wakes from power save, with BA success at 99 %: the TXOP loss that BA success does not count (txop-loss.md), in the bursts after the wakes (power-save.md), as on 2026-11-01 (txop-loss.md).