Skip to content

A passive sensor

The sensor is a tap on the air, like a SPAN port: it receives and never transmits. That keeps it out of what it measures, and keeps it acceptable on a network it does not belong to.

What the sensor never does

  • No 802.11 frame of its own. No probe request, no association, no active scan. The radios run in monitor mode without the flags that would make them acknowledge or send.
  • No deauthentication, not even to force a reconnect. When the app needs the client to join again, it asks for the user to do it.
  • No Wi-Fi of its own. The Pi's onboard Wi-Fi and Bluetooth are off, and NetworkManager does not manage the measurement radios. The sensor is no access point and joins no network.
  • No connection to the site's LAN. The Pi talks only to the Mac, over Ethernet with an IPv6 link-local address: no DHCP, no gateway.

One residual emission is known: the MT7925 chip sends a short burst when it retunes, which happens while the radios sweep channels (the context scan, the search for the client), not while they are locked on the client.

linkside-radio status checks it before every session: only monitor interfaces on the Pi, no radio managed by NetworkManager. The rule 1 measurement checked it on the air, each radio listening for the other's address.

The Mac is a transmitter

The Mac is not passive: its Wi-Fi stays on the site's network for Mist, and AWDL (AirDrop, Handoff) and Bluetooth transmit too. Its frames fall outside the sensor's filter; what matters is the airtime on the channel measured and a strong transmitter a few centimeters from the sensor's receivers. So the Mac sits about a meter from the sensor, and the app shows per channel where the Mac's own radios are:

  • red: AWDL on a channel the sensor listens on, or the Mac's Wi-Fi there with traffic of its own: at least 1 Mbit/s over 10 s, such as a download, a call or a sync. The traffic stops, or the Mac's Wi-Fi goes off and the Mac takes internet from a phone by USB tethering, the phone's Wi-Fi off. AWDL goes down with sudo ifconfig awdl0 down in Terminal, which the app gives with a Copy button.
  • a quiet note: the Mac's Wi-Fi on a channel the sensor listens on and idle, on the same band, or not connected (it scans). It names the client's AP where the capture shows that AP serving the Mac's address.
  • nothing: another band.

The tethering phone is not in the app: with its Wi-Fi off it sends nothing, and the Mac does not know its Wi-Fi address. Its Wi-Fi off is the operator's check.

Idle on the client's own BSS, with only Mist's polls, the Mac changed nothing the sensor measured; a speed test on it took half the client's downlink, contention the session would then judge as the client's, while the capture stayed complete (the measurement). The Mac on another BSS whose channel overlaps the sensor's is not measured yet.

What the sensor keeps

The sensor captures only the client's frames and the AP's management and control frames, and cuts every frame to what the analysis needs: management, control and EAPOL-Key in full, EAP up to its type, data frames to their MAC and encryption header. The payload is encrypted anyway and is never kept. linkside-cap has the full list.