Multi-Device Deauth Detection: Monitoring Every Channel at Once

Deauthentication attacks are one of the few wireless attacks that are both effective and detectable. When an attacker sends deauth frames against an AP or client, they're transmitting 802.11 management frames over the air. Anyone listening on the right channel can see them.

The challenge is "the right channel." The 2.4GHz band has 13 channels. A single device can monitor one at a time. If an attacker knows you're monitoring channel 6, they attack on channel 11. If you're cycling through channels, they catch the gap. Real comprehensive deauth detection requires a radio on every channel simultaneously - exactly what a multi-node Shiver deployment provides.

This article covers how multi-device deauth detection works end-to-end: from event detection at a remote node, through the mesh event system, to the alert appearing on the master node.

Table of Contents

• How Single-Node Detection Works
• The Channel Gap Problem
• Multi-Node Coverage
• Event Propagation: From Detection to Alert
• What the Alert Tells You
• Deployment Strategy
• False Positives and Noise
• EU Note

How Single-Node Detection Works

sequenceDiagram
    participant Attacker
    participant Channel as WiFi Channel 7
    participant NodeB as Node B (Ch 5-8)
    participant Mesh as Shiver Mesh (Ch 1)
    participant Master as Master Node

    Attacker->>Channel: Send deauth frames
    Channel->>NodeB: Deauth frame captured
    NodeB->>NodeB: Parse frame metadata
    Note over NodeB: Extract channel, BSSID, timestamp
    NodeB->>NodeB: Queue EVENT_DEAUTH_ALERT
    Note over NodeB: Wait for mesh window (up to 2s)
    NodeB->>Mesh: Switch to channel 1
    NodeB->>Master: Send EVENT_DEAUTH_ALERT
    Master->>Master: ACK received
    Note over Master: If no ACK, retry with backoff
    Master->>Master: Display deauth alert
    Note over Master: Shows: Node B, Channel 7, BSSID

Event propagation sequence - from deauth detection to master node alert display

graph TD
    subgraph "Channel Coverage Layer"
        NA[Node A
Channels 1-4] 
        NB[Node B
Channels 5-8]
        NC[Node C
Channels 9-13]
    end
    subgraph "Shiver Mesh - Channel 1"
        NA ---|ESP-NOW| MASTER[Master Node
Display + Alert]
        NB ---|ESP-NOW| MASTER
        NC ---|ESP-NOW| MASTER
        NA ---|ESP-NOW| NB
        NB ---|ESP-NOW| NC
    end
    subgraph "Detection Flow"
        DEAUTH[Deauth Frame Detected] --> ALERT[EVENT_DEAUTH_ALERT]
        ALERT --> QUEUE[Queue for mesh window]
        QUEUE --> SWITCH[Switch to Channel 1]
        SWITCH --> SEND[Send via ESP-NOW]
        SEND --> MASTER
        MASTER --> DISPLAY[Display: Node + Channel + BSSID]
    end

Multi-node deauth detection architecture - distributed channel monitoring with mesh-based alerting

BLEShark Nano's deauth checker puts the radio into promiscuous receive mode on a target channel and listens for 802.11 management frames with deauth (subtype 0x0C) or disassociation (subtype 0x0A) type indicators. These frames are transmitted unencrypted in 802.11 - even WPA2 and WPA3 networks (without 802.11w PMF) send management frames in the clear.

A legitimate deauth from an AP is normal: the AP sends a deauth to clean up a stale client session. What the checker is looking for is the pattern of attacks: rapid repeated deauth frames, deauth frames with spoofed AP MAC addresses, or deauth floods targeting specific clients.

When the checker detects a deauth event, it displays an alert on the OLED and records the event locally. This works well for a single channel.

The Channel Gap Problem

Single-channel monitoring has a fundamental coverage gap. If you have 15 APs across a corporate floor on channels 1, 6, and 11 (plus several more on adjacent channels), a single deauth checker on channel 6 misses everything happening on channels 1 and 11. An attacker targeting a client on channel 1's AP is invisible to your channel 6 checker.

Channel rotation helps but doesn't solve the problem. If you cycle through all 13 channels with a 100ms dwell time, your full rotation takes 1.3 seconds. A burst deauth attack that lasts 200ms on channel 11 may complete entirely within a gap in your rotation. You miss it.

For networks where any deauth needs to be detected (high-security environments, environments where deauth has been weaponized to disrupt operations, or authorized assessments where the tester wants to verify detection capabilities), channel rotation is not reliable enough. You need continuous coverage per channel.

Multi-Node Coverage

With Shiver's coordinated channel partitioning, multiple nodes each take responsibility for a subset of the 2.4GHz channel spectrum. Each node runs the deauth checker on its assigned channels continuously, rather than rotating through all 13.

A three-node deployment covering the full 2.4GHz band:

• Node A: monitors channels 1-4 continuously
• Node B: monitors channels 5-8 continuously
• Node C: monitors channels 9-13 continuously

With this configuration, every channel is covered continuously. A deauth frame on any channel in the 2.4GHz band will be detected by the responsible node within milliseconds of transmission. No attack on any channel is missed due to timing gaps.

