Why does a Wireshark capture on a laptop's Wi-Fi interface miss the frames of a failing association, and what do monitor mode and radiotap add?
answer
- associated adapter, one network only
- promiscuous means little on 802.11
- management and control frames
- a pseudo-header from the driver
- the adapter may disassociate
basics
~20 sAn associated Wi-Fi adapter hands the host only data frames for its own network, so promiscuous mode adds little. Monitor mode passes every 802.11 frame it hears, management and control included, with a radiotap pseudo-header of signal, channel and rate.
solid answer
~40 sAn associated Wi-Fi adapter behaves like a NIC for one network: libpcap's documentation warns that even in promiscuous mode it supplies only frames for the network it joined, may supply only data frames, and may omit the 802.11 header and radio information. The probe, authentication and association frames you need never reach Wireshark. **Monitor mode** — the Monitor Mode checkbox in Capture Options, or `dumpcap -I` — makes the adapter pass every frame it receives with full 802.11 headers, and the link-layer type becomes "802.11 plus radiotap header": a pseudo-header the driver adds with signal strength, channel frequency and data rate. Support depends on adapter, driver and OS, and the adapter may disassociate while in monitor mode, so you watch the failing laptop from a second adapter tuned to the access point's channel.
go deeper
Recall that a normal Wi-Fi capture shows only your own network's data frames, that monitor mode exists for raw 802.11 frames, and that not every adapter supports it.
Explain what promiscuous and monitor mode each change, what the radiotap pseudo-header carries, and why the capturing adapter may lose its own connection.
Show how you would set up a capture of someone else's failing association: second adapter, right channel, monitor mode confirmed, and a receiver-side explanation ruled out before blaming the access point.
Weigh where wireless evidence should come from: ad hoc monitor-mode laptops against sensors or access points that can capture, and what each misses when a client's problem is intermittent.
## What a Wi-Fi adapter normally hands the host An adapter that has joined a network (station, or "managed", mode) behaves like a network card for that one network. The capture library's own documentation is blunt: on IEEE 802.11 LANs, **even in promiscuous mode** an adapter supplies the host only frames for the network it is associated with; it **might supply only data frames**, not management or control frames, and **might not provide the 802.11 header or any radio information**. On many systems those data frames appear in Wireshark as if they were Ethernet frames. For an association problem that is fatal. The frames that matter — probe requests and responses, authentication, the association request and response, and whatever the access point sends back — are exactly the ones a normal capture on the laptop does not contain. ## Promiscuous mode versus monitor mode | | Promiscuous mode | Monitor mode | |---|---|---| | Applies to | any adapter; meaningful on wired Ethernet | IEEE 802.11 adapters only | | What it changes | the adapter keeps frames not addressed to it | the adapter passes every frame it receives on its channel | | What you get on Wi-Fi | at best data frames of the joined network | data, management and control frames, from any network on the channel | | Headers | often a synthetic Ethernet header | full 802.11 header plus a radio pseudo-header | | Side effect | none on connectivity | the adapter may disassociate from its network | | How to set it | on by default; `dumpcap -p` turns it off | Monitor Mode checkbox, `dumpcap -I`, `wireshark -I` | Promiscuous mode is a wired-Ethernet idea. Turning it on for a Wi-Fi interface rarely shows other stations' unicast traffic, and other stations' data on a WPA2 or WPA3 network is encrypted under their own session keys anyway. ## What radiotap adds In monitor mode the link-layer header type becomes **"802.11 plus radiotap header"**. Radiotap is a **pseudo-header the capturing driver prepends** to each frame; it is never transmitted over the air. Wireshark's radiotap dissector exposes it as fields, for example: - `radiotap.dbm_antsignal` — the received signal strength, in dBm; - `radiotap.channel.freq` — the channel frequency the frame was heard on; - `radiotap.datarate` — the data rate it was sent at; - `radiotap.flags.badfcs` — set when the frame check sequence failed. Which fields appear depends on what the driver reports. They answer questions the 802.11 header cannot: was the access point barely audible, was the laptop on the expected channel, were frames arriving corrupted? ## Setting up the capture for a failing association 1. Use a **second adapter or machine** next to the laptop. The laptop's own adapter in monitor mode may drop its association — the very thing you are trying to watch. 2. Find the access point's channel and tune the capture adapter to it: `dumpcap -i wlan1 -k 2437` sets the frequency and exits, on systems where dumpcap can set the channel; otherwise use the operating system's own tools. 3. Enable monitor mode (`dumpcap -I`, `wireshark -I`, or the Monitor Mode checkbox) and confirm in Capture Options that the link-layer header reads 802.11 plus radiotap. 4. Reproduce the failure with the capture adapter roughly where the laptop is, so it hears what the laptop hears. ## What monitor mode still will not give you - **One channel at a time.** Frames on another channel or band are not heard. - **Not every frame.** The capture radio misses frames to reception problems like any receiver, and Wireshark's guide notes that frames are more likely to be lost in monitor mode. A frame missing from the capture is evidence about your receiver first, and about the network second. - **Not other stations' plaintext.** Their protected data frames stay encrypted unless you supply the keys and capture the key exchange — a WLAN security subject. The association exchange itself happens before any session key exists, so it is readable. - **Not support everywhere.** It depends on interface type, hardware, driver and OS; dumpcap reports `Capturing in monitor mode is not supported on device` when the adapter cannot do it. What each management frame means belongs to the 802.11 protocol topics; this setup only makes sure you have the frames.
- A monitor-mode capture shows the laptop's association requests but no responses from the access point; what must you rule out before blaming the access point?The capture radio, not the network, may be the gap. It may be on the wrong channel or width, farther from the access point than the laptop, or simply missing frames to reception problems. Check the radiotap signal strength of the access point's beacons in the same capture and move or retune the capture adapter. Absence in a monitor capture is evidence about your receiver before it is evidence about the access point.
- Why can enabling monitor mode cut the capturing machine off the network?In monitor mode the adapter may disassociate from the network it had joined, so it no longer carries that host's own traffic. Name resolution, a remote file share or a remote session in the middle of the capture can fail. Capture with a dedicated second adapter, or keep the machine connected through another interface.
saying these in an interview costs you the question
- Promiscuous mode on Wi-Fi shows every nearby station's frames, like a hub.
- Monitor mode works on every Wi-Fi adapter and operating system.
- The radiotap header is transmitted over the air by the access point.
- Monitor mode leaves the adapter's own network connection untouched.
- A frame missing from a monitor-mode capture was never transmitted.