WLAN (IEEE 802.11) capture setup

The following will explain capturing on 802.11 wireless networks (WLAN).

If you are only trying to capture network traffic between the machine running Wireshark or TShark and other machines on the network, are only interested in regular network data, rather than 802.11 management or control packets, and are not interested in radio-layer information about packets such as signal strength and data rates, you should be able to do this by capturing on the network interface through which the packets will be transmitted and received; no special setup should be necessary. (If you're trying to capture network traffic between processes running on the machine running Wireshark or TShark, i.e. network traffic from that machine to itself, you will need to capture on a loopback interface, if that's possible; see CaptureSetup/Loopback.)

If you're trying to capture network traffic that's not being sent to or from the machine running Wireshark or TShark, i.e. traffic between two or more other machines on an Ethernet segment, or are interested in 802.11 management or control packets, or are interested in radio-layer information about packets, you will probably have to capture in "monitor mode". This is discussed below.

Without any interaction, capturing on WLAN's may capture only user data packets with "fake" Ethernet headers. In this case, you won't see any 802.11 management or control packets at all, and the 802.11 packet headers are "translated" by the network driver to "fake" Ethernet packet headers.

A 802.11 LAN uses a "broadcast medium", much like (the mostly obsolete shared) Ethernet. Compared to Ethernet, the 802.11 network is even "broader", as the transmitted packets are not limited by the cable medium. That's one of the reasons why the 802.11 network adapters have two additional mechanisms to ignore unwanted packets at the receiving side: channels and SSID's.

Conclusion: the packets you'll be capturing with default settings might be modified, and only a limited number of the packets transmitted through the WLAN.

The following will provide some 802.11 network details, and will describe how to disable the translation/filtering and see what's "really" going on inside your WLAN.

Unfortunately, changing the 802.11 capture modes is very platform/network adapter/driver/libpcap dependent, and might not be possible at all (Windows is very limited here).

Table of contents

• WLAN (IEEE 802.11) capture setup
  • Table of contents
  • Packet Types
    • Link-Layer (Radio) packet headers
    • Data Packets
    • Non-data packets
      • Management Packets
      • Low-level Control Packets
  • 802.11 Filter (Modes)
    • Channels (Frequencies)
    • SSID/ESSID (Network Name)
      • Monitor mode
    • MAC Addresses
      • Promiscuous mode
  • Turning on monitor mode
    • *BSD
      • DragonFly BSD
    • Linux
    • macOS ([Mac] OS X)
    • Windows
      • Starting from Windows 7: Npcap
      • WinPcap
      • AirPcap
      • Intel Centrino adapters
    • Channel Hopping
• Discussion
  • See Also

Packet Types

802.11 traffic includes data packets, which are the packets used for normal network protocols; it also includes management packets and low-level control packets.

The 802.11 hardware on the network adapter filters all packets received, and delivers to the host

• all Unicast packets that are being sent to one of the addresses for that adapter, i.e. packets sent to that host on that network;
• all Multicast packets that are being sent to a Multicast address for that adapter, or all Multicast packets regardless of the address to which they're being sent (some network adapters can be configured to accept packets for specific Multicast addresses, others deliver all multicast packets to the host for it to filter);
• all Broadcast packets.

The driver for the adapter will also send copies of transmitted packets to the packet capture mechanism, so that they will be seen by a capture program as well.

In order to capture 802.11 traffic other than Unicast traffic to and from the host on which you're running Wireshark, Multicast traffic, and Broadcast traffic, the adapter will have to be put into monitor mode, so that the filter mentioned above is switched off and all packets received are delivered to the host. Promiscuous mode is, in theory, possible on many 802.11 adapters, but often does not work in practice; if you specify promiscuous mode, the attempt to enable promiscuous mode may fail, the adapter might only capture traffic to and from your machine, or the adapter might not capture any packets.

When not in monitor mode, the adapter might only capture data packets; you may have to put the adapter into monitor mode to capture management and control packets. In addition, when not in monitor mode, the adapter might supply packets with fake Ethernet headers, rather than 802.11 headers, and might not supply additional radio-layer information such as data rates and signal strength. You may have to perform operating-system-dependent and adapter-type-dependent operations to enable monitor mode; information on how to do so is given below.

On some platforms, such as FreeBSD, you may be able to capture non-data packets, and see 802.11 headers rather than fake Ethernet headers, without going into monitor mode, by selecting an 802.11 link-layer header type, rather than Ethernet, when capturing; however, that might not show both incoming and outgoing traffic.

Link-Layer (Radio) packet headers

802.11 adapters often transform 802.11 data packets into fake Ethernet packets before supplying them to the host, and, even if they don't, the drivers for the adapters often do so before supplying the packets to the operating system's networking stack and packet capture mechanism.

