Multi-Node WiFi Scanning: Building a Complete Picture of the RF Environment
WiFi scanning from a single position gives you a partial view. The APs you can see are the APs in range of that specific spot. The ones behind the wall, on the floor above, at the far end of the building - they may be invisible to you, but they're on the network. They're part of the security perimeter you're supposed to be assessing.
Shiver's multi-node WiFi scan addresses this directly. Multiple nodes scan simultaneously from their respective locations, and results are aggregated by BSSID. The combined view shows which APs were detected by which nodes, what signal strength each node saw, and which APs were invisible from some positions but visible from others. You get the full RF picture of a space rather than a single-vantage snapshot.
graph TD A[ Single-Device Problem ] --> B[ Distributed Scan ] B --> C[ Stagger Mechanism ] B --> D[ Aggregation Model ]
Table of Contents
- The Single-Device Problem
- How the Distributed Scan Works
- The Stagger Mechanism
- Aggregation Model
- Three-Phase Initiator Scan
- What You See in the Results
- Use Cases
- Limitations and Accuracy Notes
The Single-Device Problem
A typical office floor might have 20-40 access points deployed by IT, plus several rogue APs set up by employees who plugged in their own equipment, plus whatever is leaking in from neighboring tenant spaces. From the IT closet at one end of the floor, you might see half of these. From the cafeteria in the middle, a different half. No single position sees everything.
This matters for security audits in a few concrete ways:
Hidden APs are invisible from some vantage points. An AP locked inside a server room, or one that a previous red team left behind, might broadcast a signal that only reaches a small area. A single-point scan misses it.
RSSI-based device location requires multiple reference points. If you want to physically locate a rogue AP or an unauthorized device, you need signal strength readings from multiple positions to triangulate. One device gives you one distance estimate, not a location.
Coverage verification needs distributed data. Confirming that a corporate WiFi network provides adequate coverage to all areas of a facility requires scanning from all those areas, not just from one spot near the IT room.
How the Distributed Scan Works
The multi-node WiFi scan starts from the Execute menu on any paired Nano. Select WiFi, select Scan Networks, select target (individual node or All Devices). The initiating node sends CMD_WIFI_SCAN to all selected targets via the Shiver mesh.
Remote nodes receiving the command execute a grace-wait of 2.5 seconds before starting their scan. During this delay, they send MSG_GOING_OFFLINE to their neighbors (twice, at 0ms and 500ms for reliability), and the radio stays on the mesh channel long enough to ensure the command has propagated to further-hop nodes. After 2.5 seconds, the node begins its local WiFi scan using the ESP-IDF WiFi scan API.
The ESP-IDF WiFi scan is non-preemptible. While it runs, the mesh is suspended on that node. Nearby neighbors have been notified via GOING_OFFLINE and will hold off evicting this node during the scan duration. The scan typically completes in 5-10 seconds depending on how many channels are being scanned and how many APs are present.
After the scan completes, the node builds its results into a wire format: 42 bytes per AP (SSID up to 33 characters, BSSID 6 bytes, RSSI 1 byte, channel 1 byte, encryption type 1 byte). It then sends the results back to the initiator via EVENT_SCAN_AP. If the result set is large, the fragmentation layer handles splitting it across multiple ESP-NOW frames.
The Stagger Mechanism
If you send CMD_WIFI_SCAN to 8 nodes simultaneously and all 8 complete their scans at approximately the same time, you have 8 nodes trying to send large result payloads back to the initiator at the same time. With Shiver's fragmentation layer, each result set might be 3-10 fragments. Eight nodes x several fragments each = a collision storm that loses half the data.
The stagger mechanism prevents this. Each remote node delays its result transmission based on its ordinal position in the participating device list. Node 0 sends immediately, Node 1 waits 500ms, Node 2 waits 1000ms, and so on. The stagger ensures that result fragments from different nodes arrive at the initiator in a serialized stream rather than all at once.
This adds latency to the overall scan - a full 8-node scan where Node 7 staggers by 3.5 seconds takes longer to complete than an un-staggered approach. But un-staggered delivery loses data. The stagger is the right tradeoff for reliable results delivery.
Aggregation Model
The initiator maintains an aggregation table indexed by BSSID. Up to 32 unique APs are tracked (MSCAN_MAX_APS), with RSSI data from up to 16 participating devices (MSCAN_MAX_DEVICES).
For each AP, the table stores:
- SSID
- BSSID
- Channel
- Encryption type
- Per-device RSSI: a separate RSSI value for each participating node that detected this AP
- A sentinel value of -128 for nodes that didn't detect the AP (below any real RSSI value)
When Node 3's results arrive and it reports AP "CorpNet" at -72 dBm, the aggregator finds the existing entry for "CorpNet" (added earlier when Node 1 reported it at -45 dBm) and fills in Node 3's RSSI column. The final table entry for "CorpNet" might look like: Node 1: -45 dBm, Node 2: -68 dBm, Node 3: -72 dBm, Node 4: -128 (not detected), Node 5: -61 dBm.
This per-node RSSI data is the input to RSSI triangulation. With the physical positions of nodes known, you can estimate the physical location of any AP by applying the path loss model to the RSSI values from multiple nodes.
Three-Phase Initiator Scan
The initiating node manages its own scan in three phases:
Phase 1 (0-3 seconds): Command delay. The initiator sends CMD_WIFI_SCAN to remote nodes and then waits. The mesh stays active during this phase to ensure command delivery reaches all targets, including nodes multiple hops away.
Phase 2 (3-18 seconds): Remote result collection. The initiator stays on the mesh channel and collects EVENT_SCAN_AP results from remote nodes as they arrive. Fragmented results reassemble during this window. The mesh is fully active for fragment delivery.
Phase 3 (after remote results): Local scan. The initiator runs its own non-preemptible WiFi scan last. By doing its own scan after collecting remote results, it ensures remote nodes had time to complete and transmit their results before the initiator's own scan blocks the mesh. Total result wait timeout is 90 seconds - nodes that haven't sent results by then are dropped from the aggregation.
The three-phase approach reflects a real coordination problem in distributed systems: if the initiator does its own blocking scan first, it can't receive remote results during that time. Doing the local scan last keeps the mesh available for result delivery from all other nodes.
What You See in the Results
The multi-node scan results UI on the initiating Nano shows the aggregated AP list. For each AP, you can drill into per-device RSSI detail - a separate screen showing which of your deployed nodes detected that AP and at what signal strength.
The UI has two modes:
Initiator mode: Full scan results with progress tracking (how many nodes have responded), AP count, per-AP detail drill-down.
Remote mode: Simplified view showing that a scan was requested and that this node completed its portion. Remote nodes don't have the full aggregated data - only the initiator sees the complete picture.
APs that appear in the results but were only detected by one node are flagged as potentially interesting - they might be hidden APs, weak-signal devices, or APs at the edge of coverage that most nodes can't see.
Use Cases
Enterprise wireless audit: Map all APs in a facility, including ones that aren't where IT thinks they are. Compare discovered BSSIDs against the authorized AP inventory. Any BSSID not on the approved list is a rogue AP worth investigating.
Rogue AP detection: An employee who plugged in a consumer router in a conference room creates an unauthorized AP. It might only be detectable from the nodes nearest that room. The multi-node scan surfaces it even if your command node is on the other side of the building.
Coverage verification: Confirm that the corporate SSID is visible at adequate signal strength throughout the space. Nodes that see the corporate SSID at -80 dBm or weaker indicate coverage gaps where employees might fall back to unauthorized networks.
BSSID spoofing detection: If a rogue AP is broadcasting an SSID that matches the corporate network but with a different BSSID, it will appear as a separate entry in the aggregated results. Per-node RSSI data helps localize where it is physically.
Deauth assessment prep: Before running deauth testing, a distributed scan gives you a complete picture of what's in the space. You can make informed decisions about which APs to test and from which nodes, based on who can actually see the target AP.
Limitations and Accuracy Notes
The multi-node WiFi scan has a few limitations worth being clear about:
32 AP ceiling: The aggregator tracks up to 32 unique APs. In environments with very high AP density (dense urban buildings, large office floors), you may see only a subset of the total APs present. APs beyond the 32-entry limit are dropped.
2.4GHz only: The ESP32-C3 radio only handles 2.4GHz. 5GHz and 6GHz APs are invisible to BLEShark Nano. For a full wireless audit, supplement with 5GHz-capable tools.
Passive scan only: The ESP-IDF WiFi scan is passive (listening for beacons) plus active (sending probe requests). It does not see APs with hidden SSIDs - those appear as entries with empty SSID strings if they respond to broadcast probes, or not at all if they ignore broadcast probes entirely.
RSSI noise: Shiver's multi-node RSSI data shows what each node measured at the time of the scan. WiFi RSSI varies with multipath, interference, and transmit power fluctuations. A single-sample RSSI value has significant measurement uncertainty. Triangulation based on this data gives room-level accuracy, not meter-level precision.
For professional wireless audits, the multi-node BLEShark scan is best used as a rapid triage tool - finding APs that need deeper investigation - rather than a replacement for dedicated enterprise WIDS or spectrum analyzer tools.