WLAN (IEEE 802.11) capture setup

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

Without any interaction, capturing on WLAN's may only capture 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 much "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 amount of the packets transmitted through the WLAN.

The following will provide some 802.11 network details and describes how to disable those 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

Contents

  1. WLAN (IEEE 802.11) capture setup
    1. Table of contents
    2. 802.11 packets
      1. Link-Layer (Radio) packet headers
      2. Data Packets
      3. Non-data packets
        1. Management Packets
        2. Low-level Control Packets
    3. 802.11 Filter (Modes)
      1. Channels (Frequencies)
      2. SSID/ESSID (Network Name)
        1. Monitor mode
      3. MAC Addresses
        1. Promiscuous mode
    4. FreeBSD
      1. Cisco/Aironet cards
      2. Other adapters
    5. NetBSD
    6. OpenBSD
    7. DragonFly BSD
    8. Linux
      1. Adapters with mac80211 drivers
      2. Cisco/Aironet cards
      3. Adapters using the Prism II chip set
      4. Orinoco Silver and Gold cards
      5. Cards with the Texas Instruments ACX100/ACX111 chipset
      6. Cards with Atheros Communications chipsets
      7. Cards with Ralink Technologies chipsets
      8. Intel Centrino adapters
      9. Cards using the Zyxel ZyDAS 1211
      10. Other cards
      11. Channel Hopping
    9. Mac OS X
    10. Windows
      1. AirPcap
      2. Intel Centrino adapters
  2. Discussion
    1. See Also

802.11 packets

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.

Typically, when capturing on an 802.11 network, only data packets are captured; management and control packets aren't seen.

You may have to perform operating-system-dependent and adapter-type-dependent operations to enable these additional information, described in the platform specific sections below.

XXX - the packet description should be done at the WLAN page, only capture setup related info should remain here. (We should at least note that you might need to do something special to capture non-data packets, even if we, for example, remove the first sentence. -Guy Harris)

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; this is the case on newer versions of FreeBSD, NetBSD, and OpenBSD.

On some other platforms, you might have to capture in monitor mode (named also RFMON) to see 802.11 headers. (XXX - explain monitor mode first?) This is the case for Cisco Aironet adapters in FreeBSD, and for many adapters on Linux.

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

XXX - explain this in more detail

Low-level Control Packets

XXX - explain this in more detail

802.11 Filter (Modes)

802.11 adapters (or their drivers) will filter packets on the receiving side in several ways. This section will give an overview which mechanisms are used and if/how these filters can be disabled.

Channels (Frequencies)

802.11 uses radio frequencies in the range of 2412-2484 MHz; please note that not all frequencies are allowed to be used in all countries. 802.11 splits the available frequencies in 14 network channels, numbered 1-14 (-> 14 "wireless cables"). The frequency range of a channel partially overlaps with the next one, so the channels are therefore not independent. Channels 1, 6 and 11 have no overlap with each other; those three are the unoffical "standard" for wireless channel independence.

Since the frequency range that's unlicensed varies in each country some places may not have 14 channels. For example, Japan has #1-#14, Europe #1-#13 and the FCC in the US allows #1-#11.

The user has to choose which channel to use for the network adapter/access point. Traffic will only be sent to (or received from) that channel.

This filtering can't be disabled. However, special measuring network adapters might be available to capture on multiple channels at once.

SSID/ESSID (Network Name)

In normal operation the user sets the SSID (Service Set Identifier) at the access point and the network adapter. If multiple access points use the same SSID it's called an ESSID (Extended SSID). A network adapter will then filter based on this SSID and hand over packets to the host only of the same SSID as it's currently set itself to.

Monitor mode

In monitor mode the SSID filter mentioned above is disabed and all packets of all SSID's from the currently selected channel are captured.

Even in promiscuous mode, an 802.11 adapter will only supply packets to the host of the SSID the adapter has joined. Although it can receive, at the radio level, packets on other SSID's, it will not forward them to the host.

So in order to capture all traffic that the adapter can receive, the adapter must be put into "monitor mode", sometimes called "rfmon mode". In this mode, the driver will not make the adapter a member of any service set, so it won't support sending any traffic and will only supply received packets to a packet capture mechanism, not to the networking stack. This means that the machine will not be able to use that adapter for network traffic; if it doesn't have any other network adapters, it will not be able to:

etc..

