MRL WikiMain Page | About | Help | FAQ | Special pages | Log in

Printable version | Disclaimers | Privacy policy

Wicrawl Card Support

From MRL Wiki

Here is a list of the Cards that are known to work with wicrawl. If you have a card that you know not to work, please update all the columns in the table. If you don't feel comfortable editing a wiki, email [wicrawl-cvs {at}] with the info, and we can update it.

To get an idea of what your driver options are for your card, see the nice page on Wikipedia:

Please be sure to add the version of the driver you are using, including if you are running any patches. Some things that might help us to diagnose would be the output of: lsmod, lspci, lshw, and iwconfig. Thanks!

Note: your card probably works, even if it's not in the list below. If you try it and it works, please add it to the list.

Note: Pretty much any PCMCIA or mini pci card which has an atheros chipset will work.

Card Chipset Driver Status Last Updated
Proxim 8270WD Atheros mad wifi Works
Netgear WG511T Atheros madwifi-ng Works 16-May-2007
Ubitiqui SRC Atheros 5004 madwifi Works with Backtrack 2 CD 04-May-2007
Intel 2200 Intel 2200 ipw2200 1.0.6+ Works. Older ipw2200 drivers require that you define CONFIG_IEEE80211_RADIOTAP in ipw2200.c to get the IEEE802_11_RADIO DLT. 8/14/2007
Intel 2100 Intel 2100 (rev04) ipw2100 Works.
Intel 2915 Intel 2915 ipw2200 Works 11/7/2006
Intel 3945 ABG Intel 3945 ipw3945 Works. See notes on ipw2200 12/28/2006
Senao SL-2511CD Prism 2.5 hostap Works [1]Note
ZyXEL ZyAIR G-110 Prism GT prism54 Works (tested under Ubuntu 6.06)
Linksys WPC55AG Atheros madwifi Works
Airlink AWLL3026 ZyDAS 1211 zd1211 Doesn't work. Use the zd1211rw drivers:
Linksys WPC11 Prism 2 hostap Works -- use iwpriv wlanX monitor_type 2 to get AVS headers
Linksys WPC11 Prism 2 orinoco Works, but no radio headers
Linksys WPC54Gv2 TI TNETW1130 ACX111 Works (tested under Ubuntu 7.4) 07/16/07
D-Link DWL-G630 Atheros madwifi Works
D-Link DWL-G650 Atheros madwifi Works
D-Link DWL-G122 B1 Ralink serialmonkey Does not work. "apcore: setMonitorMode() doesn't know how to enable monitoring on interface rausb0"
Motorola WN825G Broadcom br43xx Work
wget -c
Airport Extreme Broadcom bcm43xx Doesn't compile on ppc (G4), assembly registry error
Airnet AWN108 Atheros madwifi "wlanconfig ath create wlandev wifi0 wlanmode monitor" then "iwconfig ath# up" where # is the number assigned by kernel form previous command
MSI PC54G3 RaLink RT61 serialmonkey Works 2008-09-09

[1]Note Does not work on backtrack (v1) CD with either orinoco drivers

Main page -- Wicrawl


[edit] What Card Should I Get?

Depends on what OS you're using.

