dispelledMonitor Mode and 802.11 Captures
Monitor mode lets a compatible Wi-Fi adapter deliver observed 802.11 frames to the local system rather than behaving as a normal associated station. It is valuable for understanding and defending a wireless network, but it is not a permission to observe other people’s traffic. Use it only in an isolated lab with radios, an access point, and client devices you own or have explicit written authorization to test.
Managed mode and monitor mode solve different problems
A managed interface associates to an access point, negotiates security, and sends and receives traffic as a station. A monitor interface listens on one selected channel and exposes raw 802.11 metadata and frames to capture software. It does not join the network, obtain an IP address, or decrypt protected payloads merely because it can see transmissions.
Verify capability before changing anything
Not every adapter and driver supports monitor mode, and virtual machines often need a compatible USB adapter passed through to the guest. Inspect the radio’s advertised interface modes; a listed mode is necessary, but stable capture behavior also depends on driver and firmware quality.
# Inventory the adapter; do not assume its interface or PHY name
iw dev
iw phy phyLAB info
# In the "Supported interface modes" section, look for:
# * monitor
#
# Confirm the lab adapter is not carrying the machine's active connection
nmcli device status
iw dev labmon0 infoThe placeholder phyLAB means the PHY actually shown for labmon0 by iw dev. If the adapter is the only route to a remote machine, changing its mode can end that session. Use a local console or a second adapter for the lab.
Prepare an isolated capture
Choose a channel configured on your own lab access point, then keep both the test client and capture adapter on that channel. A monitor radio generally observes one channel at a time; it cannot provide a complete picture of a channel-hopping environment.
# Example lab variables: replace channel 36 only with your authorized lab channel
LAB_MON_IF=labmon0
LAB_CHANNEL=36
# Check the adapter is currently unused, then set its monitor mode and lab channel
ip link show "$LAB_MON_IF"
sudo ip link set "$LAB_MON_IF" down
sudo iw dev "$LAB_MON_IF" set type monitor
sudo ip link set "$LAB_MON_IF" up
sudo iw dev "$LAB_MON_IF" set channel "$LAB_CHANNEL"
# Verify mode and frequency; stop and correct the lab setup if they are unexpected
iw dev "$LAB_MON_IF" infoThese commands are intentionally limited to a named lab adapter. They do not disconnect clients, inject frames, attempt authentication, or interact with any network beyond setting the local adapter’s operating mode. If the driver rejects a change, return it to managed mode and consult its documentation rather than forcing a workaround.
Capture only the lab traffic you need
A capture filter reduces what the capture program writes while recording. A display filter is applied later to an already captured packet list. The former limits collection; the latter changes only the view. Prefer a narrow capture scope and short, planned capture windows.
# On the isolated lab only: record 60 seconds from the named monitor adapter.
# The file may contain sensitive metadata; store it in the lab's protected location.
sudo timeout 60 tcpdump -i "$LAB_MON_IF" -I -w lab-80211.pcapng
# Review offline rather than continuing to collect.
# In Wireshark, use display filters to focus on a frame class:
# wlan.fc.type == 0 management frames
# wlan.fc.type == 1 control frames
# wlan.fc.type == 2 data framesExact capture-filter syntax depends on the tool and link type, so validate it against the tool’s documentation before relying on it. Never treat a display filter as a privacy control: packets excluded from the display still exist in the file.
What the frame classes reveal
| Frame class | Useful authorized-lab observation | Defensive question |
|---|---|---|
| Management | Beacon timing, advertised capabilities, association attempts, and roaming events | Does the access point advertise the intended SSID, channel, and modern security configuration? |
| Control | Link coordination such as acknowledgements and request/clear-to-send exchanges | Do retries or contention suggest congestion, weak coverage, or a channel-plan problem? |
| Data | Traffic direction, frame sizes, retry indicators, and protection flags | Are protected payloads expected, and do loss or retry patterns match client complaints? |
Headers can reveal operational metadata even when payloads are protected. Treat capture files as sensitive. WPA2/WPA3 encryption is designed to protect data content from passive observation; seeing a protected frame is not the same as reading it. This lab does not cover recovering credentials, defeating encryption, injection, deauthentication, or bypassing access controls.
Turn observations into defensive improvements
- Compare the lab access point’s configured channel and security policy with its beacon advertisements.
- Measure retries across a controlled client location change before altering transmit power or channel plans.
- Keep guest, IoT, and administrative devices on intentionally separated networks, with current firmware and strong unique administrative credentials.
- Record capture time, channel, adapter/driver version, lab topology, and test action so another administrator can reproduce the result.
Clean up and restore the adapter
# Stop capture first, retain only the authorized lab file, then restore normal use
sudo ip link set "$LAB_MON_IF" down
sudo iw dev "$LAB_MON_IF" set type managed
sudo ip link set "$LAB_MON_IF" up
# If NetworkManager manages this adapter, let it resume normal policy
nmcli device status
iw dev "$LAB_MON_IF" infoSome drivers require deleting and recreating a monitor interface instead of changing its type. In that case, follow the driver’s documented interface lifecycle and verify that no experimental interface remains. For everyday inventory, radio blocks, connection profiles, and recovery, see Linux Wireless Interfaces with iw and nmcli.