What Is Monitor Mode? How WiFi Packet Capture Actually Works
Most WiFi adapters work like a selective filter: they receive every frame that arrives at the antenna, then discard anything not addressed to them. Packets for other devices get dropped before the OS ever sees them. This is how managed mode works - it's efficient, it's what you want for normal network usage, and it means you can't eavesdrop on your neighbor's traffic even though their packets are physically hitting your antenna.
Monitor mode turns off that filter. The adapter passes every received frame up to the driver, regardless of destination address. You see beacon frames, probe requests, management frames from other networks, data frames from other associations, all of it. It's the foundation of passive WiFi analysis - and it's what enables tools like airodump-ng, Wireshark wireless capture, and the passive sensing features of the BLEShark Nano.
Managed Mode vs. Monitor Mode
Understanding the difference requires knowing how a WiFi adapter normally operates.
In managed mode (also called infrastructure mode), the adapter:
- Associates with a specific access point
- Has a negotiated channel and security context
- Accepts frames addressed to its MAC address or the broadcast address
- Discards everything else at the hardware or driver level
- Participates in the power-save protocol with the AP
In monitor mode (also called RFMON on Linux, or promiscuous mode in some contexts):
- The adapter is not associated with any AP
- Every received frame is passed to the OS regardless of destination
- The adapter is locked to a specific channel (or hops, depending on configuration)
- Received frames include the radiotap header (metadata about reception: signal strength, data rate, channel, timestamp)
- The adapter can optionally inject frames (raw transmit capability)
Why Most Adapters Don't Support Monitor Mode
Monitor mode is a driver feature, not purely a hardware feature. The physical radio hardware in almost every WiFi chip can receive all frames - the filtering happens in the driver. Whether monitor mode is available depends on whether the driver exposes the capability to the OS.
Consumer adapters ship with drivers optimized for managed mode performance. The manufacturers have no commercial incentive to support monitor mode. It's not a feature end users ask for when buying a laptop or USB WiFi dongle. Supporting it requires extra engineering, testing, and maintenance. Most vendors don't bother.
Chipsets that do support monitor mode on Linux have become well-known in the security community for this reason: Atheros (ath9k, ath10k), Ralink/Mediatek (rt2800), and certain Realtek chips (rtl8812au variants) are the standard recommendations for wireless security research. Alfa adapters in particular sell on this reputation - the AWUS036ACH and similar models explicitly advertise monitor mode support as a feature.
On macOS, the built-in airport utility exposes limited capture capability. On Windows, monitor mode support is effectively non-existent in stock drivers for most consumer chips. Linux is the practical platform for wireless packet capture work.
What You Can See in Monitor Mode
With a monitor mode capture running on a given channel, you see every 802.11 frame transmitted on that channel within radio range:
graph TD
subgraph "802.11 Frame Types Visible in Monitor Mode"
subgraph "Management Frames"
BEACON["Beacon
AP advertisements"]
PROBE_REQ["Probe Request
Client searching"]
PROBE_RSP["Probe Response
AP replies"]
AUTH["Authentication
Open/SAE"]
ASSOC["Association
Request/Response"]
DEAUTH["Deauthentication
Disconnect frames"]
DISASSOC["Disassociation
Graceful disconnect"]
end
subgraph "Control Frames"
RTS["RTS
Request to Send"]
CTS["CTS
Clear to Send"]
ACK["ACK
Acknowledgment"]
BLKACK["Block ACK
Batch acknowledgment"]
end
subgraph "Data Frames"
DATA["Data (encrypted)
Payload not readable
without key"]
EAPOL["EAPOL
4-way handshake
(capturable!)"]
NULL["Null Data
Power management"]
QOS["QoS Data
Priority traffic"]
end
end
subgraph "Metadata Always Visible"
META["Source/Dest MAC addresses
BSSID
Signal strength (RSSI)
Channel and frequency
Data rate
Frame sequence numbers"]
end
BEACON --> META
DATA --> META
RTS --> META
Monitor mode reveals all three 802.11 frame categories - while data payloads remain encrypted, management frames, control frames, and frame metadata are always visible.
Management frames:
- Beacon frames from all APs broadcasting on the channel
- Probe requests from devices scanning for networks
- Probe responses from APs answering those probes
- Authentication frames (the open system auth exchange before association)
- Association requests and responses
- Deauthentication and disassociation frames
Data frames:
- Encrypted data frames (you see the ciphertext, not plaintext, for WPA2/WPA3 networks)
- Unencrypted data on open networks (full plaintext)
- EAPOL frames - the WPA2 4-way handshake frames that authentication uses
Control frames:
- ACK frames
- RTS/CTS frames
- Block ACK requests and responses
The EAPOL frames are the critical piece for handshake capture. During the WPA2 4-way handshake, both the AP and the client transmit EAPOL key frames. A device in monitor mode on the correct channel captures all four of these frames. That capture contains everything needed for offline password cracking - which is the primary use case of tools like airodump-ng combined with a deauthentication trigger.
graph TD
subgraph "Managed Mode (Normal)"
AIR1["802.11 Frames
on Channel"]
NIC1["WiFi NIC
(Managed)"]
FILTER1["Hardware Filter:
Only frames to MY MAC
or broadcast"]
OS1["OS Network Stack
Sees: IP packets only"]
APP1["Applications
(Browser, etc.)"]
AIR1 --> NIC1 --> FILTER1 --> OS1 --> APP1
end
subgraph "Monitor Mode (Promiscuous)"
AIR2["ALL 802.11 Frames
on Channel"]
NIC2["WiFi NIC
(Monitor)"]
FILTER2["No Filter:
All frames passed
Management + Control + Data"]
RADIO["Radiotap Header Added
Signal strength, channel,
data rate, noise"]
CAP["Capture Tool
(Wireshark, tcpdump,
BLEShark Nano)"]
PCAP["PCAP File
Raw 802.11 frames"]
AIR2 --> NIC2 --> FILTER2 --> RADIO --> CAP --> PCAP
end
Managed mode vs monitor mode - in managed mode the NIC filters frames to its own MAC address, while monitor mode captures all 802.11 traffic including management frames from other devices.
What Monitor Mode Cannot See
Monitor mode is not magic. There are real limits:
Encryption: WPA2 and WPA3 data frames are encrypted. You see the ciphertext. Without the PTK (pairwise transient key) for that session, you cannot read the data. For WPA2, cracking the pre-shared key offline (via handshake capture) gives you a way to derive the PTK, but WPA3 with forward secrecy means each session key is unique and a cracked password doesn't retroactively decrypt captured traffic.
5GHz and 6GHz: If the adapter only supports 2.4GHz, you're invisible to everything on 5GHz. This is a significant blind spot in modern environments where most devices prefer 5GHz. The ESP32-C3 is a 2.4GHz-only chip - it cannot see 5GHz traffic at all.
Out-of-range traffic: Radio doesn't penetrate walls and distance indefinitely. Frames from the other end of a building may be too weak to receive. The antenna gain and receiver sensitivity of the capture adapter matters.
Channel limitations: You're on one channel at a time (unless doing channel hopping). Traffic on other channels is invisible while you're not tuned to them.
How the ESP32 Handles Raw 802.11 Frames
The ESP32 doesn't implement monitor mode in the traditional Linux driver sense, but it achieves the same outcome through a different mechanism: a promiscuous callback.
Espressif's WiFi library provides esp_wifi_set_promiscuous(true), which enables a frame callback. When promiscuous mode is active, every received frame is passed to the registered callback function. The callback receives a pointer to the raw frame data and a metadata structure with signal strength and other reception info.
This is functionally equivalent to monitor mode: you see every frame on the current channel, regardless of destination address. The callback can inspect beacon frames, probe requests, management frames, and data frames (encrypted or not).
The BLEShark firmware uses this to implement:
- WiFi scanning: Parsing beacon frames and probe responses to build the AP list
- Deauth detection: Watching for deauthentication frame subtypes
- Handshake capture: Filtering for EAPOL frames and saving them to PCAP format (in firmware versions that support this)
For handshake capture, the BLEShark saves the captured EAPOL frames as a .pcap file, which can be downloaded via the file portal and opened in Wireshark or fed directly to hashcat/hcxtools for offline analysis. The capture is passive - the BLEShark doesn't need to send anything to capture a handshake if it observes a natural connection event. For faster capture, it can combine deauth (to force a reconnection) with promiscuous capture.
EU note: In EU firmware, deauth transmission is disabled to comply with RED regulations. Handshake capture in EU mode is passive-listen only - the BLEShark waits for a natural 4-way handshake without triggering one. This still works, it just takes longer if no clients are actively connecting.
The Radiotap Header
When capture tools like Wireshark receive monitor mode frames, each frame is prepended with a radiotap header - a variable-length metadata structure added by the driver. This is not part of the 802.11 frame itself; it's tool-level metadata added by the capture layer.
The radiotap header contains:
- RSSI (signal strength): in dBm. Negative values, closer to 0 is stronger. -40 dBm is strong, -80 dBm is weak, -90 dBm is near the noise floor.
- Data rate: what rate this frame was received at (e.g., 1 Mbps, 6 Mbps, 54 Mbps)
- Channel: the frequency the frame was received on
- Timestamp: when the frame was received
- Flags: whether FCS was correct, whether the frame was received on a short preamble, etc.
This metadata is valuable for analysis. RSSI tells you how close a device is (roughly). The data rate tells you whether the transmitter was far away (low rates are used for poor-signal conditions) or close (high rates). Timestamps let you reconstruct the sequence of events in a capture.
Channel Hopping During Capture
Because a single-radio device can only monitor one channel at a time, many capture tools implement channel hopping: the adapter quickly cycles through channels, spending a dwell time on each before moving on.
sequenceDiagram
participant FW as BLEShark Firmware
participant RADIO as ESP32 WiFi Radio
participant CH1 as Channel 1
(2412 MHz)
participant CH6 as Channel 6
(2437 MHz)
participant CH11 as Channel 11
(2462 MHz)
Note over FW,CH11: Channel Hopping Scan
FW->>RADIO: Set channel 1
RADIO->>CH1: Listen (promiscuous)
CH1->>RADIO: Beacon from AP-A
CH1->>RADIO: Probe req from STA-1
CH1->>RADIO: Data frame (encrypted)
Note over RADIO: Dwell time: 100-200ms
FW->>RADIO: Set channel 6
RADIO->>CH6: Listen (promiscuous)
CH6->>RADIO: Beacon from AP-B
CH6->>RADIO: Deauth frame detected!
CH6->>RADIO: Handshake frame 1/4
Note over RADIO: Dwell time: 100-200ms
FW->>RADIO: Set channel 11
RADIO->>CH11: Listen (promiscuous)
CH11->>RADIO: Beacon from AP-C
CH11->>RADIO: Association request
Note over FW: Cycle repeats
Full 2.4GHz sweep ~1.5s
FW->>RADIO: Back to channel 1
Channel hopping during WiFi capture - the radio dwells on each channel briefly to collect frames, cycling through all 2.4GHz channels to build a complete picture of nearby wireless activity.
airodump-ng does this by default, cycling through all 2.4GHz and 5GHz channels every few seconds. The trade-off: you see a sampling of traffic on each channel rather than a complete capture on any single channel. For finding APs and probing activity, channel hopping is fine. For capturing a complete 4-way handshake, you need to lock to the channel the target AP operates on, because the handshake frames happen quickly and you can't afford to miss them while you're on another channel.
The BLEShark's WiFi scan mode hops channels for discovery. Its deauth checker and handshake capture modes lock to a specific channel where the target AP is operating.
Practical Uses of Monitor Mode Capture
Beyond the security research context, monitor mode capture has legitimate uses:
Network troubleshooting: Seeing the full 802.11 frame exchange helps diagnose association failures, authentication problems, and roaming issues that are invisible in normal network monitoring.
Interference analysis: Seeing all management frames on a channel helps identify sources of congestion - too many APs on the same channel, excessive beacon overhead, rogue devices.
Client behavior analysis: Which devices are sending probe requests, how often, what networks they're looking for. Useful for IT security teams wanting to understand what's happening on their RF environment.
Protocol research: Learning 802.11 from first principles is much more effective when you can capture and read actual frames. Wireshark's 802.11 dissector annotates every field - following the IEEE spec alongside a real capture is how security researchers develop protocol-level understanding.
Using Wireshark With Monitor Mode
Wireshark is the standard tool for analyzing packet captures, including 802.11 captures. On Linux, put your adapter into monitor mode with iw dev wlan0 set type monitor (or use airmon-ng which handles this automatically), then start a Wireshark capture on the monitor interface.
For .pcap files captured on a BLEShark Nano, download them via the file portal and open them in Wireshark. The EAPOL frames will appear, and you can apply the display filter eapol to isolate the handshake frames. From there, the captured file can be converted to hashcat format with hcxtools for offline cracking tests.
For authorized wireless audits, this workflow - BLEShark capture, download via file portal, Wireshark analysis, hashcat cracking attempt - is a practical end-to-end test of your network's WPA2 password strength.
BLEShark Nano and Promiscuous Capture
The BLEShark Nano's promiscuous mode gives you most of what monitor mode on a traditional adapter provides, with the constraint that you're working in 2.4GHz only. For home and small office environments where many devices are still on 2.4GHz, this covers the majority of the attack surface.
For enterprise environments or modern home networks where everything has migrated to 5GHz, you'll want a dedicated 5GHz monitor mode adapter alongside the BLEShark for complete coverage. The two tools complement each other - BLEShark handles BLE scanning, deauth detection, IR, and 2.4GHz WiFi testing, while a traditional adapter handles 5GHz packet capture.
With the Shiver mesh system, multiple BLEShark Nanos can monitor different 2.4GHz channels simultaneously, removing the channel-switching trade-off for 2.4GHz coverage. Each node reports its deauth detections and frame events to the master device over ESP-NOW mesh.
Packet capture and monitor mode should only be used on networks and in environments where you have explicit authorization. Capturing traffic from networks you do not own or have permission to test may violate computer fraud and wiretapping laws in your jurisdiction.