The testlab's APs on the air¶

6 GHz on 2026-10-23¶

A sweep of capA over every NL 6 GHz channel (1 to 93) at 20 MHz, 150 ms dwell, three rounds, with beacons, probe responses and FILS Discovery; the BSS's own HE and EHT Operation elements give its channel.

• No AP at home sets the Duplicate Beacon bit, so the RSSI of a duplicate beacon at 20 MHz against the full width is not measurable here.
• Every 6 GHz primary is a PSC: the U7s' RNRs on 2.4 and 5 GHz name 53 and 85, which the sweep visits anyway, so the sweep that adds the RNRs' channels has nothing to add at home.
• AP A was at 85/320, not at the 37/160 of the runbook. At 320 MHz the A9000 hears the beacons, not the data.

The U7's scanning radio, 2026-10-23¶

capA on 2.4 GHz channel 11 and capB on 5 GHz channel 149, 30 minutes each at 20 MHz: channels where neither U7 has a BSS (their BSSs sit on 6 and 7, 40 and 48). linkside-cap kept every frame whose transmitter address has the second and third byte of the U7s' addresses (wlan[11] = 0x2a and wlan[12] = 0x6f), which their BSSIDs and the locally administered variants of them share.

• Neither radio caught a frame: recv=0 on both after 30 minutes. The same filter on channel 48, AP A's 5 GHz BSS, kept 134 frames in 5 s.
• The scanning radio sent nothing with a U7 address on those two channels: no probe requests, it scans passively there. A probe request with an address of another prefix, or on another channel, this test does not cover.

The kick from the controller¶

Reconnect in UniFi Network on the A9000 client, twice two minutes apart, on AP A's testroam 5 GHz ch 48/80 with WPA2-PSK (AKM 2, no PMF), UDP at 2 Mbit/s both ways (testlab-ap-kick, 2026-10-20). Each time a disassociation from the AP in the clear with reason 1 (unspecified), the client's traffic going on until it, and the client's authentication 0.44 s after it, connected again with the 4-way 0.54 s after it. Every beacon of AP A carries a vendor-specific element with Ubiquiti's OUI 00:15:6D, beside Qualcomm's and Microsoft's: the engine knows a UniFi AP by it (reason codes). Without PMF the frames do not show who began; UniFi's use of reason 1 for the kick does.

The AP45's answer to a Block Ack Request, 2026-10-30¶

The phone on eduroam on the AP45's 5 GHz ch 112/20, a video and one reconnect of its own (ap45-phone-video-reconnect). After the reconnect the phone sent four Block Ack Requests to the AP, for TID 6, 0, 5 and 1, each right after its Block Ack setup for that TID. The AP answered each 48 µs later on the radio's TSF with a compressed Block Ack with the request's SSN and an empty bitmap, labelled TID 0 every time (BA Control 0x0005). Its Block Acks after the phone's A-MPDUs carry the TID of the data (TID 0, 1, 5 and 6 in the session, 3035 with bits), and the phone's answers to the AP's requests carry the request's TID. In the eleven AP45 recordings of the test data every answer of the AP to a request of the phone for TID 1, 5 or 6 says TID 0.

The standard has the answer carry the request's TID. Taken by its label, the answer to the request for TID 6 (SSN 2) set where the phone's TID 0 flow went on, and the phone's request for TID 0 four seconds later (SSN 13) gave up 2 to 12: EAP responses, M2, M4 and four data frames the phone had sent before that agreement, each acknowledged by the AP with an ACK 44 to 53 µs later. That made "Losses both ways" in the reconnect's window, 86.9 % BA success up. The uplink losses of eight recordings were of this kind and nothing else: 8 in ap45-phone-reconnect, 13 in ap45-radius-unanswered-login (with its "Losses towards the AP"), 7 in ap45-phone-reauth-asleep, 6 each in ap45-radius-slow-login, testlab-client-leaves-eduroam and testlab-ip-services-dns, 4 in ap45-phone-band-roam, and 28 of the 31 in testlab-long-quiet. Since then a BA that answers a request goes on the request's flow (BlockAckTracker.answer).

The AP45's beacon sequence numbers, 2026-10-30¶

The same recording, ap45-phone-video-reconnect, beacon interval 100 TU on both of the AP's radios. The sequence number steps by one per beacon interval: of the 5,622 steps between consecutive beacons of its 5 GHz BSS on capA, 5,610 were +1 across one interval, and of the 5,457 of its 2.4 GHz BSS on capB 5,440. Across two intervals the step was +2 four times on 5 GHz and fourteen times on 2.4 GHz, across three +3 once on 5 GHz, and across 2.9 and 13 s of capB's sweep +29 and +127: beacons the AP sent and the sensor did not take. Across two intervals the step was +1 once on each radio: a beacon the AP did not send. Six times on 5 GHz the step was +2 or +3 within one interval: a number went to another frame of the AP's, or was skipped, so a step larger than the intervals spanned tells neither. The step across the longest gap is BSSEntry.largestBeaconGapSequenceStep; Surroundings gives it with the beacons the gap spans.