Survey the 802.15.4 channels and confirm capture feasibility

Mechanism

A 2.4 GHz Zigbee PAN operates on a single IEEE 802.15.4 channel and stays there for the life of the network, unlike BLE, it does not frequency-hop across the band [ieee802154-2020]. The 2.4 GHz PHY defines sixteen channels numbered 11 to 26, spaced 5 MHz apart, with channel k centred at Fc = 2405 + 5(k − 11) MHz, i.e. 2405 MHz (ch 11) to 2480 MHz (ch 26), each occupying roughly 2 MHz, modulated as O-QPSK with DSSS at 250 kbps [ieee802154-2020]. Because the PAN is pinned to one channel, the Spectrum-layer task is a channel scan to find that channel and read the PAN’s identity, not a hop chase.

There are two ways to find the channel, and they differ in whether they transmit. An active scan sends a MAC beacon request on each channel and records the beacons that answer, yielding the channel, the 16-bit PAN ID and stack/profile hints in seconds; KillerBee’s zbstumbler is the canonical implementation, walking the channels and logging every PAN that responds [killerbee]. Active scanning is defined by the standard as the coordinator/device discovery primitive [ieee802154-2020], but it is observable to anyone listening and perturbs the network. A passive survey instead listens only, an energy/ED-style sweep or a frame-logging channel hop that never sends a beacon request. Kismet channel-hops the 802.15.4 band and logs every PAN, coordinator and device it hears to pcapng without transmitting [kismet]; on a CatSniffer, catnip’s cativity mode draws a live per-channel activity table and can map coordinator/router/end-device topology [catsniffer-tools]. A wideband SDR waterfall (gqrx) is only a coarse cross-check: it shows energy, not Zigbee frames, and cannot by itself tell Zigbee from Wi-Fi or BLE in the shared band.

Capture feasibility is dominated by Wi-Fi coexistence: 802.15.4 shares 2.4 GHz with 802.11, whose ~20 MHz channels overlap several Zigbee channels at once, so a target on a Wi-Fi-congested channel may be hard to capture cleanly. AN1017 frames the defence as frequency separation, place the 802.15.4 channel as far as possible from the Wi-Fi channel, ideally at the opposite end of the 2.4 GHz ISM band, because adjacent-channel performance can be up to 20 dB worse than the “far-away” case [silabs-an1017]. The non-overlapping Wi-Fi channels 1/6/11 occupy the same frequencies as Zigbee channels 11 to 22 [metageek-coex], so practitioners commonly place a PAN on a higher channel above that traffic; the non-overlapping Zigbee channels 15, 20, 25 and 26 sit in the gaps outside almost all standard Wi-Fi settings and are the common choices [haade-zigbee-channels], with channel 26 often the least Wi-Fi-affected but supported by fewer devices. Note a North-American regulatory constraint: AN1017 states Zigbee channels 25 and 26 require reduced transmit power to meet FCC requirements [silabs-an1017].

Procedure

Authorised testing only. Step 1 (active scan) transmits 802.15.4 beacon requests into the RF environment; run it only against networks you are authorised to assess, ideally in an RF-shielded setup or with explicit permission. Where stealth or non-interference is required, skip to the passive survey in step 2.

1. Active scan, find the channel and PAN ID fast (transmits). Walk the 16 channels with KillerBee, sending beacon requests and logging responders:

   zbstumbler

   Expected output: one line per discovered PAN, e.g. New Network: PANID 0x1A62 Source 0x0000 Ext PANID ... Channel 15 Stack Profile: ZigBee PRO. Record the Channel and PANID of the target, that is the channel you will park a capture radio on. No responders on any channel means the network is out of range, on a non-default channel set, or not answering beacon requests (try the passive survey).

2. Passive survey, confirm without transmitting. Channel-hop and log every PAN/device heard, sending nothing:

   kismet -c nrf52840.0:name=zigbee

   (Substitute your 802.15.4 datasource; a CatSniffer v3 Zigbee source is specified manually as a serial port.) Expected: Kismet’s UI lists 802.15.4 devices/PANs with their channel as it hops, and writes a .kismet/pcapng log. Cross-check the channel and PAN ID against step 1; a passive hit on the same channel confirms the PAN is observable from your position.

3. CatSniffer: per-channel activity and topology (CatSniffer kit). On a CatSniffer, see which channel is busy at a glance and optionally map the mesh:

   python3 catnip.py cativity
   python3 catnip.py cativity --channel 15 --topology --protocol zigbee

   Expected: a live per-channel activity table (default mode) highlighting the busy channel, then a fixed-channel detail view and a coordinator/router/end-device topology for the chosen channel.

4. SDR waterfall, coarse spectrum cross-check (optional). Tune an SDR to the target channel’s centre to judge signal strength and Wi-Fi overlap before committing:

   gqrx

   Tune to Fc = 2405 + 5(k − 11) MHz for channel k (e.g. 2425 MHz for channel 15). Expected: a ~2 MHz Zigbee burst pattern at the channel centre, often beside much wider Wi-Fi energy. This only confirms energy is present, it does not decode frames; use steps 1 to 3 to confirm it is Zigbee.

5. Record feasibility. Note channel, PAN ID, observed signal level and the Wi-Fi overlap. This is the hand-off to the LL-layer capture control: the channel to park on and whether capture is clean or contended.

Field case

Illustrative walkthrough, substitute the values you capture. A bench survey of a Zigbee 3.0 smart-bulb hub on an authorised test network would run as follows. zbstumbler (KillerBee, nRF52840) reports a single PAN: PANID [FILL: observed PAN ID] on channel 15 with Stack Profile ZigBee PRO. A passive Kismet sweep over the same band confirms the PAN on channel 15 and records [FILL: device count] distinct 802.15.4 devices, sending nothing on air. On gqrx tuned to 2425 MHz (channel 15 centre), the ~2 MHz Zigbee bursts appear in a gap beside a Wi-Fi AP on Wi-Fi channel 6, signal [FILL: measured RSSI/dBm], read this against your environment to judge whether capture is clean. Conclusion in this illustration: capture feasible on channel 15; hand off to the LL capture control parked on that channel. The [FILL: …] items are placeholders for the values you measure on your own engagement, not reported findings.

Remediation

Channel survey is reconnaissance; “remediation” here is reducing the exposure and interference it depends on, layered by role.

• Developer / stack vendor: Do not leak network identity before encryption is in force. The channel and PAN ID are inherently observable (they are layer-1/MAC), so the defence is to ensure nothing of value is readable from beacons or pre-join traffic, and to support install-code / Zigbee 3.0 joining so that locating the network does not advance an attacker toward the key (see the CR-layer control).
• Integrator: Choose a channel deliberately. Maximizing frequency separation from local Wi-Fi improves reliability [silabs-an1017], and placing the PAN on a higher channel above the common Wi-Fi traffic (e.g. 15/20/25/26) is the usual channel-planning advice [haade-zigbee-channels], which incidentally also makes the network easier to capture cleanly, so weigh coexistence against exposure, and prefer install-code joining so a located PAN is not a joinable one. Avoid the well-known default Trust Center link key.
• Operator: Treat the RF environment as observable. A surveyable, fixed-channel PAN is normal and cannot be hidden; monitor for anomalous beacon-request floods or unexpected rejoin activity (signs of active scanning/disruption) and ensure devices that briefly expose identifiers (e.g. at join) do so only during controlled commissioning, not continuously.