Monitor mode is not supported by WinPcap, and thus not by Wireshark or TShark, on Windows. It is supported, for at least some interfaces, on some versions of Linux, FreeBSD, NetBSD, OpenBSD, and Mac OS X.

You will have to perform operating-system-dependent and adapter-type-dependent operations to enable monitor mode, described below.

MAC Addresses

The 802.11 hardware on the network adapter filters all packets received by the destination MAC address (just as in traditional Ethernet), and delivers to the host:

Promiscuous mode

In promiscuous mode the MAC address filter mentioned above is disabled and all packets of the currently joined 802.11 network (with a specific SSID and channel) are captured, just as in traditional Ethernet.

This seems to work on Linux and various BSDs, including Mac OS X. On Windows, putting 802.11 adapters into promiscuous mode is usually crippled, see the Windows section below.

Promiscuous mode can be enabled in the Wireshark Capture Options.

FreeBSD

In FreeBSD 5.2 and later, you should be able to capture in monitor mode, and see raw 802.11 headers on packets, on

if Wireshark is linked with libpcap 0.8.1 or later, and on Cisco/Aironet cards, if Wireshark is linked with libpcap 0.7.1 or later. Drivers for the Intel Centrino adapters were committed to the FreeBSD CVS source tree on April 18, 2005; it appears that the driver for the Intel(R) Pro Wireless 2100 will support monitor mode and raw 802.11 headers, so some future release will probably support that. The driver for the Intel(R) Pro Wireless 2200BG/2225BG/2915ABG doesn't appear to support monitor mode. Drivers were also committed then for the Ralink Technology RT2500 chipset, which appears to support monitor mode. (What about the driver for the Texas Instruments ACX100 chip set?)

On FreeBSD 4.6 through 5.1, you should be able to capture in monitor mode on Cisco/Aironet cards, but not on other adapters.

In FreeBSD 4.5 and earlier, you will not be able to capture in monitor mode on 802.11 adapters (no drivers supported it prior to 4.5, and in 4.5 the Aironet driver had bugs that caused packets not to be captured correctly).

Note that some adapters might be supported, in recent versions of FreeBSD, using the "ndisulator" or "Project Evil" mechanism. Unfortunately, if you use the ndisulator, you have the same limitations as Windows for 802.11 capture, which usually means "no monitor mode and no 802.11 headers".

Cisco/Aironet cards

For Cisco/Aironet cards, you can only see 802.11 headers in monitor mode; they are always supplied in monitor mode. To capture in monitor mode, you should put the card into monitor mode with the command ancontrol -i interface -M flag, where flag should be the sum of:

Don't add 8 in to flag; Wireshark currently doesn't support the full Aironet header.

When the capture completes, turn off monitor mode with the command ancontrol -i interface -M 0.

Converting the FreeBSD Aironet driver to use the new 802.11 framework in FreeBSD, and converting it to support the radiotap wireless header, are tasks in the FreeBSD Network Cleanup and Consolidation Project, also known as "Dingo". If that's completed, in any release containing a Dingoized Aironet driver, the Aironet card will work the same way as other 802.11 cards in FreeBSD.

Other adapters

For other adapters that support 802.11 headers, to see 802.11 headers for frames, you should:

For other adapters that support monitor mode, you should:

  1. Put the card into monitor mode with the command ifconfig interface monitor. You can also set the channel to monitor by adding the argument channel channel_number to that command.

  2. Request 802.11 headers, as per the above - fake Ethernet headers can be supplied for data frames, but that's impossible for management and control frames.

To get radio information with each packet, you should:

When a monitor mode capture completes, turn off monitor mode with the command ifconfig interface -monitor, so that the machine can again perform regular network operations with the 802.11 adapter.

NetBSD

In NetBSD 2.0 and later, you should be able to capture in monitor mode, and see raw 802.11 headers on packets, on

if Wireshark is linked with libpcap 0.8.1 or later. The instructions are the same as for FreeBSD (in NetBSD, unlike FreeBSD, for Cisco/Aironet cards the same instructions are used that are used with other adapters).

To get radio information with each packet, follow the same instructions as for FreeBSD.

OpenBSD

If you know the details for OpenBSD, please update the Wiki with that information. It appears that they are adopting the same mechanisms that FreeBSD and NetBSD are adopting for 802.11 support, so the answers for OpenBSD 3.7 might be similar to those for NetBSD 2.0 and later; it appears that in OpenBSD 3.7 and later you should be able to capture in monitor mode, and see raw 802.11 headers on packets, on

