Coordinated Channel Partitioning: Full 2.4GHz Coverage Across Shiver Nodes
A single WiFi device can only monitor one channel at a time. The 2.4GHz band has 13 channels (11 in North America, 13 in Europe). If you're monitoring channel 6, you can't simultaneously see traffic on channels 1 or 11. Switch channels, and you miss what was happening on the channel you just left.
This limitation is fundamental: the radio hardware is a single receiver. It can be tuned to one frequency at a time. To monitor multiple channels simultaneously, you need multiple radios.
That's what Shiver's coordinated channel partitioning does. Rather than having every node in the mesh monitor the same channel, the system can assign different channels to different nodes. Each node monitors its assigned channels while the mesh communication continues on the dedicated mesh channel (channel 1). The result is simultaneous coverage across the entire 2.4GHz band.
Table of Contents
- The Single-Channel Problem
- How Partitioning Works
- Mesh Channel vs Task Channel
- Deauth Detection Application
- Authorized Deauth Testing Application
- Channel Assignment
- Availability
- EU Note
The Single-Channel Problem
To understand why channel partitioning matters, consider what happens when you run the deauth checker on a single BLEShark Nano. The device listens for deauthentication frames - 802.11 management frames with subtype 0x0C. When it sees one, it alerts you.
stateDiagram-v2
[*] --> MeshMode: Node boots
MeshMode --> TaskMode: Scan/detect command received
TaskMode --> MeshMode: Task complete or report needed
MeshMode --> TaskMode: Next channel assignment
state MeshMode {
[*] --> Channel1
Channel1: ESP-NOW on Channel 1
Channel1 --> Listening: Wait for commands
Listening --> Forwarding: Relay mesh traffic
Forwarding --> Listening
}
state TaskMode {
[*] --> SwitchChannel
SwitchChannel: Hop to assigned task channel
SwitchChannel --> Scanning: Monitor for frames
Scanning --> Detected: Deauth/beacon captured
Detected --> ReturnMesh: Send alert via mesh
}
Node state transitions between mesh communication mode and task monitoring mode
graph TD
subgraph "Mesh Layer - Channel 1 (Always)"
MASTER[Master Node
Channel 1] ---|ESP-NOW| NODE2[Node 2]
MASTER ---|ESP-NOW| NODE3[Node 3]
MASTER ---|ESP-NOW| NODE4[Node 4]
NODE2 ---|ESP-NOW| NODE3
end
subgraph "Task Layer - Partitioned Channels"
NODE2 -->|Monitors| CH1_6["Channels 1-6"]
NODE3 -->|Monitors| CH7_11["Channels 7-11"]
NODE4 -->|Monitors| CH12_14["Channels 12-14"]
end
subgraph "2.4GHz Coverage Result"
CH1_6 --> FULL[Full 2.4GHz Band Covered]
CH7_11 --> FULL
CH12_14 --> FULL
end
style FULL fill:#1f1f1f,stroke:#5b5b5b,color:#fff
Channel partitioning across Shiver mesh nodes - mesh stays on channel 1 while task channels are distributed
But it can only listen on one channel at a time. Most deauth attacks are targeted at a specific AP on a specific channel. If the attack is on channel 11 and your checker is on channel 6, you miss it entirely.
A single-device scan rotates through channels sequentially - a brief dwell time on each channel before moving to the next. This is how passive wireless scanners typically work: they cycle through the channel list and capture whatever they happen to catch in each dwell window. Channel rotation works for discovering APs (which transmit beacon frames periodically at predictable intervals). It works poorly for detecting attacks, which happen at unpredictable moments and may last only a fraction of a second.
If you need continuous, comprehensive deauth monitoring across all 2.4GHz channels, you need a radio on every channel at once.
How Partitioning Works
Shiver's coordinated channel partitioning is a planned feature arriving in v1.0.0. The mechanism works by assigning each participating node a channel partition - a subset of the 2.4GHz channel spectrum that this node is responsible for monitoring.
Example partition assignment for a 3-node setup:
- Node A: channels 1-4
- Node B: channels 5-8
- Node C: channels 9-13
Each node configures its radio to monitor (or cycle through, at short dwell times) only its assigned channel range. Because each node covers a fraction of the full spectrum, it can dwell longer per channel and catch shorter events. Node B only needs to cover 4 channels instead of 13, so it can spend 3 times as long on each one.
The partition assignment is sent from the command node to each target node via CMD (via the Shiver mesh, which runs on the dedicated mesh channel 1). Once each node acknowledges its channel assignment, they all begin monitoring their respective partitions simultaneously.
Mesh Channel vs Task Channel
This is the key point that makes channel partitioning possible: the Shiver mesh always communicates on channel 1, and this is separate from what channel a node is monitoring for security tasks.
When a node switches to its assigned task channels (channels 5-8 for Node B), it uses Shiver's preemptible task system. Every 2 seconds, during the mesh window (500ms), the node switches back to channel 1, handles any pending mesh communication (acknowledges commands, forwards data, maintains keepalives), then returns to its task channel.
This means Node B can be "watching channel 7 for deauth frames" while still being a functional Shiver mesh member. The mesh windows are short enough (500ms every 2 seconds) that the interruption to task monitoring is minimal. Most security events of interest last long enough (a deauth attack produces many frames, not just one) to be detected even with the brief channel-switch gaps.
The practical effect: Node B is monitoring channels 5-8 for security events, and mesh traffic flows normally on channel 1. The two operations coexist without interfering with each other.
Deauth Detection Application
The primary use case for channel partitioning is comprehensive deauth detection. With 3 nodes covering the full 2.4GHz spectrum, every deauth frame sent on any channel in the building is seen by one of the nodes within its dwell period.
When a node detects a deauth frame on its assigned channels, it sends EVENT_DEAUTH_ALERT back to the master node via the Shiver mesh. The alert includes which channel the deauth was detected on, which BSSID was targeted, and the node's identity (so you know where in the building the detection originated).
The master node receives alerts from all monitoring nodes and displays a unified view. A deauth attack on channel 11 shows up on your screen within a few mesh window cycles of occurrence, even though your display device might be on the other side of the building and nowhere near channel 11.
This is a meaningful improvement over single-channel deauth detection for enterprise environments. Organizations with dozens of APs spread across multiple channels have significant blind spots with single-device monitoring. Partitioned multi-node detection eliminates those blind spots.
Authorized Deauth Testing Application
The inverse of detection: if you're running authorized deauth testing and want to test whether a corporate network's APs are vulnerable on all channels, coordinated channel partitioning lets you assign each node to test a different channel range simultaneously.
Rather than running a sequential test (test channel 1, wait, test channel 6, wait, test channel 11, wait), you test all channels simultaneously from a single operation. The results from all nodes flow back to the command node via EVENT aggregation.
This is relevant for authorized testing because deauth attacks are time-sensitive in assessments. You want to know if APs are using 802.11w Protected Management Frames (PMF) and whether they're susceptible to deauth. A comprehensive test that covers all channels gives you the complete picture in one operation window rather than requiring separate tests per channel.
EU users: deauth features are disabled on EU firmware builds per Radio Equipment Directive requirements. Deauth detection (listening only) remains available. Deauth transmission is EU-restricted.
Channel Assignment
The channel assignment UI is part of the Execute menu flow in Shiver. When you select a channel-partitioned operation, the device prompts for partition configuration:
- How many nodes to assign (the system can show you which nodes are online)
- Automatic partition: the system divides the channel range evenly across selected nodes
- Manual partition: you specify which channels each node monitors
Manual partition makes sense when you have prior knowledge of the environment. If you know the corporate network uses channels 1, 6, and 11 (the standard non-overlapping channels), you can assign one node per primary channel and let the third node cover adjacent channels to catch adjacent-channel devices.
Automatic partition is the quick-start option for environments where you don't have prior knowledge. Even distribution across all 13 channels gives a baseline coverage map.
Availability
Coordinated channel partitioning is arriving in BLEShark Nano firmware v1.0.0. The underlying Shiver mesh infrastructure (command delivery, event aggregation, preemptible task system) that enables it is already implemented - channel partitioning is the application layer built on top of that infrastructure.
If you're planning a deployment that relies on comprehensive 2.4GHz coverage for detection or testing purposes, this is the feature that makes it practical without requiring dedicated enterprise WIDS hardware.
EU Note
BLEShark Nano's deauth transmission features are disabled in EU firmware builds to comply with the Radio Equipment Directive (RED). Coordinated channel partitioning for deauth detection (passive listening) operates normally in EU builds. Deauth testing (transmission) is restricted to non-EU firmware. All other channel partitioning uses (general scanning, AP detection, coverage mapping) are available in EU builds.