You can capture raw Wi-Fi frames, not just IP packets, using tcpdump in monitor mode.
Here’s what it looks like when you’re actually doing it:
sudo tcpdump -i wlan0mon -s 0 -w wifi_capture.pcap
This command binds tcpdump to the wlan0mon interface, which is your wireless card in monitor mode. -s 0 tells it to capture full packets, and -w wifi_capture.pcap saves the output to a file.
Let’s say you’re troubleshooting a Wi-Fi connection issue. You suspect a client device isn’t properly associating with an access point (AP). You’ve tried the usual – rebooting the AP, checking the client’s Wi-Fi settings – but the problem persists. You need to see the actual handshake between the client and the AP, not just the IP traffic that happens after they’ve connected.
With tcpdump in monitor mode, you can capture and analyze the underlying 802.11 management and control frames. These are the packets that establish and maintain the wireless connection itself. You’ll see things like:
- Beacon frames: Sent by APs to advertise their presence and capabilities.
- Probe requests/responses: How clients search for APs and how APs respond.
- Authentication requests/responses: The initial step in connecting to an AP.
- Association requests/responses: The final step in joining a network, where capabilities are exchanged and an association ID is assigned.
- Deauthentication/disassociation frames: Used to terminate a connection.
- RTS/CTS (Request to Send/Clear to Send): Flow control mechanisms to manage channel access and prevent collisions.
- ACK (Acknowledgement): Confirms successful reception of data frames.
This allows you to diagnose issues at a much deeper level. For instance, if a client is sending probe requests but never receiving probe responses, you know the AP isn’t "seeing" the client, or there’s a significant RF issue. If you see association requests but no successful association response, the AP might be rejecting the client for some reason (e.g., MAC filtering, incorrect security settings).
To use monitor mode, your wireless card and driver must support it. On Linux, you typically need to:
- Identify your wireless interface:
iw dev - Bring down the interface:
sudo ip link set wlan0 down(replacewlan0with your actual interface name) - Enable monitor mode:
sudo iw dev wlan0 set type monitor - Bring the interface back up:
sudo ip link set wlan0 up - Rename the interface (optional but recommended for clarity):
sudo ip link set wlan0 name wlan0mon
Once in monitor mode, tcpdump can capture all the raw 802.11 frames that pass through the airwaves within range, regardless of whether they are intended for your specific machine or network.
The key is that tcpdump in monitor mode doesn’t just filter by IP address or port. It sees everything. You’re essentially turning your laptop into a passive Wi-Fi sniffer. You can then open the .pcap file in a tool like Wireshark, which is excellent at dissecting and visualizing these 802.11 frames, making it much easier to follow the connection state transitions.
When you’re analyzing a capture, you’ll often filter by frame type. For example, to see only association requests from a specific client MAC address, you might use Wireshark’s display filter: wlan.fc.type_subtype == 0x0000 && wlan.sa == AA:BB:CC:DD:EE:FF. Here, 0x0000 is the subtype for Association Request, and wlan.sa is the source address of the client.
This capability is invaluable for debugging sticky client issues, understanding why devices are failing to connect, or even analyzing network performance by looking at retransmission rates and channel busy times indicated by different frame types.
The most surprising thing is that even when tcpdump is running, it’s not actively participating in the network conversation. It’s just listening to the airwaves, receiving every frame that hits its antenna, and the operating system’s wireless driver is responsible for passing those raw frames up to tcpdump without any filtering based on network destination.
After you’ve successfully captured and analyzed Wi-Fi management frames, the next logical step is to dive into the data frames themselves, looking for issues like TCP retransmissions or UDP packet loss.