if Wireshark is linked with libpcap 0.8.1 or later. The instructions would be the same as for FreeBSD.

In addition, in OpenBSD 3.7, it appears that to get radio information with each packet, you would follow the same instructions as for FreeBSD.

There might be some support for fancier capture with Prism cards in older releases (if so, is that unique to OpenBSD)?

DragonFly BSD

From a quick look at the DragonFly BSD CVS source, it appears that the wireless capture support in DragonFly BSD 1.0 and 1.1 was like FreeBSD 4.x, with support only for Cisco/Aironet cards in the old style, and the support in 1.2 is more like FreeBSD 5.x, with the old-style Cisco/Aironet support and with new-style support for some interfaces supported by the wi driver (Prism II and Orinoco, but not Spectrum24).

To get radio information with each packet in DragonFly BSD 1.2 and later, it appears that you would follow the same instructions as for FreeBSD.

Linux

Whether you will be able to capture in monitor mode depends on the card and driver you're using. See this page of Linux 802.11b information for details on 802.11b wireless cards, including information on the chips they use, and see this page of Linux 802.11b+/a/g information for details on 802.11b+, 802.11a, and 802.11g wireless cards, including information on the chips they use.

In order to see 802.11 headers, you will have to capture in monitor mode. (XXX - true for all drivers?)

Note that some adapters might be supported using the NdisWrapper mechanism. Unfortunately, if you use NdisWrapper, you have the same limitations as Windows for 802.11 capture, which usually means "no monitor mode and no 802.11 headers".

Adapters with mac80211 drivers

For adapters whose drivers support the new mac80211 framework, to capture in monitor mode create a monitor-mode interface for the adapter and capture on that; delete the monitor-mode interface afterwards.

In newer Linux distributions with the iw command, first run the command ifconfig -a to find out what interfaces already exist with names beginning with mon followed by a number. Then choose a number greater than all of the numbers for monN devices; choose 0 if there are no monN devices. Then run the command iw dev interface interface add monnum type monitor, where interface is the ifconfig name for the adapter and num is the number you chose. If that succeeds, bring up the interface with the command ifconfig monnum up, and capture on the monnum interface. When you are finished capturing, delete the monitor mode interface with the command iw dev monnum interface del.

Cisco/Aironet cards

On Linux with the driver in the 2.4.6 through 2.4.19 kernel, put the card into monitor mode with the command echo "Mode: rfmon" >/proc/driver/aironet/interface/Config. If you want to capture traffic for any service set rather than just the service set to which the card belongs, use Mode: y rather than Mode: rfmon. When the capture completes, turn off monitor mode with the command echo Mode: ess >/proc/driver/aironet/interface/Config. (XXX - different command in ad hoc mode?)

On Linux with the driver in the 2.4.20 or later kernel, or with the CVS drivers from the airo-linux SourceForge site, you will have to capture on the wifiN interface if your Aironet card is ethN, after running the commands listed above.

In all of those cases, Wireshark would have to be linked with libpcap 0.7.1 or later; this means that most Wireshark binary packages won't work unless they're statically linked with libpcap 0.7.1 or later, or they're dynamically linked with libpcap and your system has a libpcap 0.7.1 or later shared library installed (note that libpcap source package from tcpdump.org does not build shared libraries). Some binary packaging mechanisms might make it difficult to install Wireshark binary packages built to depend on older libpcap binary packages if you have a newer libpcap binary package installed; the installer programs for those packaging mechanisms might support disabling dependency checking so that they will install Wireshark even though a newer version of libpcap is installed.

Adapters using the Prism II chip set

You can capture raw 802.11 packets with Prism II adapters on Linux systems with the 0.1.14-pre6 or later version of the linux-wlan-ng drivers (see the linux-wlan page, and the linux-wlan-ng tarball directory), or with the hostap driver for Prism II/2.5/3.

Those require either Solomon Peachy's patch to libpcap 0.7.1 (see his libpcap-0.7.1-prism.diff file, or his RPMs of that version of libpcap), or libpcap 0.8.1 or later. If your distribution comes with an 0.8.1 or later release of libpcap, Wireshark binary packages should work, as should compiling Wireshark from source. Otherwise, if you apply Solomon Peachy's patches to libpcap 0.7.1 and rebuild and install libpcap, or if you build and install an 0.8.1 or later version of libpcap, you would have to rebuild Wireshark from source, linking it with that new version of libpcap; an Wireshark binary package would not work. Wireshark binary packages might work if you install the libpcap-0.7.1-1prism.i386.rpm RPM, as it might install a libpcap shared library in place of the one on your system.