This means that if you capture on an 802.11 network, the packets will look like Ethernet packets, and you won't be able to see all the fields in the 802.11 header.

On some platforms, you can request that 802.11 headers be supplied when capturing, at least with some 802.11 adapters, regardless of whether you capture in monitor mode, sometimes called "rfmon mode" (see below); on some other platforms, you will get 802.11 headers in monitor mode, and only in monitor mode.

In addition, on some platforms, at least with some 802.11 adapters, you can get radio headers, supplying information such as signal strength, in addition to 802.11 headers. On some of those platforms, the radio headers are available whether you are capturing in monitor mode or not; on other platforms, they are only available in monitor mode. In Wireshark 1.4 and later, when built with libpcap 1.0 or later, there may be a "Monitor mode" check box in the "Capture Options" dialog to capture in monitor mode, and the command-line option -I to dumpcap, TShark, and Wireshark may be used to capture in monitor mode. However, due to problems with libpcap 1.0.x and libpcap 1.1.x, and due to the way libpcap 1.1.x is built on some Linux distributions, the check box and -I flag might not work on those distributions; see the "Turning on monitor mode" section below for information on how to capture in monitor mode if the check box and -I flag are either not available or don't work.

In FreeBSD 5.2 and later, NetBSD 2.0 and later, OpenBSD 3.7 and later, and DragonFly BSD 1.2 and later, you do not have to capture in monitor mode to get 802.11 headers, except when capturing on a Cisco Aironet adapter in FreeBSD. For earlier releases of those BSDs, 802.11 headers are not supported, except perhaps when capturing on a Cisco Aironet adapter in FreeBSD.

On Linux and macOS, you can only get 802.11 headers in monitor mode.

To see 802.11 headers for frames, without radio information, you should:

• in Wireshark, if you're starting the capture from the GUI, select "802.11" as the "Link-layer header type" in the "Capture Options" dialog;
• in dumpcap or TShark, or in Wireshark if you're starting the capture from the command line, add the argument -y IEEE802_11 to the command.

If 802.11 headers are not available for your 802.11 adapter on your platform at all, "802.11" will not be offered as a link-layer header type, and attempts to use -y IEEE802_11 even if the "Monitor mode" checkbox, if present, is checked, or if -I is specified on the command line. If they are only available in monitor mode, "802.11" will only be offered if the "Monitor mode" checkbox is checked or -I is specified on the command line.

For Wireshark 1.4 and later, when built with libpcap 1.0 or later, to determine from the command line what link-layer header types are available for an interface in monitor mode, run one of

• dumpcap -i interface -I -L
• tshark -i interface -I -L
• wireshark -i interface -I -L

Omit the -I to see what link-layer header types are available when not in monitor mode. For earlier versions of Wireshark, or versions of Wireshark built with earlier versions of libpcap, the -I flag is not specified; on Linux, you will have to put the adapter into monitor mode yourself (see below) to see what link-layer header types are available in monitor mode, and, in Mac OS X Leopard and later, selecting 802.11 headers will put the adapter in monitor mode.

To see 802.11 headers for frames, with radio information, you should:

• in Wireshark, if you're starting the capture from the GUI, select one of "802.11 plus BSD radio information header", "802.11 plus AVS radio information", or "802.11 plus Prism header" as the "Link-layer header type", if one or more of them are available (they won't necessarily be available for all interfaces supporting monitor mode);
• in dumpcap or TShark, or in Wireshark if you're starting the capture from the command line, add the argument -y IEEE802_11_RADIO, -y IEEE802_11_RADIO_AVS, or -y PRISM to the command - to see which of those are supported, run to see which are supported.

If 802.11+radio headers are not available for your 802.11 adapter on your platform at all, "802.11" will not be offered as a link-layer header type, and attempts to use -y IEEE802_11 even if the "Monitor mode" checkbox, if present, is checked, or if -I is specified on the command line. If they are only available in monitor mode, "802.11" will only be offered if the "Monitor mode" checkbox is checked or -I is specified on the command line.

Data Packets

Data packets are often supplied to the packet capture mechanism, by default, as "fake" Ethernet packets, synthesized from the 802.11 header; you don't see the real 802.11 link-layer header.

The driver for the adapter will also send copies of transmitted packets to the packet capture mechanism, so that they will be seen by a capture program as well.

Non-data packets

You might have to capture in monitor mode to capture non-data packets. If not, you should capture with 802.11 headers, as no "fake" Ethernet headers can be constructed for non-data frames.

Management Packets

Management packets are used by peer WLAN controllers to maintain a WLAN network, and as such is seldom of importance above OSI layer 2. They are discarded by most drivers, and hence they do not reach the packet capture mechanism. However, if adapter/driver supports this, you may capture such packets in "monitor mode" as discussed below.