In my second
wireless article, I discussed setting up both linux-wlan-ng and
Prism2 Host AP. It's now
been about three months and things have changed dramatically since
the May release of HostAP, so it's time to renew my discussion of
installation and configuration.
First, A Brief Word On Compatible 802.11b Cards
HostAP only works with Intersil's Prism{2,2.5,3} chipset
for PCI, PLX, and PC Card interfaces. So, which cards come with the
Prism chipset? That's a pretty good question. Due to the economics
of production, what card has what chipset changes occasionally. As
of this writing D-Link plans on switching to the Atmel chipset for
their DWL-650 (non plus) card and LinkSys has already
switched its WMP11 PCI card to a BroadCom chipset. Neither chipsets
are supported by HostAP. (I know of no Linux support as of this
writing for BroadCom's WiFi chipset, but if you're using a card that
ships with the Atmel chipset, you might be in luck. I refer you to
this
page for more information.)
You can find information on various wireless cards and which
chipsets they ship with at PersonalTelco's Prism2Card
page or Seattle
Wireless' Hardware
Comparison. Keep in mind the actual chipset being used is
subject to change at the vendor's discretion and it may not be
obvious until after you install the card and find out it isn't a
Prism card.
One last thing might aid you in your search. It's the FCC's
Office of Engineering and Technology search page, where you can
search through vendor's documentation and test submissions to the
Federal Communications Commission (U.S.). The only catch is you need
your vendor's FCC ID.
For products sold in the U.S., it will be on the device itself,
but that won't help you if you don't already own one. Another
solution is to search
for your vendor's name under Grantee Search Report. Use the
Grantee Code given in the search results to look up your
vendor. From there, you'll need to identify the product that
interests you by going through each entry sequentially or finding a
familiar string in the FCC IDs listed in the results. The documents
are all in PDF format, and may or may not contain any information
about the chipset on the card. You will find other interesting
things like card output power and antenna connector type, if
applicable.
Things You'll Need Before Starting With 2002-10-12
First, you'll need to acquire these things:
- Linux Kernel v2.4.20
- Host AP driver driver v2002-10-12
- Linux Wireless Extensions Tools v25
(or apt-get install wireless-tools under Debian GNU/Linux)
- Wireless Extensions v15 patch
- Wireless Extensions v16 patch
(optional, but useful if you want to run more recent HostAP CVS)
- Optionally you can install any other
Wireless Extensions patches you may need, but most of these
are already in 2.4.20-pre2 and above.
You'll need to apply
the wireless extension v15 patch (or the other wireless extension
patches of your choice in order first, then finally the v15 patch)
to your shiny new 2.4.20 kernel.
On my x86 box, at least, 2.4.19 and 2.4.20 perform very
poorly. Poorly in the sense that the machine frequently pauses and
mouse and keyboard input aren't possible. As this appears to be a
known issue with 2.4.19 and 2.4.20, I am recommending people that
have problems with 2.4.20 to use 2.4.18 instead. You will need both
the WEv13
and WEv14
patchs, which you must apply in order before WEv15 linked above, if
you choose to use 2.4.18.
When you patch your kernel with WEv15, you may receive the
following error:
Hunk #9 succeeded at 678 (offset -2 lines).
Hunk #10 succeeded at 697 (offset -2 lines).
Hunk #11 succeeded at 963 (offset -2 lines).
1 out of 11 hunks FAILED --
saving rejects to file net/core/wireless.c.rej
You can safely ignore the reject error -- That hunk contains
comments only. There is no code in that hunk.
When you build your new kernel, make sure you enable the Wireless
Extensions! Optionally if you want to bridge a wired and
wireless network, enable 802.1d Ethernet
Bridging (Kernel Ethernet Bridging) in your kernel
configuration.
If you are running a recent RedHat distribution, compiling HostAP
may not be necessary. Aaron Baer has assembled
RPMs for i386 and i686 systems with a kernel (and HostAP as a
module) ready to go. The source RPM is also available for your
customization needs.
A (Not So) Brief Firmware Discussion
Firmware comes up a lot with regard to host based AP mode. There
are quite a few different kinds of firmware available for your card.
(In some cases availability is at the discretion of your WiFi card
vendor.) Firmware drives the Media Access Controller, or MAC. ( But
don't confuse it with the mac address, which is a unique 48 bit
number given to network interface cards to identify your card on the
network and closely related to the MAC itself; Hence "mac address".)
There are at least four kinds of firmware surrounding Intersil
Prism cards, including the initial, primary, secondary, and tertiary
firmware. The initial firmware is bootstrap code and is used only
when initially programming the adapter. The primary firmware deals
with network interface card stuff, like interfacing with the system
bus. It also enables you to load or upgrade other kinds of firmware.
The secondary firmware deals with the Prism radio. Intersil's Prism
chipset secondary firmware (often called the station firmware) is
unique in that it deals with time sensitive tasks like frame
acknowledgement and beacon transmission. The tertiary firmware deals
with access point specific things.
The primary and secondary firmware are the most important,
especially the secondary, because its handling of time sensitive
tasks makes host computer based access points possible. It's also
the firmware revision that will cause you the most grief if your
card has a known broken secondary (or primary) firmware revision.
He's a list of secondary firmware revisions that are in the wild:
- 0.7.5
- Known to generate INFDROP events under high load
- 0.8.0
- Same as above
- 0.8.3
- Known good
- 1.3.4
- Jouni
Malinen writes, "However, one should note that PRI 1.0.5 and
STA 1.3.4 have some PCI bus related bugs that cause packet
corruption."
- 1.3.5
- Known good
- 1.3.6
- Known good
- 1.4.2
- Jouni
Malinen explains, "The bug in 1.4.2 causes the card to not
reply Probe Request frames in Host AP mode. However, beacon frames
are sent correctly."
- 1.4.9
- Known good -- Only version up to this point to support
firmware based WEP encryption properly
- 1.5.6
- Exists; Works and WDS mode can send standards compliant WDS
frames with this STA firmware
- 1.6.3
- Internal Intersil; Unavailable publicly to my knowledge (It is
reported to work with CVS > 2003-02-01, though)
- 1.7.2
- Unavailable, but I believe it exists.
If you use 0.8.3, 1.3.{5,6}, or 1.4.9 you should be in good
shape. Intersil has secondary firmware revision 1.5.x out now, but I
don't know of any cards that ship with that revision yet. If you
have known bad firmware, check with your vendor to see if there's a
new firmware revision available for you to flash your card with.
If your vendor can't help, you can try these as a last resort.
Avishai Wool has made available a Windows LinkSys utility patched to
flash LinkSys
cards to revision 1.4.9. As his page says, use this at your own
risk. I have not used it personally, so you're on your own. If you
have one of the many other brands of cards shipping with the Prism
chipset, you might try these
firmware hex images hosted by NetGate. Each file includes two
PDFs explaining which hex file is compatible with which card
variants. The RAM based images can be loaded with a HostAP utility
we'll discuss later.
Installing The Prism2 Host AP driver
Here, I will walk through installation of a PCI based Prism2
card. PLX style cards are installed in a similiar fashion, but
you'll want to substitute plx for pci in the commands
and output below.
First, dump the hostap-2002-10-12.tar.gz file in your favorite
source directory and untar it.
Next, edit the Makefile:
# Edit this path to match with your system
# (it should point to the root
# directory of the Linux kernel source)
KERNEL_PATH=/usr/src/linux
Ensure that the KERNEL_PATH variable points to your kernel source
tree.
Now, run make pci and look on as HostAP builds. After a
moment that will finish and you can either run make install,
or be a purist like me and copy all the *.o files from
driver/modules/ to /lib/modules/`uname
-r`/kernel/drivers/net. In either case, your module set ought to
be these for a PCI card installation:
nebula:/usr/src/hostap-2002-10-12# ls driver/modules/*.o
driver/modules/hostap_crypt.o driver/modules/hostap.o
driver/modules/hostap_crypt_wep.o driver/modules/hostap_pci.o
Next, you'll need to edit your /etc/modules.conf (or
/etc/modutils/aliases on Debian GNU/Linux and then run
update-modules) file and add the following:
alias wlan0 hostap_pci
Lastly, run depmod -a to update your module dependancies.
The driver should produce output similar to this, when it's
loaded, in your syslog:
hostap_crypt: registered algorithm 'NULL'
hostap_pci: hostap_pci.c 0.0.0 2002-10-12
(SSH Communications Security Corp, Jouni Malinen)
hostap_pci: (c) Jouni Malinen
PCI: Found IRQ 12 for device 00:0b.0
hostap_pci: Registered netdevice wlan0
prism2_hw_init()
prism2_hw_config: initialized in 17775 iterations
wlan0: NIC: id=0x8013 v1.0.0
wlan0: PRI: id=0x15 v1.0.7
wlan0: STA: id=0x1f v1.3.5
wlan0: defaulting to host-based encryption as a workaround for
firmware bug in Host AP mode WEP
wlan0: LinkStatus=2 (Disconnected)
wlan0: Intersil Prism2.5 PCI: mem=0xe7000000, irq=12
wlan0: prism2_open
wlan0: LinkStatus=2 (Disconnected)
You might note the reference to host-based encryption. This
applies to all firmware revisions before v1.4.9 as noted above in
the firmware discussion.
Using HostAP With The Linux Wireless Extensions
The most important tool is iwconfig and its similarity
with ifconfig is telling of its purpose. You'll use
iwconfig to set your card's mode, channel, and essid. You'll
still need to set an IP address for you card using the traditional
ifconfig, though.
To get your card up and running in AP (or Master) mode, issue the
following commands:
# ifconfig wlan0 192.168.0.1
# iwconfig wlan0 essid vortex
# iwconfig wlan0 channel 1
# iwconfig wlan0 mode Master
Then, take a gander at your new software based access point:
rebecca:~# iwconfig wlan0
wlan0 IEEE 802.11-b ESSID:"vortex"
Mode:Master Frequency:2.412GHz Access Point: 00:06:25:A7:BB:DA
Bit Rate:11Mb/s Tx-Power:-11 dBm Sensitivity=1/3
Retry min limit:8 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality:0 Signal level:0 Noise level:0
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Most of the items are self explanatory. Link quality, signal, and
noise won't show up when in Master mode.
You can also use the HostAP driver in Ad-Hoc and Managed
(Infrastructure) modes, and it also excels in these modes. Here's an
example Ad-Hoc command sequence and output:
# ipconfig wlan0 192.168.1.12
# iwconfig wlan0 mode Ad-Hoc
# iwconfig wlan0 essid vortex
# iwconfig wlan0 channel 11
rebecca:~# iwconfig wlan0
wlan0 IEEE 802.11-b ESSID:"vortex"
Mode:Ad-Hoc Frequency:2.462GHz Cell: 02:06:07:E7:F7:DA
Bit Rate:11Mb/s Tx-Power:-8 dBm Sensitivity=1/3
Retry min limit:8 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality:92/92 Signal level:-40 dBm Noise level:-100 dBm
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0
Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Unfortunately, I cannot discuss setting up a wireless
distribution system (WDS) using Repeater mode because I don't have
another Prism card I can test it with. Please read the README.prism2
file, included with your hostap tarball, for detailed information
about setting up a WDS.
Enabling Basic WEP Under HostAP
Discussion of why WEP is not that secure could be the topic for
an entire article. Nevertheless, WEP is another layer of protection
and depending on your level of risk aversion you might be perfectly
happy with the level of security it provides. That said, enabling
WEP for HostAP is extremely easy and works in Ad-Hoc and Managed
mode the same way as in Master mode. Stations without the correct
WEP key will be able to associate, but not authenticate with the
base station.
The iwconfig command with the key option is the
gateway to encryption. To enable WEP, you first need to set at least
one key. You can enter a key in hexadecimal of length ten for 40-bit
WEP keys, or a key of length twenty-six with a dash after each four
hexadecimal numbers for 104-bit WEP. For example:
# iwconfig wlan0 key 1234567890
# iwconfig wlan0 key 1234-1234-5678-5678-1234-1234-99
The above will set the specified key as the new current
key. It will also enable encryption if it was previously disabled
and set the encryption mode to Restricted. Refer to the
output below with a 40-bit WEP key set (with the irrelevant portions
removed):
rebecca:# iwconfig wlan0
wlan0 IEEE 802.11-b ESSID:"vortex"
Mode:Master Frequency:2.412GHz Access Point: 00:06:25:A7:BB:DA
Encryption key:1234-5678-90 Encryption mode:restricted
If you want to add additional keys (up to a maximum of four, or
the original plus three more) without altering the current key,
prepend or append a numerical index ([4]) to the argument, like so:
# iwconfig wlan0 key [2] 1234-1234-5678-5678-1234-1234-12
If you want to change the current active key, specify only
the key's index.
# iwconfig wlan0 key [1]
Lastly, you can enter the key as an ASCII string instead by
prefixing it with "s:", as demonstrated below:
# iwconfig wlan0 key s:jasonb
40-bit WEP keys entered as strings should be five characters.
104-bit WEP keys as strings should be thirteen characters. (And when
I speak of 40-bit and 104-bit I'm referring to 64-bit and 128-bit
WEP respectively.) It's important to note that using strings
generally gives you less entropy than using hexadecimals.
# iwconfig wlan0 key off
And, the above will disable WEP entirely.
For a nice list of current WEP options, including which of the
four keys is currently being used, how many bits each key is, and
the current encryption mode, we're going to call upon iwlist.
Example output after setting four 104-bit WEP keys and selecting the
third key as the active key is the following:
rebecca:# iwlist wlan0 key
wlan0 2 key sizes : 40, 104bits
4 keys available :
[1]: 6161-6161-6161-6161-6161-6161-61 (104 bits)
[2]: 6161-6161-6161-6161-6161-6161-61 (104 bits)
[3]: 6161-6161-6161-6161-6161-6161-61 (104 bits)
[4]: 6161-6161-6161-6161-6161-6161-61 (104 bits)
Current Transmit Key: [3]
Encryption mode:restricted
If you'd like access to additional WEP keying options beyond the
scope of basic WEP, you'll want to play with the options
hostap_crypt_conf offers, which is located in the
utils/ subdirectory of your hostap directory.
Configuring Your Card To Load On Boot
Getting your card to load on start up is distribution specific.
In the interest of not spreading false information, I'm only going
to discuss setup for Debian Woody and beyond and not guess about the
correct proceedure for RedHat. (But if someone would like to
contribute, it would be educational for me and appropriate credit
would be attributed if I reproduce some of it here.)
The best place for information on getting your card up at boot is
to read the DISTRIBUTIONS.txt file which comes with the wireless
tools package. It explains setup for RH{7,8}, Debian {2.2,3}, and
others. Usage of wireless.opts is now generally depreciated on most
distributions for PC Cards. My description of Debian below does not
utilize The Debian Way of setting up a wireless card on boot. Again,
review DISTRIBUTIONS.txt for that until I update this section
accordingly.
On Debian, you will want to edit the file
/etc/network/interfaces to bring your card up on start up.
Assuming you made the appropriate entry in your
/etc/modules.conf file earlier, the following should bring
your card up at boot.
auto wlan0
iface wlan0 inet static
address 192.168.1.1
netmask 255.255.255.0
up /sbin/iwconfig wlan0 essid debian && \
/sbin/iwconfig wlan0 channel 1
The up directive will run any arguments following it. The
backslash allows commands to run beyond a single line. It's
essentially shell, and you can && and || stuff as you
please. There is also the pre-up directive, if you want the
card to have things set before the actual interface comes up.
Enabling Ethernet Bridging
You can use the Linux kernel's 802.1d Ethernet Bridging option to
perform the functions of a hardware bridge using your Linux box and
any interfaces that are currently configured on it. Bridging your
HostAP wlan0 interface with your internal wired network, say eth0,
will provide you with the same benefits (and pitfalls) as using a
store bought Wireless Access Point. Devices on both interfaces will
share the same subnet. You'll need the Linux Ethernet Bridging
Utilities (or apt-get install bridge-utils under Debian
GNU/Linux) that work with the kernel bridging functionality.
You you need to remove any existing IP addresses on your chosen
interfaces, first (assuming wlan0 is the wireless interface and eth0
is the wired interface):
ifconfig wlan0 0.0.0.0
ifconfig eth0 0.0.0.0
Then, you'll need to enable bridging, with the brctl
utility, by adding a bridged interface, br0, assigning physical
interfaces wlan0 and eth0 to it, and finally using ifconfig
to assign the new virtual bridged interface an IP address:
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 wlan0
ifconfig br0 192.168.1.1 up
Now, if you're on Debian then you're in luck, as you can easily
edit /etc/network/interfaces to load your bridged interfaces
on start up! You'll want to read
bridge-utils/README.Debian.gz for full details, but here's my
basic configuration that I've used (RedHat 7.x/8.x configuration
submissions welcome!):
auto br0
iface br0 inet static
address 192.168.1.1
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
bridge_ports wlan0 eth0
up \
/sbin/iwconfig wlan0 essid trekweb && \
/sbin/iwconfig wlan0 channel 4 && \
/sbin/iwconfig wlan0 mode Master
Now your Wired and Wireless network are bridged, as one.
Uploading A New Secondary (Station) Firmware Image
First, go back and recompile HostAP with PRISM2_DOWNLOAD_SUPPORT
by running make pci EXTRA_CFLAGS="-DPRISM2_DOWNLOAD_SUPPORT"
after doing a make clean. Optionally you can set this
directly in driver/modules/hostap_config.h, which has some
other interesting experimental options you can review, but should
save for later.
Don't forget to make install or copy the *.o files over
manually to where you put them last time and run depmod -a
again.
Next, you need to go back to your hostap source directory and
enter the utils subdirectory. Once there, if you haven't
already, type make to compile the utilities. Now, turn your
attention to the prism2_srec file, which ought to give you
this output when run:
rebecca:# ./prism2_srec
Usage: prism2_srec [-vvrfd]
Options:
-v verbose (add another for more verbosity
-r download SREC file into RAM (volatile)
-f download SREC file into flash (non-volatile)
-d dump SREC image into prism2_srec.dump
Options -r and -f cannot be used together.
If -r or -f is not specified, image summary is shown and
compatibility with WLAN card is verified without downloading
anything.
HostAP does not yet support "download SREC file into flash
(non-volatile)" (-f). You'll need to "download SREC file into RAM
(volatile)" (-r) instead, and this will be necessary each time the
card is reset.
Now, you just need a new secondary firmware image file (*.hex) to
download onto your card. I linked to them
earlier at NetGate's Web
site. The PDF files include a list of compatible hardware along
with their board IDs in hexadecimal. You can either match this up
with the information you get in your syslog when you
initialize the HostAP driver, or you can use the nifty
hostap_diag utility which you just compiled above.
rebecca:# ./hostap_diag wlan0
Host AP driver diagnostics information for 'wlan0'
NICID: id=0x8013 v1.0.0
(PRISM II (2.5) Mini-PCI (SST parallel flash))
PRIID: id=0x0015 v1.0.7
STAID: id=0x001f v1.3.5 (station firmware)
From the output above you will want to refer to the NICID hex
value to determine which HEX file is right for you. Make sure the
image you choose is stated to be a "RAM-download" Secondary
firmware.
Now, it's magic time. Running prism2_srec should get you
output like this:
rebecca:# ./prism2_srec -r wlan0 /path/to/firmware/RF010409.HEX
srec summary for RF010409.HEX
... Card Information ...
Downloading to volatile memory (RAM).
OK.
Rerunning hostap_diag should show your card using it's new
station firmware:
rebecca:# ./hostap_diag wlan0
Host AP driver diagnostics information for 'wlan0'
NICID: id=0x8013 v1.0.0
(PRISM II (2.5) Mini-PCI (SST parallel flash))
PRIID: id=0x0015 v1.0.7
STAID: id=0x001f v1.4.9 (station firmware)
This proceedure may not work for downloading new primary firmware
onto all cards, more specifically Prism2.5 chipset cards.
Very Frequently Asked Questions Regarding HostAP
Driver
Does HostAP support my ... USB wireless card?
No, HostAP has no support of any kind for your USB wireless card.
If you don't care about taking advantage of the HostAP stuff, you
can get away with using the wlan-ng driver which does support USB
Prism2 cards.
Does HostAP support my [some brand] wireless card?
Maybe. Check the compatibility section at the beginning of this
article and search the FCC's database. Maybe you'll get lucky.
How do I turn off beacon frames completely?
You can't. You can reduce their frequency (which increases
performance) by using the prism2_param script in the
utils/ directory and running it like:
prism2_param
[interface] beacon_int 1000
(where each unit is 1024 usec)
When my card initialized, I got this weird error:
CMDCODE_ACCESS_WRITE failed
If this happens after extended usage, you're probably using a
very old verison of HostAP (don't do that) which used to throw that
under odd circumstances. If this happens as soon as the driver
attempts to initialize your card, it's very likely your card does
not have a Prism2 chipset. If large version numbers are mentioned
during the initialize attempt, this is further evidence that it
isn't a Prism2 card.
I want to use four Prism cards, two local, two remote, for
improved performance. Can I do that?
Possibly. You might research these two threads. 4 cards in
full duplex mode. 4 cards for
a full duplex link... possible?. No promises.
Links and Useful Resources
Thanks and Credits
Thanks to Aaron Baer for providing RPMs for RedHat
distributions.
Thanks to Gerald Britton for helping me understand the
various firmware types that exist for Prism cards and for his
section topic suggestions.
Thanks to Jacques Caron for the heads up on LinkSys moving
the WMP11 to the BroadCom chipset and his photos of the card I
posted in another article.
Thanks to Jerritt Collord for setting me straight on WEP
keys and PLX cards.
Thanks to Michael Smith for his feedback on 40 bit WEP
keys.
Thanks to NetGate for hosting STA firmware revisions
1.3.4, 1.3.6, and 1.4.9.
Thanks to Jean Tourrilhes for pointing me to his
DISTRIBUTIONS.txt file for bringing wireless cards up on boot.
Copyright and Revision Information
10-13-02 - Initial Draft
10-16-02 - Added setup, WEP, and firmware download sections
10-18-02 - Added compatibility discussion
10-20-02 - Copied bridging discussion from wireless2 with a few
changes
10-24-02 - Made some corrections to WEP, configuration, and
bringing the card up on boot
12-08-02 - Added notice about possible problems with 2.4.20 and a
workaround; Changed link for WEv15 to point to the version for 2.4.x
series kernels. I apologize if this has caused anyone grief; Added
link to optional WEv16 for 2.4.x kernels
12-11-02 - Changed recommended kernel version to 2.4.20 since you
need not prepatch 2.4.19 up to 2.4.20-rcX anymore
12-13-02 - Added link to RedHat RPMs of a ready to go kernel with
HostAP as a module
02-14-03 - Added two new firmware revisions believed to exist;
Status known
03-30-03 - Slight update to the STA firmware list
This document is copyright (c) Jason Boxman, 2002-2003. All
rights reserved.