With the linux-wlan-ng driver, put the card into monitor mode with the command wlanctl-ng interface lnxreq_wlansniff enable=true. You should request 802.11 headers by adding to that command the option prismheader=true or, if supported, wlanheader=true; the latter might require libpcap 0.8.1 or later. You can also set the channel to monitor by adding the argument channel=channel_number to that command. When the capture completes, turn off monitor mode with the command wlanctl-ng interface enable=false. You might also have to turn 802.11 headers off with prismheader=false or wlanheader=false. See the wlan-ng FAQ for additional information, although note that it does not appear to be up-to-date.

With the hostap driver, you should put the card into monitor mode with the command iwpriv interface monitor mode, where mode is 2 or 3 (mode 3 would require libpcap 0.8.1 or later). When the capture completes, turn off monitor mode with the command iwpriv interface monitor 0. (Does iwconfig interface mode monitor, followed by iwconfig interface channel channel to select a channel, also work? If so, do you get 802.11 headers? Can you also get radio headers?)

Orinoco Silver and Gold cards

The current version of the SourceForge orinoco_cs driver should support monitor mode. There also exist patches to earlier versions of the Orinoco driver, on the Orinoco Monitor Mode Patch Page, to add support for monitor mode. You will have to determine which version of the driver you have, and select the appropriate patch, if one is necessary.

Note that the page indicates that not all versions of the Orinoco firmware support this patch. It says, for some versions of the patch, "This patch should allow monitor mode with v8.10 firmware (untested w/ 8.42);" if you have version 8.10 or later firmware on your Orinoco cards, you might have to use those patches, with the corresponding versions of the Orinoco driver, in order to run in monitor mode.

That patch is written for the drivers included with the pcmcia-cs drivers, but works equally well for the Orinoco drivers provided with Linux kernels up to 2.4.20. To apply a patch to your kernel drivers, simply copy the orinoco-09b-patch.diff file to the /usr/src/linux/drivers/net directory and patch according to the directions on the Orinoco Monitor Mode Patch Page. You can double- check the version of the Orinoco drivers that shipped with your kernel by examining the first few lines of the orinoco.c file.

The Orinoco patches and SourceForge driver require either Solomon Peachy's patch to libpcap 0.7.1 (see his libpcap-0.7.1-prism.diff file, or his RPMs of that version of libpcap), or libpcap 0.8.1 or later. If your distribution comes with an 0.8.1 or later release of libpcap, Wireshark binary packages should work, as should compiling Wireshark from source. Otherwise, if you apply Solomon Peachy's patches to libpcap 0.7.1 and rebuild and install libpcap, or if you build and install an 0.8.1 or later version of libpcap, you would have to rebuild Wireshark from source, linking it with that new version of libpcap; an Wireshark binary package would not work. Wireshark binary packages might work if you install the libpcap-0.7.1-1prism.i386.rpm RPM, as it might install a libpcap shared library in place of the one on your system.

With a driver that supports monitor mode, you should put the card into monitor mode with the command iwpriv interface monitor mode channel_number, where mode is 1 or 2, and channel_number is the number of the channel to monitor. When the capture completes, turn off monitor mode with the command iwpriv interface monitor 0. (Does iwconfig interface mode monitor, followed by iwconfig interface channel channel to select a channel, also work? If so, do you get 802.11 headers? Can you also get radio headers?)

Cards with the Texas Instruments ACX100/ACX111 chipset

You can capture raw 802.11 packets with ACX100/ACX111 cards on Linux systems with the ACX100 OSS drivers available from the ACX100 wireless network driver project SourceForge site.

With that driver, put the card into monitor mode with the command iwpriv interface monitor 2 channel_number, where channel_number is the number of the channel to monitor. When using an ACX111 card iwpriv interface monitor 1 channel_number works. When the capture completes, turn off monitor mode with the command iwpriv interface monitor 0. (Does iwconfig interface mode monitor, followed by iwconfig interface channel channel to select a channel, also work? If so, do you get 802.11 headers? Can you also get radio headers?)

Cards with Atheros Communications chipsets

See the Atheros customer products page to find products that use Atheros chipsets.

