CaptureSetup/WLAN - The Ethereal Wiki

Page 1 of 11

CaptureSetup/WLAN
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
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. Cisco/Aironet cards 2. Adapters using the Prism II chip set 3. Orinoco Silver and Gold cards 4. Cards with the Texas Instruments ACX100/ACX111 chipset

http://wiki.ethereal.com/CaptureSetup/WLAN?action=print

6/8/2007

CaptureSetup/WLAN - The Ethereal Wiki

Page 2 of 11

5. Cards with Atheros Communications chipsets 6. Cards with Ralink Technologies chipsets 7. Intel Centrino adapters 8. Other cards 9. Mac OS X 10. Windows 1. Intel Centrino adapters 2. Discussion

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 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.

http://wiki.ethereal.com/CaptureSetup/WLAN?action=print

6/8/2007

CaptureSetup/WLAN - The Ethereal Wiki

Page 3 of 11

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:

http://wiki.ethereal.com/CaptureSetup/WLAN?action=print

6/8/2007

CaptureSetup/WLAN - The Ethereal Wiki

Page 4 of 11

resolve addresses to host names using a network protocol such as DNS; save packets to a file on a network file server; etc.. Monitor mode is not supported by WinPcap, and thus not by Ethereal or Tethereal, on Windows. It is supported, for at least some interfaces, on some versions of Linux, FreeBSD, and NetBSD. 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: 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.
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 Ethereal 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 some 802.11 interfaces supported by the wi driver (Prism II and Orinoco, but not Spectrum24); 802.11 interfaces supported by the ath driver (Atheros - see page to find products that use Atheros chipsets); the Atheros customer products

if Ethereal is linked with libpcap 0.8.1 or later, and on Cisco/Aironet cards, if Ethereal 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.

http://wiki.ethereal.com/CaptureSetup/WLAN?action=print

6/8/2007

CaptureSetup/WLAN - The Ethereal Wiki

Page 5 of 11

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: 1, to turn monitor mode on; 2, if you want to capture traffic from any service set rather than just the service set with which the card is associated; 4, if you want to see beacon packets (capturing beacon packets increases the CPU requirements of capturing). Don't add 8 in to flag; Ethereal 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: in Ethereal, if you're starting the capture from the GUI, select "802.11" as the "Link-layer header type"; in Tethereal, or in Ethereal if you're starting the capture from the command line, add the argument -y IEEE802_11 to the command. 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.

http://wiki.ethereal.com/CaptureSetup/WLAN?action=print

6/8/2007

CaptureSetup/WLAN - The Ethereal Wiki

Page 6 of 11

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: in Ethereal, if you're starting the capture from the GUI, select "802.11 plus BSD radio information header" as the "Link-layer header type", if it's available (it won't necessarily be available for all interfaces supporting monitor mode); in Tethereal, or in Ethereal if you're starting the capture from the command line, add the argument -y IEEE802_11_RADIO to the command. 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 some 802.11 interfaces supported by the wi driver (Prism II and Orinoco, but not Spectrum24); 802.11 interfaces supported by the ath driver (Atheros); 802.11 interfaces supported by the atw driver (adapters using the ADMtek ADM8211 802.11 chipset); 802.11 interfaces supported by the rtw driver (adapters using the Realtek RTL8180 802.11 chipset); Cisco/Aironet interfaces; if Ethereal 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 802.11 interfaces supported by the ath driver (Atheros); 802.11 interfaces supported by the atw driver (adapters using the ADMtek ADM8211 802.11 chipset);

http://wiki.ethereal.com/CaptureSetup/WLAN?action=print

6/8/2007

CaptureSetup/WLAN - The Ethereal Wiki

Page 7 of 11

802.11 interfaces supported by the ral driver (adapters using the chipset);

Ralink Technology RT2500

802.11 interfaces supported by the rtw driver (adapters using the Realtek RTL8180 802.11 chipset); if Ethereal 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". 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, Ethereal would have to be linked with libpcap 0.7.1 or later; this means that

http://wiki.ethereal.com/CaptureSetup/WLAN?action=print

6/8/2007

CaptureSetup/WLAN - The Ethereal Wiki

Page 8 of 11

most Ethereal 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 Ethereal 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 Ethereal 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, Ethereal binary packages should work, as should compiling Ethereal 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 Ethereal from source, linking it with that new version of libpcap; an Ethereal binary package would not work. Ethereal binary packages might work if you install the libpcap-0.7.11prism.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. 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

http://wiki.ethereal.com/CaptureSetup/WLAN?action=print

6/8/2007

CaptureSetup/WLAN - The Ethereal Wiki

Page 9 of 11

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, Ethereal binary packages should work, as should compiling Ethereal 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 Ethereal from source, linking it with that new version of libpcap; an Ethereal binary package would not work. Ethereal 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. 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. 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). Cards with Ralink Technologies chipsets Does the Linux RT2400/RT2500 driver support monitor mode and/or 802.11 headers? -> Yes works fine with current cvs (2005-07-04) tested with WMP54G V4 Linksys. (So what are the commands used to put it into monitor mode? - Guy Harris) Intel Centrino adapters The open source Intel(R) Pro Wireless 2100 and 2200/2915 Drivers for Linux both 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). The ipw2200 drivers version 1.0.7 and newer can provide the captured data with radiotap headers (compile time option). A patch for ipw2100 exists but hat not yet (1.1.3) been integrated into the official source.

http://wiki.ethereal.com/CaptureSetup/WLAN?action=print

6/8/2007

CaptureSetup/WLAN - The Ethereal Wiki

Page 10 of 11

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.

Mac OS X
Using Apples own "Airport" 802.11 wireless cards, neither monitor mode, nor seeing 802.11 headers when capturing data, nor capturing non-data frames are supported - although promiscuous mode is supported. 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 Ethereal allows review of dumps you could then run them through the Ethereal analyzer. I don't have enough knowledge to tell how/if it is possible to point Ethereal 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!) If you have an internal AirPort Extreme card, you can use the new passive drivers in KisMac. Open KisMac and load the drivers, by starting a scan. Control channel hopping from within KisMac. Go back to ethereal and you should see a new interface called wlt1. Capture from this. You can even turn off channel hopping and join a network, while still capturing in monitor mode!

Windows
Capturing WLAN traffic on Windows depends on WinPcap and on the underlying network adapters and drivers. Currently, the only adapters that supports monitor mode in Windows is the AirPcap adapter from CACE Technologies. This adapter allows to capture control frames, management frames, and and radiotap power information. Besides this exception, the regular wireless 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 (Ethereal uses WinPcap to capture traffic on Windows), for information about particular adapters. 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 Ethereal 0.10.6 or later in order to have the non-data packets recognized and properly dissected.

http://wiki.ethereal.com/CaptureSetup/WLAN?action=print

6/8/2007

CaptureSetup/WLAN - The Ethereal Wiki

Page 11 of 11

Discussion
As this page is becoming very long, split into several subpages? Keeping the platform independant part here and creating platform dependent subpages? /BSD (incl. MAC OS X?) /Linux /Windows (hmm, will be currently small editada pela ltima vez em 2006-10-25 17:01:56 por 75

http://wiki.ethereal.com/CaptureSetup/WLAN?action=print

6/8/2007