Testlab baseline¶
Setup on 2026-10-20¶
| Part | Details |
|---|---|
| AP | AP A, a U7 Pro Max: the home SSID on 5 GHz ch 48/80 (WPA2/WPA3 transition, 802.11r). Firmware not noted |
| Client | Stick B (A9000, MT7925U) on the Fedora PC, Fedora 44, kernel 7.2.10-200.fc44, mt7925u firmware 20260813113118, wpa_supplicant in a network namespace with psk.conf (WPA2-PSK, no PMF), pinned to 5240 MHz. EHT, two streams |
| Traffic | iperf3 UDP both ways, one client and server per direction, to the Fedora's own Ethernet port through the AP |
| Sensor | capA alone (stick A) on 5240/80, 1 m from the client. The AP at −36 dBm, the client at −38 dBm. The Mac on the IoT SSID (2.4 GHz), awdl0 down |
| Method | Traffic, Ctrl-C of wpa_supplicant, a reconnect, traffic again, recorded by the app |
Two runs¶
| 30 Mbit/s each way, 2 × 2 min | 2 Mbit/s each way, 2 × 1 min | |
|---|---|---|
| Recording | 1.48 million frames, 205 MB, 0 dropped; replay 3.5 min (debug build) | 44,771 frames, 5.8 MB, 0 dropped; replay 24 s. Test data: testlab-baseline |
| Block Acks per second, each direction | 1,600 to 2,000 | 173 |
| BA success, AP to client | 99.7 % | 100 % |
| BA success, client to AP | 99.9 % | 100 % |
| Captured, AP to client | 92 % | 5 % |
| Captured, client to AP | 11 % | 3 % |
| Rates of the captured frames, AP | EHT MCS 11 (66 %), 12 (29 %), 10 | EHT MCS 13 (46 %), 12 (42 %), 11 |
| Rates of the captured frames, client | EHT MCS 12, 11, some MCS 12 at 40 MHz | EHT MCS 12, 11, MCS 13 at 40 MHz |
| iperf3 loss | 0 and 2 of 310,000 datagrams | not noted |
Under load the AP's frames the sensor decoded are mostly MCS 11; at 2 Mbit/s mostly MCS 12 and 13, and the sensor decoded one frame in twenty. A lower MCS under load fits the higher share; the rates of the frames the sensor missed are not known. The uplink stays low in both runs, at the same signal; its cause is open. The Block Acks are complete in both runs, so the BA success does not depend on it.
The reconnect¶
In both runs the first 4-way handshake after the reconnect stopped after M3: the AP sent M3, the client never sent M4, and the AP deauthenticated with reason 15 after 3 s. The second attempt completed 14 s after the first. It happened in three of the four starts of wpa_supplicant that day; wpa_supplicant logs "4-Way Handshake failed - pre-shared key may be incorrect", and the regulatory domain changes from the AP's Country element between the association and the 4-way. A wrong passphrase looks different over the air: it stops after M2.
After the reassociation the AP starts a new Block Ack agreement at sequence 0 (ADDBA with SSN 0, buffer 256). The client's first Block Ack starts at 3842 with only the bits for 0 and 1 set: the MT7925 reports the 256 sequence numbers up to its newest. Counted from bit 0, those were 254 losses, 23 % in the 20 s window of the reconnect at 2 Mbit/s and a "Losses towards the client" hint. The engine therefore counts a flow's first Block Ack from its first acknowledged bit (definitions).
Right after the 4-way the U7 Pro Max sends a neighbor report response the client did not ask for (RRM: Unexpected neighbor report in wpa_supplicant). Without PMF it is readable; the protected variant of roam-u7.md needs the client with SAE.
The 4-way with the client's ACKs, 2026-10-23¶
The same client on AP A's 5 GHz ch 48/80 with psk.conf, the focus filter now with the client's CTS and ACK to the AP: five restarts of wpa_supplicant and the reconnects after each failed 4-way, nine 4-ways in all, then two minutes of UDP at 2 Mbit/s both ways. The recording is ~/linkside-captures/2026-10-23-4way-ack, outside the repo.
- M1 went at 6 Mbit/s, and the client's ACK came 60 µs after it every time.
- M3 went out eight times, about 640 µs apart, the first 2.2 to 3.6 ms after M2. In seven of the nine 4-ways no attempt drew an ACK; in two the eighth did, 7.75 and 8.25 ms after M2.
- In four no M4 followed: the U7 did not send M3 again, and deauthenticated the client with reason 15, 3.1 s after the first M3. Between the two the client was there: it sent a QoS Null and acknowledged a VHT action frame of the AP. In the other three without an ACK seen M4 came anyway; in the one looked at, 1.5 ms after the last attempt, its first copy with the retry bit.
The sensor missed nothing: the client does not hear the AP for some 5 to 8 ms after M2, longer than the U7's eight attempts last. Each association brings CTRL-EVENT-REGDOM-CHANGE from the AP's Country element, and each disconnect sets the regulatory domain back; on 6 GHz the first association of the day failed with reason 15 right after "6 GHz was enabled". A client that reprograms its channels after M2 would do this; untested. The app found nothing abnormal then; m3-missed takes it now, client side, as the golden session testlab-4way-ack.
In the same session the AP sent the client 710 RTS: one went unanswered, and after 77 (10.8 %) a CTS came without a Block Ack (txop-loss.md).