Wi-Fi Packet Capture Fundamentals
Every Wi-Fi problem leaves a trace on the air. Taking the capture is half the battle; the other half is reading it without getting lost in tens of thousands of frames. This page covers how to capture 802.11 traffic correctly on every platform, where to place the capture, and how to start analysis. Capture first, then the protocol does the rest.
— Shankar K. · Sources: IEEE 802.11-2020 monitor-mode behaviour, kernel.org iw docs, Apple Wireless Diagnostics · Wireshark: wlan.fc.type_subtype
A packet capture (PCAP) is a recording of the actual 802.11 frames in the air: beacons, probes, authentication, association, the 4-way handshake, data, and the management frames that explain why a client left. Your everyday laptop, while connected to Wi-Fi, cannot record this. It is in managed mode and only hears frames addressed to it. To capture everything on a channel you need monitor mode. That single distinction is the foundation of everything below.
The default. Your radio is associated to an AP and the driver hands up only the frames destined for your MAC plus broadcast and multicast. Decrypted data, yes, but you cannot see other clients, most management frames, or the retries and control frames that explain a problem. Useless for protocol troubleshooting.
The radio stops associating and passes up every 802.11 frame it can demodulate on the tuned channel, from any device, wrapped in a radiotap header carrying RSSI, MCS, and channel. This is what a PCAP needs. The whole game is getting your adapter into monitor mode and onto the right channel.
One consequence worth internalising early: over-the-air data frames are encrypted (WPA2/WPA3). A monitor capture sees that they exist and how they behave, but not their contents unless you also hold the key material. For most connectivity and roaming work, the management and control frames are what you need, and those are in the clear.
Your capture radio must reach the band you care about (2.4, 5, or 6 GHz) and must support the generation you are capturing. To capture a Wi-Fi 7 (802.11be) exchange you need a Wi-Fi 7 capture radio, or you will miss EHT fields and 320 MHz detail. With Multi-Link Operation you also cannot be sure which link a client will use to start, so single-radio captures can miss the opening frames of an MLO session.
One radio captures one channel at a time. That is fine for a stationary client on a known channel. Roaming analysis is different: the client moves across APs on different channels, so you must capture several channels at once, which means several radios, one locked per channel. A single adapter can only time-slice across channels and will drop frames while it is tuned elsewhere, so it is not a substitute for simultaneous multi-channel capture.
For connectivity, authentication, and roaming problems, management and control frames carry the story, and they are unencrypted. Capture data frames when the issue is throughput, fragmentation, or anything past association into the IP path. Knowing what you are after narrows the channel, the placement, and how long you record.
A capture taken next to the client and one taken at the AP are two different viewpoints, and they often disagree. If you want to know what the client experienced, put the sniffer beside the client and, for roaming, move with it. Remember the wired side too: an 802.1X failure may be the RADIUS server or an upstream load balancer, not the air, so a parallel capture behind the AP is sometimes the only way to localise the fault.
Pick your machine and what you are trying to do. The recommendation below updates with the method and the first commands or steps to run.
The built-in adapter supports native monitor mode, which is why many wireless engineers keep a Mac for captures. The cleanest path is AirTool2 or the Sniffer inside Apple's Wireless Diagnostics; both put the radio into monitor mode and write a PCAP. The old airport command-line tool is deprecated, so do not rely on it. Native capture is single-channel; for multi-channel you add an external sensor (see remote capture). One current caveat for Wi-Fi 7 hardware: on the newest Apple N1 Wi-Fi 7 card the standard tcpdump -I and Wireshark monitor path can fail to enter monitor mode, and the Wireless Diagnostics Sniffer is the reliable route there. The newest silicon is not always the best capture silicon.
With a supported adapter, Linux gives you full control of monitor mode through iw. Stop the processes that fight you for the radio, create a monitor interface, set the channel and width, then capture with Wireshark or tcpdump. Multi-channel is just several monitor interfaces on several adapters.
sudo airmon-ng check kill
# create a monitor interface on the phy
sudo iw phy phy0 interface add mon0 type monitor
sudo ip link set mon0 up
# tune it: channel + width, or explicit freq for 6 GHz
sudo iw dev mon0 set channel 149 80MHz
sudo iw dev mon0 set freq 5955 80 5985 # 6 GHz example
# capture
sudo wireshark -i mon0 | sudo tcpdump -i mon0 -w cap.pcap
Windows does not expose native monitor mode, which is its biggest limitation for capture. Two practical routes: a tool that ships its own monitor-capable driver, such as TamoSoft CommView for WiFi (commercial, with a trial), or a remote capture where a WLAN Pi does the monitoring and Wireshark on Windows pulls the stream over SSH. If you install Wireshark on Windows for the remote path, enable the Wi-Fi capture extcap component during setup, since it is not selected by default. Simultaneous multi-channel capture is not realistic on a Windows laptop alone.
Dedicated multi-radio tools (for example Ekahau Sidekick2 with its analyzer app, or NetAlly handhelds) capture several channels at once and double as survey gear. They cost money but remove the laptop limits and are built for fieldwork, including ad-hoc roaming captures.
A WLAN Pi with one or more supported adapters captures in monitor mode while you SSH in or stream into Wireshark. Add a USB hub with several radios, lock each to a channel, and you have affordable multi-channel capture from any host OS. This is how you give a Mac or Windows machine the multi-channel ability its own radio lacks.
When you cannot stand next to the client, the APs and controllers can capture for you. The trade is convenience and a possible decrypted view in exchange for an AP-perspective that is not the same as what the client heard.
Many vendors (Cisco, Aruba) can dedicate an AP to sniffer mode, which exports captured frames to a Wireshark host wrapped in a UDP transport that Wireshark decodes once you tell it to treat the traffic as remote wireless (the PEEKREMOTE decode). On a Cisco 9800 you can also filter a capture by client MAC at the controller, but the architecture decides whether that even works: in local mode all client traffic is CAPWAP-tunnelled to the WLC, so the WLC can capture it; in FlexConnect local-switching the client data never reaches the WLC, so a controller-side capture sees control-plane traffic only. Always know the deployment mode before you trust an infrastructure capture.
- No extra capture hardware to carry
- Centralised, often event-driven or automated
- Can offer a decrypted view (vendor dependent)
- Cloud platforms copy frames off the chipset without burdening the serving radio
- AP perspective only, not true over-the-air at the client
- Reduced RF visibility versus a sniffer beside the client
- Behaviour varies by vendor and deployment mode
- Cloud captures are capped by packet count or a time window
A capture you cannot read is just a large file. The fastest way to stop drowning in frames is to drive Wireshark with intent rather than scrolling. Three habits do most of the work:
- Display filters to isolate the conversation, for example one client's MAC across both directions, or only the frame types that matter to your question.
- A capture profile with custom columns (channel, RSSI, data rate, retry) and coloring rules so failures stand out at a glance instead of hiding in the noise.
- Protocol literacy first. The tool surfaces frames; the standard tells you which field matters. Reading a malformed RSN element or a reason code is a spec skill, not a tool feature.
Go deeper on this site: Wireshark Filters, Frame Lab, Connection Failure PCAP Guide, WLAN Pi PCAP Guide, and How Engineers Troubleshoot.
A PCAP records the frames in the air. A connected laptop is in managed mode and cannot record them. You need monitor mode and the right channel. On a Mac, AirTool2 or Wireless Diagnostics gets you there fastest.
Match the radio to the band and generation. One radio is one channel, so roaming needs several radios at once. Capture beside the client for client experience, and capture the wired side for 802.1X faults. Management and control frames are unencrypted and carry most answers.
Infrastructure captures depend on architecture: a 9800 sees FlexConnect client data nowhere near the WLC. Cloud captures copy off the chipset but cap on packets or time. For Wi-Fi 7, verify your capture radio is 802.11be and beware MLO link selection and new-silicon monitor-mode regressions.