Wicrawl Card Support
(Redirected from Card Support)
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} midnightresearch.com] 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: http://en.wikipedia.org/wiki/Comparison_of_Open_Source_Wireless_Drivers
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: http://zd1211.ath.cx/wiki/DriverRewrite | |
| 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 http://ubuntu.cafuego.net/pool/dapper-cafuego/bcm43xx/bcm43xx-firmware_1.3-1ubuntu1_all.deb | |
| 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
Contents |
[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:
- The card make and model
- The driver you installed for that card
- 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:
- Change channels in the channel hopper
- Enable and disable monitor mode as we start and stop wicrawl
- 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:
- Prism2 (linux-wlan)
- Prism2 AVS (linux-wlan-ng)
- 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:
- 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:
http://madwifi.org/wiki/UserDocs/MonitorModeInterface
[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:
- People with a strong belief in open source hate it because they can't fix the driver if it acts funny.
- 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.
- 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:
http://sysnet.ucsd.edu/pawn/wrapi/
[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.