You can capture raw 802.11 packets with AR5K cards on Linux systems with the v5_ar5k or madwifi drivers. For the v5ar5k driver you will need the Linux wireless-tools version 25 or higher to put the card into monitor mode. If you're using the madwifi driver, you can put the card into monitor mode using iwconfig interface mode monitor, followed by iwconfig interface channel channel to select a channel (if needed). THis works only on the old version of the madwifi driver. If you are using the new version, also known as madwifi-ng, you must create a monitor vap with the command wlanconfig ath create wlandev wifiX wlanmode mon. For further information read the madwifi documentation, included with versions 0.9.0 and up.

Cards with Ralink Technologies chipsets

The Linux RT2400/RT2500 driver supports monitor mode. Put the card into monitor mode using iwconfig interface mode monitor, followed by iwconfig interface channel channel to select a channel (if needed). (Does this give 802.11 headers, or 802.11 headers plus radio headers?)

Intel Centrino adapters

The open source Intel(R) Pro Wireless 2100,2200/2915 and 3945 Drivers for Linux support monitor mode. You can put the card into monitor mode using iwconfig interface mode monitor, followed by iwconfig interface channel channel to select a channel (if needed). Optional (compile time) support for additional radiotap headers is provided in all drivers and starts with the following versions: ipw3945 version 0.0.71, ipw2200 version 1.0.7 and ipw2100 drivers version 1.2.1. The ipw2200 and ipw3945 drivers have another feature that allows to use the wireless interface normally and at the same time capture the raw traffic passing through it: The rtapX interface. You'll need to add the following line to your /etc/modprobe.d/ipw3945 file: "options ipw3945 rtap_iface=1". After that, do an "ifconfig rtap0 up" and start capturing on that interface. For ipw2200 replace 3945 by 2200.

Cards using the Zyxel ZyDAS 1211

The ZyDAS 1211 chipset supports monitor mode with the open-source drivers available from the zd1211 project. This chipset is exclusive to USB dongles, and quite common. The quickest way to put it into monitor mode is to issue iwconfig interface mode monitor. The driver is built into the kernel starting with 2.6.18, but can be built out-of-tree on any 2.6 kernel.

Other cards

It might be possible to capture in monitor mode on other cards. If so, please update the Wiki with information on how to do so.

Channel Hopping

When capturing traffic in monitor mode, you can capture on a single, fixed channel, or capture while hopping through multiple channels (channel hopping). Channel hopping will inevitably cause you to lose traffic in your packet capture, since a wireless card in monitor mode can only capture on a single channel at any given time. However, it may be desirable to perform channel hopping initially as part of your analysis to idenitfy all the networks within range of your wireless card, and then select the channel that is most appropriate for analysis.

If you are capturing traffic to troubleshoot a wireless connectivity problem, or to analyze traffic for a single AP or station, it's best to capture on a single, fixed channel.

In order to implement channel hopping for a wireless packet capture, users have a few options. Wireshark does not have a built-in facility to perform channel hopping during a packet capture, but you can have multiple processes controlling a single wireless card simultaneously; one to perform the channel hopping, and a second process to capture the traffic (Wireshark, in this case).

