Skip to content

The Mac on the measured channel

Idle and with a speed test on the client's BSS, 2026-10-25

The question of the Mac as a transmitter: does the Mac that drives the app, a meter from the sensor, spoil a focus when its Wi-Fi sits on the channel the sensor listens on? The app warned red on any overlap, an assumption.

The home lab. The AP45 broadcasting eduroam on 5 GHz alone, ch 128 at 20 MHz, its 2.4 and 6 GHz radios disabled for the run: an iPhone otherwise stays on 2.4 GHz, and the MacBook would take 6 GHz. The iPhone as the client 1 m from the sensor, downloading a 10 GiB file over HTTPS in Safari, Auto-Lock off. The Pi with both sticks on its USB 3 ports, capA on the AP45's BSS, capB on 6 GHz ch 37 out of the way; the MacBook a meter from the sensor, awdl0 down. One live session of fourteen minutes (21:21 to 21:35 CEST), the app at cc85b5a, tshark 4.6.8; the recording is outside the repo. Mist put the channel at 83 to 87 % utilization during the download.

Three states of the Mac, run twice: on the home IoT SSID on 2.4 GHz (A, the baseline), associated to the client's BSS and idle (B, the app red), and on that BSS with a speed test run again and again (C). The bounds come from the capture: the AP45's association response to the Mac opens B, its deauthentication of the Mac (the Mac leaving for the IoT SSID) ends C. The download ended during the second A and ran again on its own at a quarter of the rate, so the second round compares at that load; it failed at the end of the second C. Each phase was cut from capA.pcap with a few seconds off each bound and replayed on its own (linkside-cli replay).

Phase The Mac Seconds Downlink delivered (MPDU/s) BA success down Capture share down / up Retry bit down TXOPs failed down / up
A IoT SSID 120 7,944 99.6 % 1.000 / 0.88 2.3 % 1.8 / 12.4 %
B idle on the BSS 118 7,943 99.6 % 1.000 / 0.95 2.2 % 1.4 / 12.4 %
C speed test 115 3,984 99.1 % 0.998 / 0.88 3.7 % 2.8 / 15.1 %
A, second IoT SSID 122 2,416 99.9 % 0.988 / 0.93 1.4 % 2.7 / 4.0 %
B, second idle on the BSS 98 2,442 99.8 % 0.990 / 0.88 1.3 % 1.9 / 1.5 %
C, second speed test 76 894 99.4 % 0.969 / 0.77 2.9 % 1.7 / 3.6 %

linkside-cap counted no drop in the whole session, and no phase raised a hint: each came out "Nothing abnormal found".

  • Idle, the Mac changes nothing measurable. B against A, in both rounds: the same downlink, the same BA success, the same capture share of the downlink, the same retry bit. Its traffic was Mist's polls and a chat; the AP45 sent it some 10 to 50 control frames a second.
  • With traffic of its own, the Mac changes the client's situation, not the sensor's view of it. The speed test took half the airtime of a channel already near full: the phone's downlink halved, and the AP sent 1.5 points more of its frames again. That is contention the client lives through and the session then measures as the client's; the capture of it stayed complete, the downlink's share 0.97 to 1.00 and BA success above 99 %.
  • The uplink's capture share moves without the Mac, from 0.77 to 0.95, with the lowest in the second C, while the phone's download was failing. The uplink was TCP acknowledgements alone; one run does not separate the Mac from that noise.
  • Not covered: the Mac on another BSS whose channel overlaps the sensor's without being the client's, where it defers to the client's AP only by energy detection; wider channels; a client farther from the AP. The first is the case most likely to block the sensor's receivers; the home lab's APs leave no such overlap with ch 128, and it waits for another run (item 115). So does AWDL: every run had awdl0 down, and what it sends while up and idle is not measured.

From this the app's warning: the Mac idle on a channel the sensor listens on is a quiet note, as for the same band; with traffic of its own there, at least 1 Mbit/s over 10 s from the Wi-Fi interface's byte counters (TrafficMeter), it is red. The threshold is set, not measured: a call or a sync is above it, Mist's polls far below.