Linux: get an Atheros card with external antenna jack (if you don't mind running a driver with a binary core). We really like the Senao ones.

BSD: get something with a Prism2 chip in it.

OS X: we don't support OS X yet.

Windows: get an Airpcap card, then bug us to write the support for it. In theory, everything except the GUI should work on windows with an Airpcap card, but we haven't tried it..

[edit] Wireless APIs

[edit] Overview

The way we talk to the different cards is by using an API, or application programming interface. The API we use is determined by a few things:

  1. The card make and model
  2. The driver you installed for that card
  3. The operating system you're using

Open source being what it is, you sometimes get to choose which driver you want to use, especially for the Prism 2 (good) cards.

We use these APIs to do a few things:

  1. Change channels in the channel hopper
  2. Enable and disable monitor mode as we start and stop wicrawl
  3. Ask the drivers for extended radio headers, which contain things like the rx signal level and channel number.

[edit] Radio Headers

In rfmon mode, we expect the drivers to give us all the layer-2 data they get from the wire. However, there is other metadata associated with the frame, like the rx signal level, antenna used, etc. This information is prepended to the frame using an extended "radio header." The radio header formats we currently support:

  1. Prism2 (linux-wlan)
  2. Prism2 AVS (linux-wlan-ng)
  3. Radiotap

The first two are hacks, and kind of prism2 specific. The radiotap header format comes from work done by BSD wireless hackers, and is much more future-proof and hardware-independent than the other two. Although it's a little harder to parse because it's variable-length, the flexibility of the format is well worth adding support for it.

We do not support:

  1. Atheros descriptors

[edit] Linux

rfmon-capable Linux drivers get to pick which radio header format they'll return: we've seen Prism2, AVS, and Radiotap. Most newer drivers use the shiny new Radiotap format.

One annoying thing about the selection of radio headers is that the kernel will return the same ARPHRD value for both the Prism2 and AVS cases -- since libpcap uses the ARPHRD value to figure out what DLT to give us, we have to have special logic to figure out which radio header is really being provided.

[edit] Linux Wireless API

On Linux, the "offical" API is the Linux Wireless APIs, which are documented primarily in /usr/include/linux/wireless.h. On-line documentation doesn't really exist.

[edit] linux-wlan-ng

The linux-wlan-ng package only support prism2 cards. They only provide a few Linux Wireless APIs, providing most functionality via a driver-specific API.

The linux-wlan-ng API is SNMP-like in that it implements all the MIBs required by the 802.11 spec and makes them available to us using a very... original... set of ioctl() calls. Packing and unpacking data going to and from the linux-wlan-ng driver is very complicated, so we interface with it by calling their userspace tools instead of trying to deal with their API directly.

You're probably better off using the HostAP drivers if at all possible, since you'll be in good company with all the other wicrawl users using our Linux Wireless API support.

[edit] HostAP

The HostAP drivers also only support Prism cards, but have all kinds of fancy features like being able to act as an AP and more flexible rfmon support. If you have a Prism card, use these drivers.

The HostAP drivers provide most of the functionality of the linux-wlan-ng driver, except they use the Linux Wireless APIs instead of the linux-wlan-ng ones. The hostap drivers can return either the PRISM headers or the AVS headers, if you pass 1 or 2 respectively to "iwpriv wlan0 monitor_type X". You really want to pass 2 (AVS headers), because in the Prism header case, the HostAP drivers do this:

 LWNG_SETVAL(channel, 3, 1 /* no value */, 4, 0);

Which gives wicrawl a zero value for the channel in all incoming frames. In the AVS case, the HostAP driver does set the channel correctly:

 hdr->channel    = htonl(local->channel);

[edit] Orinoco

Don't use these with your prism2 card; they don't provide radio headers. Although wicrawl will work fine, you'll be missing things like power and channel data that might be used by future plugins. On older (2.4 and lower) distributions, you can patch /etc/pcmcia/config for your card (say "cardctl info X" to figure out which card you have) so it says this:

 bind "hostap_cs"

instead of this:

 bind "orinoco_cs"

On newer 2.6 distributions, you have to rename the orinoco_cs.ko module to something else entirely. The new way of figuring out which module to load for your card is to just ask the module what card IDs it supports. Since both orinoco_cs and hostap_cs are probably capable of binding to your Orinoco card, you need to rename the orinoco driver if you want to use the hostap driver instead.

[edit] madwifi

The madwifi drivers have many advanced features, which need to be set up prior to running wicrawl using the wlanconfig command. In particular, newer versions of the madwifi drivers require you to set up a special monitor mode VAP prior to using wicrawl:

[edit] When DLT Detection Fails

Detecting the radio packet header format is a crap shoot. We rely on libpcap to tell us what the radio packet headers should look like, and guess if libpcap says it doesn't know. The cards listed above all work fine with the current logic. When libpcap says it doesn't know, the discovery engine outputs this message if we don't have override logic for your card:

Warning: unknown DLT type, assuming no header.

If this happens, and your card doesn't work, then email the wicrawl development list and we'll have a look.

[edit] Aironet

We've tested some Cisco Aironet cards on Ubuntu 5.10, after receiving reports that they don't work right with wicrawl on Linux. After investigation, we discovered that libpcap thinks that the Aironet card is using the DOCSIS data-link type, which happens in cases where libpcap thinks it could see DOCSIS frames on an ethernet medium. Because a wireless cable modem is a contridiction, this is obviously crazy and we abort when we detect this situation. Please try a newer libpcap to see if the problem goes away. Otherwise, email us. We currently have no-one outside of MRL complaining about this, so it's unlikely to get fixed without additional feedback.

[edit] FreeBSD and OpenBSD

On FreeBSD and OpenBSD, the oldest and best support is for cards with a Prism2 or Prism2-like chipset. Other cards are supported natively, but not as many people use them, reducing the available community support.

All BSDs use a standard radio header format, so we don't have the DLT detection problems found on Linux. The cards have card-specific APIs for setting things up, so we have to support each one individually.

[edit] NDIS Drivers

FreeBSD, Linux, and possibly other operating systems use a tool called ndiswrapper to load binary NDIS drivers to drive cards which don't have OS-native support. This is controversial for several reasons:

  1. People with a strong belief in open source hate it because they can't fix the driver if it acts funny.
  2. NDIS 5.0 and 5.1 do not provide APIs for doing things like monitor mode, and have spotty support for things like per-MAC rx power detection.
  3. Some people believe that it will remove any justification for vendors to write OS-native drivers for their hardware, and reduce any motivation for vendors to provide programming documentation for the hardware.

The discovery engine will probably hook directly into the NDIS layer at some point to do AP scanning and power level detection, but the limited evidence indicates that it will probably result in a speed hit. This may or may not matter for practical purposes.

Windows uses NDIS drivers, so in theory we could use this to port wicrawl to Windows. NDIS 6 (Vista) supports 802.11 natively instead of using a fakey 802.3 interface, so we may write the pcap parts necessary to do rfmon on Windows using the new WCF layer or by patching the winpcap kernel driver.

An outside contributor has reported some success porting wicrawl to cygwin using WRAPI to avoid having to talk to NDIS directly:

[edit] Solaris

Yeah, we should probably do that.

[edit] Broadcom wl Drivers

Broadcom ships a family of wireless chipsets that show up in many commercial access points. The OpenWRT project is doing a good job of providing a mini-distribution that will allow you to boot Linux on the access points and have it do a few simple things.

We will probably support direct access to the wl driver's APIs sometime in the future, so you could deploy the scanning component of wicrawl on an AP.

[edit] Kismet

Kismet's server component provides a protocol that we could speak to it if we wanted to use Kismet for AP discovery. This will probably happen, due to their incredible list of supported cards. Furthermore, this would allow us to do distributed sniffing by deploying kismet drones.

Retrieved from ""

This page has been accessed 32,155 times. This page was last modified on 9 September 2008, at 15:17.


Main Page
Community portal
Current events
Recent changes
Random page
Edit this page
Editing help
This page
Discuss this page
New section
Printable version
Page history
What links here
Related changes
My pages
Log in / create account
Special pages
New pages
File list