One tool that is particularly effective and flexible for performing channel hopping is Kismet (http://www.kismetwireless.net). The user can control the desired channels, frequencies (e.g. 802.11b, 802.11g, 802.11a) and hopping rate by editing the kismet.conf file. see the Kismet README file at http://www.kismetwireless.net/documentation.shtml#readme.

If you are looking for a simpler channel hopping solution, you can use the following shell script; modify it to suit your needs.

http://802.11ninja.net/code/chanhop.sh

Save this script to a file (e.g. /usr/local/bin/chanhop.sh) and run: 

# chmod 700 /usr/local/bin/chanhop.sh

As root, to make the script executable. Running the script with no arguments displays the following usage instructions: 

chanhop.sh: Usage:
./chanhop.sh [-i|--interface] [-b|--band] [-d|--dwelltime]
-i or --interface specifies the interface name to hop on [mandatory]
-b or --band specifies the bands to use for channel hopping, one of
        IEEE80211B      Channels 1-11 [default]
        IEEE80211BINTL  Channels 1-13
        IEEE80211BJP    Channels 1-14
        IEEE80211A      Channels 36-161
    Use multiple -b arguments for multiple channels
-d or --dwelltime amount of time to spend on each channel [default .25 seconds]
e.x. ./chanhop.sh -i ath0 -b IEEE80211BINTL -b IEEE80211A -d .10
Exiting.

To use the script, specify the interface name that is monitor mode as the only mandatory arugment: 

# ./chanhop.sh -i ath0
Starting channel hopping, press CTRL/C to exit.

By default, this will cause the specified interface to cycle through the eleven IEEE 802.11b channels with a dwell time of .25 seconds. Optionally, you can specify additional channels with a different dwell time for each channel. For example, if you wish to channel hop between the IEEE 802.11b and IEEE 802.11a channels with a .10 second dwell time, you can specify the following arguments: 

# ./chanhop.sh -i ath0 -b IEEE80211B -b IEEE80211A -d .10
Starting channel hopping, press CTRL/C to exit.

The chanhop.sh script requires the Wireless Tools utility "iwconfig" and standard Linux shell script tools (whoami, sleep).

Constructing similar scripts, using "ifconfig" rather than "iwconfig", for versions of {Free,Net,Open,DragonFly}BSD with the 802.11 framework and adapters whose drivers support the standard 802.11 framework ioctls is left as an exercise for the reader.

Mac OS X

Using Apple's own AirPort Extreme 802.11 wireless cards:

In Mac OS X releases prior to 10.4.0 (Panther and earlier), neither monitor mode, nor seeing 802.11 headers when capturing data, nor capturing non-data frames are supported - although promiscuous mode is supported.

In Mac OS X 10.4.x (Tiger) (at least in later updates), monitor mode is supported; 802.11 headers are provided, and non-data frames are captured, only in monitor mode. To capture in monitor mode on an AirPort Extreme device named enn, capture on a device named wltn instead - for example, if your AirPort Extreme device is named en1, capture on wlt1. On PowerPC Macs, you will have to enable that device by changing the !APMonitormode property in the /System/Library/Extensions/AppleAirport2.kext/Contents/Info.plist property list file to have the value "true" (<true/>) and rebooting; on Intel Macs, that device is enabled by default.

In Mac OS X 10.5.x (Leopard) and 10.6.x (Snow Leopard), monitor mode is supported; 802.11 headers are provided, and non-data frames are captured, only in monitor mode. To capture in monitor mode on an AirPort Extreme device, select a "Link-layer header type" other than "Ethernet" from the Capture -> Options dialog box in Wireshark or by selecting a link-layer header type other than "EN10MB" with the "-y" flag in TShark or from the command line in Wireshark (the available link-layer types are printed if you use the "-L" flag).

If you use a Prism II chipset PCMCIA card in a Powerbook, or use another wireless card which is supported appropriately by the wireless sourceforge drivers, you may be able to use software such as KisMAC to dump to file full frames captured in passive mode. Since Wireshark allows review of dumps you could then run them through the Wireshark analyzer. I don't have enough knowledge to tell how/if it is possible to point Wireshark to such a PCMCIA card, or to get it to watch a growing dump file, to allow live analysis but I think it's a plausible project. (if you manage it then remember to write it up here!)

Windows

Capturing WLAN traffic on Windows depends on WinPcap and on the underlying network adapters and drivers. Unfortunately, most drivers/adapters support neither monitor mode, nor seeing 802.11 headers when capturing, nor capturing non-data frames.

Promiscuous mode can be set; unfortunately, it's often crippled. In this mode many drivers don't supply packets at all, or don't supply packets sent by the host.

If you experience any problems capturing packets on WLANs, try to switch promiscuous mode off. In this case you will have to capture traffic on the host you're interested in.

If anybody finds an adapter and driver that do support promiscuous mode, they should mention it at the bottom of this page, for the benefit of other users.

See MicroLogix's list of wireless adapters, with indications of how well they work with WinPcap (Wireshark uses WinPcap to capture traffic on Windows), for information about particular adapters.

Useful video to set up packet capture on wireless using Windows bridging: http://www.micro-logix.com/WinPcap/howtonetworkbridge.avi

AirPcap

The AirPcap adapters from CACE Technologies allow full raw 802.11 captures under Windows, including radiotap information.

Intel Centrino adapters

You might have some success capturing non-data frames in promiscuous mode with at least some Centrino interfaces. As these interfaces encapsulate the 802.11 header in a fake Ethernet packet in a non-standard fashion, you will need Wireshark 0.10.6 or later in order to have the non-data packets recognized and properly dissected.

Discussion

As this page is becoming very long, split into several subpages? Keeping the platform independant part here and creating platform dependent subpages?

See Also

CategoryHowTo

CaptureSetup/WLAN (last edited 2010-01-06 23:04:31 by GuyHarris)