Mist's AP capture¶

Setup on 2026-10-29¶

The AP45 at home in the work org, firmware 0.14.30332, broadcasting eduroam on 5 GHz ch 104/20 (5520 MHz), its other radios on 2.4 GHz ch 11/20 and 6 GHz ch 5/80. The phone (an iPhone with a private address on eduroam) the only client, at −52 dBm at the AP in Mist's stats, playing a 4K video it had mostly buffered: about five Block Acks a second each way. The org token with the Helpdesk role (linkside-cli mist self: ap_pcap=yes). Three captures one after the other, each requested with POST sites/{site_id}/pcaps/capture for 60 s with max_pkt_len 512, num_packets 0 and format pcap:

No sensor capture. Read with tshark 4.6.8, linkside-cli radiotap and linkside-cli replay (a build of 2026-10-24).

The request and the result¶

• The POST answers at once with the capture's id, its expiry (the start plus the duration) and, for scan, pcap_aps with the band, the channel and the width per AP; also two fields the API spec does not name, raw (false) and tcpdump_parser_expression (null).
• GET sites/{site_id}/pcaps/capture answers {} once the capture has ended. GET sites/{site_id}/pcaps lists it with url, num_packets and termination_reason 30 to 31 s after its end. The URL is on the API host and takes the token; each download took under a second: 231, 168 and 448 KB.
• The file is a pcapng of 802.11 with radiotap, its interface named scan or radiotap.
• The first scan ended after 34.8 s with 1,243 frames, termination_reason "default"; the other two ran their 60 s. Why it ended early is open.

The scanning radio, type scan¶

• Every frame came at legacy 24 Mbit/s, 20 MHz: no HE PPDU at all, also not the AP's own data, which reaches the scanning radio at −12 dBm. The scanning radio, or Mist, passes no HE frame, and the data's capture share is 0.
• Radiotap carries TSFT, signal, noise, rate and channel on every frame: the AP at −12 dBm in its own enclosure, the client at −51 to −56 dBm, −52.1 on average as in Mist's stat, and a neighbor BSS on channel 104 at −81 dBm, whose RTS, CTS and Block Acks are among the other stations' frames. The noise is −94 dBm on all 2,621 frames of the second run: the radio's noise floor, not a value per frame.
• The radio held the channel: every beacon of the AP's BSS in both runs (9.8 a second), no gap beyond 105 ms. The second run's first 25 ms were on 5240 MHz, the scanning radio's previous channel, with six beacons of the U7s on channel 48.
• client_mac does not filter scan: the second run held the beacons and the neighbor's frames as the first.

The engine on the scanning radio's capture¶

linkside-cli replay on the pcapng as it came, with the phone as the client:

The AP's TXOPs failed in the second run and not in the first. Without the sensor's capture of the same minute it is open whether the client left them unanswered or the scanning radio missed the CTS and the Block Acks.

The serving radio, type radiotap¶

• 562 frames in 56.9 s: 282 QoS data frames from the AP (HE MCS 11 and 10, two streams, 20 MHz, GI 0.8 µs), 201 from the client (HE MCS 11, two streams), 78 Null frames from the client at 24 Mbit/s and one probe request. No control frame and no beacon, as a capture in the portal found before (Wi-Fi PCAP with Mist, 2024: most control frames and beacons missing).
• The data frames come decrypted: the Protected bit clear, the LLC, IP, UDP and QUIC headers readable up to the 512 bytes.
• The AP's own frames carry their rate and a signal of 0 dBm, as sent; the client's at −49 to −53 dBm, −51.2 on average, each with a noise of −96 dBm.
• No retry bit set and no sequence number twice. Whether the capture holds every data frame or only first transmissions is not measured: 483 data frames in the minute is the order of what the Block Acks acknowledged in the minute after.