Each node still participates in the Shiver mesh. Mesh communication between nodes runs over ESP-NOW - Espressif's connectionless WiFi protocol. BLE is used only for the initial pairing step; once paired, the radio operates exclusively in ESP-NOW mode. This window gap is short enough that the vast majority of deauth attacks (which involve multiple frames over seconds, not fractions of a second) are detected.

Event Propagation: From Detection to Alert

When a remote node detects a deauth event on its assigned channels, it sends EVENT_DEAUTH_ALERT to the master node via the Shiver mesh. The event delivery uses the mesh's reliable transport - the frame is acknowledged and retried if not acknowledged within the backoff window.

The event path:

1. Node B detects deauth frames on channel 7.
2. Node B constructs EVENT_DEAUTH_ALERT with metadata (detected channel, target BSSID if extractable, timestamp).
3. Node B queues the event for delivery at the next mesh window opening (within 2 seconds).
4. At the next window, Node B switches to channel 1 and sends the event via the mesh to the master node.
5. If the master node is not a direct neighbor of Node B, AODV routing forwards the event through intermediate nodes.
6. The master node receives the event and displays a deauth alert, indicating which node detected it and on which channel.

Total time from detection to alert display: typically 2-4 seconds (dominated by waiting for the next mesh window). For security monitoring purposes, near-real-time is sufficient. You don't need sub-second alerting to respond appropriately to a deauth attack.

What the Alert Tells You

The deauth alert from a remote node includes:

• Which node detected it (identified by node name or eFuse prefix)
• The physical location of that node (if you labeled nodes by location during deployment)
• Which channel the deauth was detected on

This information is actionable. If Node B (deployed in the east wing of the second floor) detected a deauth on channel 7, the source of the attack is in or near the east wing of the second floor. The attacker has to be within radio range of Node B to produce a detectable signal there.

If the same event is also detected by Node A (west wing) at the same time, the attacker is either centrally located or using a high-power transmitter. If only Node B detects it, the attacker is localized to Node B's vicinity.

Per-node detection gives you spatial context that single-device monitoring can't provide.

Deployment Strategy

For comprehensive deauth monitoring, deployment goals:

Coverage density: Each node needs to be within radio range of the APs and clients it's monitoring. For channel coverage purposes, "radio range" means being in the same area as the target network. ESP-NOW Long Range mode extends Shiver node range, but the target 2.4GHz traffic being monitored follows standard WiFi range - roughly 30-50 meters in typical indoor environments.

Physical distribution: Nodes spread across the monitored area ensure that an attack in any part of the building is within detection range of at least one node. Clustering nodes in one area leaves other areas unmonitored regardless of channel assignment.

Channel assignment strategy: If you know which channels your corporate APs use, assign monitoring nodes to cover those channels plus adjacent channels. If you don't have prior channel information, even distribution across all 13 channels ensures nothing is missed.

Minimum viable setup for full-spectrum coverage of a single floor: 3 nodes, one per primary 2.4GHz channel partition, deployed at roughly equal spacing across the floor. This gives both complete channel coverage and reasonable spatial coverage of a typical commercial floor plate.

For large enterprise environments with multiple floors or wings: more nodes, deployed with both channel and physical coverage in mind. The 16-node Shiver maximum supports comprehensive coverage of substantial facilities.

False Positives and Noise

Not all deauth frames indicate an attack. Normal 802.11 network operation includes legitimate deauthentications:

• APs send deauth to clients that haven't sent traffic for a while (idle timeout)
• Clients send deauth when they intentionally disconnect
• Roaming: a client moves from one AP to another and the original AP sends deauth
• Driver bugs in some clients cause spurious deauth transmissions

The deauth checker distinguishes attacks from normal operation by looking at rate and pattern. A single deauth frame once every few minutes is normal operation. Dozens of deauth frames in a second, or deauth frames spoofing an AP's BSSID, indicate an attack.

In high-density environments (office buildings with many APs, public spaces), the rate of legitimate deauth frames can be high enough to generate false alerts if the detection threshold is too sensitive. Tuning the detection threshold for the specific environment reduces false positive rate.

Nodes deployed near other corporate WiFi networks (neighboring tenant spaces in shared buildings) may also detect deauth frames from those networks. Filtering by BSSID prefix (if your corporate network uses a consistent OUI for all APs) focuses monitoring on your own infrastructure.

EU Note

BLEShark Nano's deauth detection (passive listening for deauth frames) operates normally on EU firmware builds. Deauth transmission is disabled on EU builds per the Radio Equipment Directive. Multi-node deauth detection and EVENT_DEAUTH_ALERT propagation across the Shiver mesh are fully available in EU builds.

The Bottom Line

A single BLEShark Nano can detect deauth attacks on the channel it's monitoring. A Shiver mesh with coordinated channel partitioning can detect deauth attacks on all 2.4GHz channels simultaneously, from every area of a building, with alerts delivered to a single monitoring point in near-real-time.

For organizations that have experienced wireless disruption, or for red teams assessing whether an organization's detection capabilities are adequate, this is the practical implementation of comprehensive wireless threat monitoring at a price point that makes sense outside enterprise-grade deployments.

Get BLEShark Nano