Linux Unwired [Electronic resources] نسخه متنی

6.2 Software

There are a number of
ways you can set up Linux on any of the hardware we discussed in the
previous section, ranging from custom-built distributions
specifically designed for a particular motherboard to simply
installing a full Linux distribution on the hard disk of your
recycled PC. We discuss several of the most common distributions that
you may want to consider.

What all of these distributions share in common is, at least, the
wireless drivers you need. As mentioned in Section 6.1.4.1, there are currently two
drivers that support the use of master mode: the HostAP and Madwifi
drivers. In addition, there are two driver options you can use with a
Hermes I (Lucent WaveLAN IEEE/Orinoco/Agere 802.11b) or Hermes II
(Agere/Proxim 802.11g) radio card to run in master mode. We cover all
four of these driver options in detail.

6.2.1 Linux Distributions

There are several available versions of Linux that are specifically
geared toward building your own Linux-powered access point. Most
of them have been under development for quite some time and are very
stable. Wireless ISPs and community network organizations use these
distributions to power their access points.

6.2.1.1 Running Linux off a CF card

One thing you will need for many of these installations is a Linux
system that can read a CF card. Don''t panic!
You don''t need a custom-built motherboard such as
the Soekris or the Via MII. You need a CF adapter, and you can find
it in three flavors:

CF-to-PC Card adapter sleeves

USB CF reader

CF-to-IDE adapter

Any of these types of units will work fine for our purposes. The USB
reader will obviously require that your Linux system be configured
properly for USB, and we don''t have the space to go
into those details here. However, most USB card readers, once
recognized, will use a device name of
/dev/sd<x> where
x=a-z. If you have other SCSI devices in your
system, the CF may not be recognized as
/dev/sda.

The CF-to-PC Card adapter sleeve is your best option if you are
working with a laptop system. You simply fit the CF card into the end
of the adapter, then insert the adapter like a regular PC Card. In
order for this to work in Linux, you must have pcmcia-cs installed or
kernel tree PCMCIA configured in your kernel. We covered both of
these in detail in Chapter 2.

If you have a desktop system, the CF-to-IDE adapter is your other
option if you don''t have a USB reader. (We discussed
these adapters in Section 6.1.3.) We suggest using this type of
adapter only if you don''t need any special drivers
loaded. As long as your system recognizes an IDE device,
you''re set. Insert the CF into the adapter when your
system is powered off, and on boot, your Linux distribution should
recognize the CF as an IDE device.

Almost all CF cards sold on the market come preformatted with the Microsoft FAT16 filesystem. Why? Because this has become the de facto filesystem that most digital cameras read. Digital cameras are the primary users of CF cards, so it makes sense for the CF manufacturers to have their media ready to play. We have encountered problems off and on with getting some makes of CF cards to reformat properly in Linux. After you fdisk the CF card and run mkfs to make a new filesystem, everything appears to run smoothly. However, when you attempt to mount the new filesystem, you receive an error similar to "FAT filesystem not supported." On some Red Hat 8 and 9 systems, we were not able to resolve this problem. On other distributions, we were able to use the cfdisk graphical partitioning utility instead of fdisk, and that resolved the issue. One other workaround was to fdisk the CF card in a Sharp Zaurus PDA.

6.2.1.2 Pebble

This distribution
was developed by Terry Schmidt of
NYCWireless.
Terry has worked very hard on this distribution, and it shows. Pebble
is designed specifically with the Soekris hardware in mind, but it
also runs quite nicely on the Stylistic and Via hardware.

The NoCat lab runs Pebble on various Pentium-era systems down to a
Pentium 75 with an ISA 3Com Ethernet card and an ISA PCMCIA adapter
for an Orinoco wireless card. According to the README, Pebble has
also been known to run on 1U servers, IBM ThinkPads, and a robot at
the Defcon hacking conference.

Terry developed this distribution specifically for the Soekris, so it
was built from the ground up to be run from a 128 MB CF memory card.
While you could strip out some functionality by removing Perl,
NoCatAuth, djbdns, and a few other utilities, and get the distro to
fit on a 32 MB CF card, it''s barely worth the effort
because you can find 128 MB CF cards for $30.

To prevent excessive writes to the CF card, Pebble is designed to
boot read-only, and it creates a RAM disk for any temporary files
that need to be written in the course of regular system operation.
This means that once the system is configured, the flash is never
written to, which will extend the life of your CF card. The other
great advantage of a read-only mounted operating system is that you
can lose power at any time, and you won''t corrupt
any data.

Pebble is based on the Debian GNU/Linux 3.0r1 release, so customizing
the installed software is easily done with the included apt
utilities. For example, the Pebble boxes on the NoCat network are
customized from the standard pebble release, so run apt-get
install sudo ntp-simple bind9 bind9-host
and apt-get remove djbdns ppp pppoe nano before
you deploy a new Pebble machine. This approach is much more flexible
than some of the other small distributions we discuss later in the
chapter. While the apt databases do take up some space, the
flexibility they offer is worth it.

Pebble is freely available at
http://www.nycwireless.net/pebble. As of this
writing, the latest version is
pebble.v39.tar.bz2. This release includes:

Linux Kernel 2.4.22 with Crypto modules

HostAP 0.1.2 and utils and hostapd

MadWiFi CVS version from 11/17/03

bridge-tools

djbdns caching dns server

elvis (tiny vi)

gnupg

iptables 1.2.6a

lilo

NoCatAuth, running as non-root user, post 0.81 nightly

ntpdate

openSSH server 3.4p1-1.woody.2 patched

openSSL 0.9.6c patched with security fixes backported by Debian

pcmcia-cs (kernel module pcmcia)

Perl 5.6.1

ISC dhcpd and dhclient

zebra 0.92a-5 (BGP, OSPF, RIP Routing Daemon)

Pebble has wireless card driver
support for many but not all wireless cards. There are drivers for
Orinoco, Cisco, Atheros (madwifi), and Prism (HostAP). It supports a
fairly wide variety of Ethernet drivers, including 3Com, Intel,
National Semiconductor (Soekris), and Via-Rhine (Via motherboards),
as well as the Tulip driver, which supports a wide range of Ethernet
cards.

We assume for the purposes of this section that you will install
Pebble on a CF card for use in a Soekris or other machine that can
boot from a CF. This shouldn''t keep you from loading
it on other media. It works well from a hard disk, and you can simply
substitute a mounted IDE hard disk for the CF card in the following
instructions.

As Terry mentions in the README, there are many types of CF cards. He
has had problems with Kingston flash cards and recommends
SanDisk CF cards. We concur, having had
a few flash cards ourselves that simply would not boot properly.
Pebble fits nicely on a 128 MB flash. We don''t
recommend anything smaller unless you plan to trim packages, and we
don''t cover that here. See Section 6.2.1.1.

Once the CF card is in your system and is successfully recognized,
there are several steps to obtaining a working Pebble distribution on
the CF. Terry has greatly improved this process over time, and the
latest versions of Pebble have an installation script that takes care
of most of the heavy lifting for you.

Here''s what you must do as root. These examples
assume that your CF card is recognized as
/dev/hde. This is the case on a
typical system with a single IDE hard
disk and an IDE CD-ROM. Consult dmesg to make sure
you know which device your CF card is using.

Use fdisk to create one large partition. You don''t
need swap, because Pebble mounts read-only and writes everything
entirely to RAM.

# fdisk /dev/hde

Next, use mkfs.ext2 to create an ext2 filesystem. You
don''t need or want a journaling filesystem such as
ext3 or jfs. Again, Pebble mounts read-only, so the journal uses up
space that you could use:

# mkfs.ext2 /dev/hde1

Create a mount point for the CF card (you don''t need
to mount it, because the pebble.update script,
which you''ll run later, takes care of this for you):

# mkdir /mnt/cf

Make a directory to untar the Pebble distro so the install script can
work:

# mkdir /mnt/pebble
# cd /mnt/pebble

Uncompress and untar the Pebble distro to the directory that you have
just created (the actual version number may be different):

# tar jxvf /path/to/pebble.
v39.tar.bz2

If you want to do manual configuration of your
Pebble install before invoking
the installation scrip, there is an opportunity here for editing
filest. For instance, if you want to configure dhcpd or any of the
other daemons that run at startup, this is a good time to do so. In
particular, you should consider editing
etc/network/interfaces to define TCP/IP for
eth0, and also editing
etc/pcmcia/network.opts and
etc/pcmcia/wireless.opts to configure your radio
cards. This way, you can bring up a working system from the get-go.

We also recommend editing etc/inittab. Terry
runs the NoCatAuth captive portal from
inittab to make sure that it always respawns if
it dies unexpectedly. This is fine, but until you have a completely
configured Pebble system with all of its network interfaces active,
you will receive garbage on the console while NoCatAuth tries to
start, fails, and respawns. The last line of
etc/inittab reads:

NC:23:respawn:start-stop-daemon -S -c nocat -exec /usr/local/nocat/bin/
gateway -- -F

Comment this line out by placing a # at the
beginning of the line. Then you can run:

# ./pebble.update

This is the installation script. It''s interactive,
so you must answer a few questions before it can start.

 Where is the pebble installer (this) directory? default=/mnt/pebble:
Which device accesses the compact flash? default=/dev/hde:
Which directory should I mount the FlashCard to? devfault=/mnt/cf:
Which module? Enter 1 for pcmcia, 2 for net4501, or 3 for net4521/net4511 default=net4501

You should know the answers to the first three questions, because
we''ve discussed them in the previous steps. The last
question is critical, because the answer affects which modules load
in the Pebble installation you create, as well as other startup
operations.

If you''re setting up a Soekris system,
the answers are obvious for any other system that uses a PC Card
radio, you must choose option #1. If you have a PCI or a MiniPCI
radio card, none of these options will completely suit you. Choose #1
and make some configuration changes later.

Once you have the questions answered, the installer script goes to
work, making changes to the configuration files depending on how you
answered the last question. Once done, it copies the modified
distribution from /mnt/pebble to the mounted CF
card at /mnt/cf.

After copying, it performs ssh key generation for the sshd keys, so
that there are no duplicate Pebble ssh keys running in the world, and
finally, it makes you change the root password. Once done, it
unmounts the CF card, and you are ready to insert the CF card into
your chosen access point hardware.

If you have a Soekris system, this is the point where
you''ll want to hook up a serial cable to a PC and
run some terminal software at 9600 8-N-1, so you can see the console
as Pebble boots. If you made configuration changes prior to running
the installation script, this is doubly important so you can make
sure things start like you expect. If you''re on a PC
system with video output, hook up a monitor.

At this point, you should have a working Pebble access point. If you
happen to have a Prism-based card in your system, it should come up
in master mode and appear as an access point with an SSID of
"Freenetworks." Later in this
section, we cover some specifics on configuration of the HostAP
driver that makes this setup possible.

There are two places to get help with Pebble. First, read completely
through the README, available at http://www.nycwireless.net/pebble/pebble.README.
If you can''t resolve your issue with the help of the
README, subscribe to the
Pebble mailing list at http://freenetworks.org/mailman/listinfo/pebble-linux.
The list is active and full of knowledgeable readers who should be
able to provide you assistance.

6.2.1.3 LEAF/WISP-Dist

LEAF stands for the Linux Embedded Appliance
Firewall. Rather
than being a single distribution, LEAF has actually become a
clearinghouse of sorts for a number of related distributions, all of
which are available from the LEAF pages: http://leaf.sourceforge.net.

Most of the LEAF distributions are children of the
Linux Router Project (LRP), which was
designed as a single-floppy bootable Linux-based router. As the
project matured, spin-offs developed that included newer kernel
support, among other things. LEAF is now the parent organization for
six active distributions and some inactive ones.

At one time, Wireless ISP
Distribution (WISP-Dist) was an independent distribution, but
recently it has moved under the support of LEAF. For the purposes of
building a custom access point, WISP-Dist is the only LEAF
distribution we cover.

WISP-Dist is a modular embedded Linux distribution for wireless
routers but can be used for other purposes as well. The entire system
fits in 8 MB flash/16 MB RAM, making it much smaller than Pebble. The
stated goal of the project is "to create an open,
customizable, and easy to use embedded router for ISP
needs."

As of this writing, the current version of WISP-Dist is 2624, but it
is referred to in the documentation as WISP-2003, because it was the only
release in that year. Current features include:

Linux kernel 2.4

Simple to use menu-based configuration system for basic functionality

Command-line access for advanced configuration

The ability upgrade remotely via automatic script

Modularity: you can add/remove packages

Local access via console or serial port

Remote access via sshd

Statistics available via SNMP, including wireless statistics

Layer 3 bridging support based on proxy ARP

OSPF, RIPv2 dynamic routing support integrated with Zebra routing
engine

NAT (with H.323, PPTP pass-through support)

Bandwidth shaping

PPP

PPPoE client

VTUN for encrypted PtP

VLAN trunking

Access point support for Prism2/2.5/3/Atheros

MAC filter support for access point

Advanced network diagnostics: NTOP, tcpdump, bmon, etc.

The ability to log all system events to remote system with syslog

checkping: system reboots if some of the specified hosts are
unreachable (useful when radios get stuck)

The ability to store all files, which makes it easy to service on
standard FAT partition.

While WISP-Dist is very small, it runs on pretty much any
x86-compatible CPU. The developers recommend at least a 100 MHz
processor in addition to the minimum of 8 MB of disk space and 16 MB
of RAM. WISP-Dist has been tested on the Soekris hardware as well as
several single-board computers designed for the ISP market. It
includes drivers for Cisco, Orinoco, Atheros, and Prism-based cards.
There are two types of wireless cards that it does not support: cards
based on the Texas Instruments chipset (such as the D-Link
DWL-520/650+) and USB wireless adapters.

As with Pebble, WISP-Dist is designed to be installed on a
CF card. The size requirements are much
smaller, howeveryou can run WISP-Dist on as little as 8 MB of
flash. You do need a system that can read CF cards. See Section 6.2.1.1, earlier in this section.

The WISP-Dist
installation is nowhere near the simplicity of the Pebble
installation script. The distribution is provided in two different
types:

Partitionless installation from a .bin or .img file

Once you have downloaded the
wisp-dist_2624_img_wdist.bin file (or a newer
version) and have a CF card inserted in your reader, you must use the
dd command to copy the image to the CF card.
dd makes a block-by-block copy of the image, so
you don''t need to partition the CF. This invocation
assumes your CF card is on /dev/hde:

$ dd if=wisp-dist_ 2624
_img_wdist.bin of=/dev/ hde

Partition-based installation from package distribution .zip file

You must manually partition the CF card using the fdisk command. The
first partition that you create should be at least 6800 Kb in size,
and you should set this partition to Active. You
should also specify the partition type as FAT. The
second partition should be at least 1,300 Kb in size. If you have
more than 16 MB RAM in your system, you can skip the creation of the
second partition, as WISP-Dist will create a RAMdisk on boot to use
instead of a second partition, similar to Pebble''s
operation.

Next, create the filesystem on the first partition:

# mkfs.msdos /dev/ hde1

Now obtain the SYSLINUX bootloader from http://syslinux.zytor.com, and install it on
the first partition. SYSLINUX can also be installed in Debian using
apt-get. Mandrake and Red Hat/Fedora users can install an RPM.
SYSLINUX is designed to boot Linux from a FAT filesystem. Once you
have the SYSLINUX binary on your system, execute this command:

# syslinux /dev/ hde1

This creates a boot sector on the disk and copies a file named
LDLINUX.SYS into the root directory.

Next, you should mount the CF card, unzip the
wisp-dist_2624_pkg_wdist.zip file (or a newer
version that matches the version of the .bin
file) into a temporary directory, and copy files from the temporary
directory to the root of the CF card:

# mount -t vfat /dev/ hde1 /mnt/cf
# cd wisp-dist
# cp -a * /mnt/cf

Lastly, edit the syslinux.cfg file. If you did
create the second partition in the first step, you must add the
statement rwfs=/dev/hda2. This assumes that on
your target system, the CF card is the IDE primary master
/dev/hda. If your system is booting from a
different device, you must also change any occurrence of
boot=/dev/hdaX in the
syslinux.cfg file to the appropriate device.

At this point, you should be able to unmount
/dev/<hde> (or whatever device your CF is
on) from your system, eject the CF card, and place it in the system
that will be running WISP-Dist. As with Pebble, it''s
a good idea to connect a serial console or monitor to the system to
watch the initial boot.

WISP-Dist should appear with a default configuration that has no root
password, the eth0 Ethernet interface at
192.168.1.1 with a 255.255.255.0 netmask, and a serial console on
ttyS0 at 9600 8N1. When you log in as root, you are immediately
presented with a menu, as shown in Figure 6-8.

Figure 6-8. WISP-Dist Configuration menu

The WISP-Dist configuration system is straightforward and easy to set
up. If you want a command line for advanced configuration, you can
choose Quit from the menu and you will be presented with the root
command line.

If you need help with WISP-Dist, you should first read through the
User Guide, which is located at
http://leaf.sourceforge.net/devel/hzdrus/doc/html.
For some reason, there is no WISP-Dist topic in the LEAF FAQs at
SourceForge, so the next place you should check is the leaf-user
mailing list. You can search the archives at http://www.mail-archive.com/leaf-user%40lists.sourceforge.net
or subscribe to the list at http://lists.sourceforge.net/lists/listinfo/leaf-user.

6.2.1.4 LinuxAP

The LinuxAP
distribution began life as an upgrade to the OpenAP code, which was
developed to run on certain access point hardware. See Section 6.3.4 later in this
chapter for details.

As of this writing, the current version of LinuxAP is based on the
2.4.20 kernel, and it supports both the Eumitcom WL11000 motherboards
that power some access points, as well as the Soekris hardware
platform. The LinuxAP web pages are at http://linuxap.ksmith.com, and as of this
writing, the most current version of the LinuxAP source is
linuxAP-2003-09-13.tar.bz2.

Installation and compilation of LinuxAP is somewhat modular in that
you can choose up front which daemons and utilities you want to
include with your compiled kernel. In addition to the LinuxAP source,
you can download additional compressed files from the LinuxAP web
site, including:

Kernel 2.4.20

Bridge utilities

BusyBox shell/network utilities

C-Kermit

CRAMFS filesystem utilities

CIPE tunnel driver and utilities

HostAP driver

IP tables firewall

pcmcia-cs

Tiny login

Uclibc compact C library

uDHCP client/server

UMSDOS enhanced FAT filesystem

Wireless tools

As with the previous two distributions, in order to get LinuxAP
loaded on a CF card for use in a Soekris unit, you need a CF card
reader. See Section 6.2.1.1 earlier in
this section.

First, uncompress the LinuxAP distribution. The developer recommends
that you place the compressed file in /usr/src
so that your code tree resides in
/usr/src/linuxAP. You must replace
2004-09-13 with whatever version of
LinuxAP you downloaded:

# cd /usr/src
# tar xjvf linuxAP- 2004-09-13 -tar.bz2
# cd linuxAP

Next, make a directory for the utilities that you selected and
downloaded:

# mkdir tarfiles

Uncompress each source file for the utilities, but leave the
.tar file intact, and copy the
.tar files into the newly created directory:

# cd /usr/src
# bunzip2 linux- 2.4.20 .tar.bz2
# cp linux- 2.4.20 .tar linuxAP/tarfiles

Now, run make, which allows you to select the type of hardware,
Eumitcom or Soekris, and also the utilities you want to include:

# cd linuxAP
# make

Once the compile is completed, in the linuxAP
directory you will have two created files:
kernel and ramdisk. At this
point, prepare your target disk and install SYSLINUX. (See the Section 6.2.1.3 earlier in the
chapter for details on where to obtain SYSLINUX.) Set up the first
partition as 8 MB, set it as Active, and make it a
FAT16 partition. Make a new MSDOS partition, and then install
SYSLINUX. If your CF card is on a different device,
replace /dev/hde with the appropriate
device.

# fdisk /dev/ hde
# mkfs.msdos /dev/ hde1
# syslinux /dev/ hde1

The last step is to mount your newly formatted CF card and copy the
compiled kernel, ramdisk,
and the syslinux.cfg files over:

# mount -t vfat /dev/ hde1  /mnt/cf 
# cd /usr/src/linuxAP 
# cp syslinux.cfg ramdisk /mnt/cf 
# cp kernel /mnt/cf/linux 
# umount /mnt/cf 

Once again, you can now remove the CF card, insert it in your Soekris
hardware, and boot it up with a serial cable attached to observe the
initial boot.

For help with LinuxAP, refer to the LinuxAP-dev mailing list, hosted
at http://linuxap.ksmith.com/mailman/listinfo/linuxap-dev.
There is an active development and user community who should be able
to provide you with advanced assistance.

6.2.1.5 Other distributions

As of this writing, Pebble and WISP-Dist are the two most
full-featured distributions specifically aimed to make a small-board
computer into an access point. There are some other distributions you
may want to investigate:

Sydney Wireless HostAP CD

The wireless folks down under have produced this ISO CDROM image of a
Linux bootable CDROM installer. This is not just
a bootable CDROM; it will fdisk and format a hard disk or device that
you choose and install a custom version of Debian Linux. The
distribution features support for PCI and PCMCIA Prism cards using
the HostAP driver, has support for a wide variety of Ethernet cards,
does advanced routing with the Zebra routing engine, and has IPv6
capabilities.

The installed distribution takes up approximately 43 MB, so you can
consider this as another alternative operating system to try on your
CF card. The CD can be downloaded from http://www.sydneywireless.org/?Projects.

LocustWorld MeshAP

MeshAP is a unique distribution in many respects. Jon Anderson, in
the UK, created MeshAP and has added some interesting features.
First, MeshAP is designed from the ground up to actually build mesh
networks using the Ad-hoc On-demand Distance Vector (AODV) routing
protocol. AODV builds routes between nodes on demand, as desired by
those nodes. You can get detailed information on AODV at http://moment.cs.ucsb.edu/AODV/aodvl.

Second, as part of the MeshAP project, Jon created the
Wireless Internet Assigned Numbers
Authority (WIANA), found at http://www.wiana.org. This is slightly
controversial, as WIANA will assign you a 1.x.x.x IPv4 address for
the wireless mesh portion of your MeshAP. WIANA certainly is not the
first organization to assign unused IPv4 address space to wireless
networks; the folks at http://freenetworks.org have done the same
with the 10.x.x.x address space. Both of these assignments are really
hacks on the existing infrastructure, until IPv6 is actually
implemented on a larger basis.

MeshAP is provided in a similar format to the Sydney Wireless CD, in
that you download an ISO CDROM image, burn that image to CD, and boot
from the CD. The installation process lets you select a device for
installation, and it then partitions and formats the destination
device and installs a MeshAP distribution. Once you have MeshAP
installed, you must register at http://www.wiana.org to receive a 1.x.x.x
address for your Mesh.

You can get documentation for MeshAP from the
LocustWorld
Wiki at http://www.locustworld.com/tracker/wiki?p=WikiIndex.
There is also a MeshAP User mailing list. To subscribe, send an empty
email message to

6.2.2 HostAP

In Chapter 2, we covered in detail
the compilation and installation of the HostAP driver, so all the
examples from this point on assume that you have compiled and
installed HostAP (if necessarysome distributions include it),
and then configured the HostAP driver for your Prism-based radio
card. Also, we assume that the driver works with your card in managed
mode.

As we''ve explained previously, the HostAP driver
performs the 802.11 management functions that would normally be
performed in an access point by either tertiary firmware in a radio
card or dedicated additional hardware.

Setting up HostAP to function this way is a simple matter of changing
the card to master mode. You can do this through the iwconfig tool
(replace MyAP with the name you want to
use for your access point):

# iwconfig  wlan0 essid  myAP mode master

To bring up the HostAP driver in master mode during startup, modify
/etc/pcmcia/wireless.opts. Here is an example
(you can change the ESSID and CHANNEL settings):

# wireless.opts
case "$ADDRESS" in
*,*,*,*)
INFO="Prism card in Master mode"
ESSID="myAP"
MODE="Master"
CHANNEL="11"
RATE="Auto"
;;
esac

Chapter 2 also discussed the address-matching
syntax used in the wireless.opts and
network.opts files. This syntax is:

scheme, socket, instance, MAC address

You can use this syntax in many different ways.
Schemes are mostly useful for client-based
laptops, where you need to switch between different wireless settings
for home and work. instance is supposed to be used
for network cards that have multiple interfaces.
We''ve never found a wireless card that uses this
parameter.

However, for an access point, it can be extremely useful to specify
which slot should only hold the access point radio card:

*,0,*.*)

This syntax would ensure that only a card in PCMCIA socket 0 would be
given the master mode configuration. It would
even be more useful to add a wildcard MAC address match:

*,0,*,00:02:6F:*)

Now, any card that is inserted in slot 0 and is a Senao/EnGenius
Prism-based card is given the master mode
configuration, and allowed to act as the access point card. If
you''re spending a lot of time futzing around with
your radio card configuration, this is one way to make sure that you
know what to expect when you plug in a certain card.

Some machines, including the Stylistic and Soekris, have problems loading the HostAP driver with high-power 100 mW and 200 mW Prism-based radio cards. The card is detected on insert but fails to initialize, and it reports an obscure error: "GetNextTuple: No more items." If you have this problem, add this line to /etc/pcmcia/hostap_cs.conf: module "hostap_cs" opts "ignore_cis_vcc=1" The driver attempts to verify that one entry on the card''s acceptable voltage table matches the voltage reported by your PC Card slot. In some cases, this voltage can be reported incorrectly, causing the driver to fail. This option causes the driver to ignore the reported voltage and load anyway.

If you have a PCI or MiniPCI Prism card, configuration is not handled
via the pcmcia-cs configuration scripts, but is handled like any
other Ethernet interface. On Debian systems, you can add an
up iwconfig line to the TCP/IP definition for the
radio card in /etc/network/interfaces:

iface wlan0 inet static
address 192.168.1.1
netmask 255.255.255.0
broadcast 192.168.1.255
up iwconfig wlan0 essid myAP mode master channel 11 rate auto

On Mandrake, RedHat, and Fedora systems, you can add radio
configuration for PC Card, PCI, and MiniPCI Wi-Fi adapters in
/etc/sysconfig/network-scripts. This is a sample
ifcfg-wlan0 script:

DEVICE=wlan0
BOOTPROTO=static
ADDRESS=192.168.1.1
NETMASK=255.255.255.0
BROADCAST=192.168.1.255
ONBOOT=yes
MODE=Master
ESSID=myAP
CHANNEL=11
RATE=AUTO

Once you have your card configured for master
mode, you can now treat wlan0 as any other
Ethernet interface. Assign IP addresses, set up routing, and bind
processes to the interface as needed. HostAP takes care of all the
details of managing wireless clients attached to your access point.

6.2.2.1 Bridging

In the previous examples, your Prism card on
wlan0 has its own IP address. This requires you
to set up routing on your Linux system. While this really
isn''t a problem, there may be situations where you
don''t want routing, but rather want to bridge all
wireless traffic across to your wired Ethernet port.

Later in this chapter, we discuss setting up Wireless Distribution
System (WDS), which bridges HostAP and a Linksys access point. In
order to set up bridging or WDS, we needed to install the
bridge-utils package. On our Mandrake 9.2
system, this was installed using the command urpmi
bridge-utils; Red Hat and Fedora users should be able to
similarly use the rpm installation, and Debian users can do
apt-get install bridge-utils.
You can also obtain the source code from http://bridge.sourceforge.net. You must also
make sure that your kernel has support for 802.1d Ethernet bridging.
On the factory kernels from Mandrake and Fedora, this was enabled by
default, but for RedHat and Debian systems, we needed to compile this
option into the kernel ourselves.

To bridge your Prism card running in master mode
with your first Ethernet card, use the following, preferably from the
console of your access point (if you try to mess with networking
while you are connected via ssh, things will probably become weird):

ifconfig eth0 0.0.0.0
ifconfig wlan0 0.0.0.0
brctl addbr br0
brctl addif br0 eth0
brctl addif br0 wlan0
ifconfig br0 192.168.1.2
route add default gw 192.168.1.1

As we report in the WDS section later in this chapter, it can take up
to 30 seconds for the bridge to come up and began passing TCP/IP
traffic. Don''t be alarmed if you
can''t ping across the bridge from your client
immediately after pressing Enter on the last command.

If you have only one bridge on your network, you can safely turn off
the Spanning Tree protocol with:

brctl stp br0 off

This prevents the bridging code from needlessly sending 802.1d
traffic to other nonexistent bridges. You can see the configuration
of your bridge at any time by using brctl show:

# brctl show
bridge name    bridge id            STP enabled    interfaces
br0            8000.00026f15423F    no             eth0
wlan0

Bridges tend to be "set and forget"
devices (although you must run the commands shown in this section
after each reboot, so you may want to put them in a startup script).
Once configured, your bridge maintains itself, barring a huge amount
of traffic. Be sure to read the documentation available at
http://bridge.sourceforge.net as
well as the documents listed at the end of this section.

Keep in mind that although a bridge is simple to configure, it
isn''t very secure. You don''t have
any control over the packets that flow across your bridge. To use a
bit of cliché, you may want to consider enacting a toll on
your bridge by implementing some firewalling. Unfortunately, standard
iptables firewall commands don''t work with bridging
in the 2.4 kernels. Rob Flickenger has detailed how to bridge with a
firewall in his excellent book, Wireless Hacks
(O''Reilly).

For more information, please consult the following sources:

The Linux Bridge STP HOWTO (http://www.linux.org/docs/ldp/howto/BRIDGE-STP-HOWTO)

The Linux Bridge and Firewall mini HOWTO (http://www.tldp.org/HOWTO/mini/Bridge+Firewalll)

Wireless Hacks, by Rob Flickenger
(O''Reilly)

6.2.2.2 MAC address filtering

We touched briefly on this subject in Chapter 4. MAC filtering does not offer much
security, because a person running Kismet can easily sit in range of
your access point, capture a number of frames, and quickly deduce at
least one MAC address that is allowed to associate with your access
point. It is pretty trivial under Linux to spoof a MAC address,
allowing an attacker to join your wireless network. You should
combine MAC filtering with WEP and implement a captive portal with
authentication to provide a reasonable measure of security.

While the filtering of MAC addresses is certainly not the best
security measure for your wireless network, it does at least provide
the first layer of defense. Filtering MAC addresses not only blocks
traffic that is not destined for your network, but also attempts to
prevent other users from associating with your access point.

When using MAC filtering, make a list of wireless devices that you
wish to allow, and then deny all others. With the HostAP driver, this
is done using the iwpriv command:

# iwpriv wlan0 addmac 00:01:02:03:04:05
# iwpriv wlan0 addmac 05:06:07:08:AA:BB

This adds MAC addresses to an internal table maintained by HostAP.
You can add as many addresses to the table as you like, one on each
line, and then tell HostAP what to do with the table
you''ve built:

# iwpriv wlan0 maccmd 1
# iwpriv wlan0 maccmd 4

The maccmd 1 tells HostAP to use the table as an
allowed list and deny all other MAC addresses
from associating. The maccmd 4 disconnects all
associated clients, forcing them to reassociate. At this point, only
clients in the table are allowed to reassociate with your access
point.

Sometimes, you may only need to ban a troublemaker or two, rather
than set up a list of permitted devices. Again, you would use the
iwpriv command:

# iwpriv wlan0 addmac 01:10:20:02:30:03
# iwpriv wlan0 maccmd 2
# iwpriv wlan0 kickmac 01:10:20:02:30:03

As before, you can use addmac to add as many
addresses to the table as you need. The maccmd 2
sets the policy for the new table to deny, and
kickmac boots the specific MAC immediately from
the access point. This is nicer than booting everybody and making
them reassociate.

To disable MAC filtering, enter this command:

# iwpriv wlan0 maccmd 0

If you make a mistake typing in a MAC address, you can use the
delmac command just as you would
addmac. Should you ever need to flush the current
MAC table entirely but keep a defined policy in place, issue:

# iwpriv wlan0 maccmd 3

Finally, you can view the current MAC table in
/proc:

# cat /proc/net/hostap/wlan0/ap_control

While iwpriv manipulates the running HostAP
driver, it doesn''t preserve settings across reboots.
Once you''re happy with your MAC filtering tables and
policies, make sure you put the necessary commands in an
rc script to run at boot.

6.2.3 Madwifi

Unfortunately, the Madwifi
driver does not have nearly all of the bells and whistles of HostAP.
However, if you want a Linux-based 802.11a or 802.11g access point,
this driver is really your only working option as of this writing.

Again, we covered the installation and compilation of the Madwifi
driver in Chapter 2. We assume that you are
able to use the driver in managed mode.

The Madwifi driver, like HostAP, performs the 802.11 management
functions that normally are performed in an access point by either
tertiary firmware in a radio card or dedicated additional hardware.

Setting up Madwifi to function this way is a simple matter of
changing the card to master mode. You can do
this through the iwconfig tool (you can change
myAP to whatever you prefer for the SSID):

# iwconfig ath0 essid myAP mode master

To bring up the Madwifi driver in master mode
during startup, you can modify
/etc/pcmcia/wireless.opts. Here is an example
(you can replace ESSID and
CHANNEL with your own settings):

# wireless.opts
case "$ADDRESS" in
*,*,*,*)
INFO="Atheros card in Master mode"
ESSID="myAP"
MODE="Master"
CHANNEL="11"
RATE="Auto"
;;
esac

The Atheros cards are all CardBus adapters, so they are treated as
hotplug devices, and configuration can also be handled like any other
Ethernet interface. On Debian systems, you can add an up
iwconfig line to the TCP/IP definition for the radio card
in /etc/network/interfaces:

iface ath0 inet static
address 192.168.1.1
netmask 255.255.255.0
broadcast 192.168.1.255
up iwconfig wlan0 essid myAP mode master channel 11 rate auto

On Mandrake, RedHat, and Fedora systems, you can add radio
configuration for PC Card, PCI, and MiniPCI Wi-Fi adapters in
/etc/sysconfig/network-scripts. This is a sample
ifcfg-ath0 script:

DEVICE=ath0
BOOTPROTO=static
ADDRESS=192.168.1.1
NETMASK=255.255.255.0
BROADCAST=192.168.1.255
ONBOOT=yes
MODE=Master
ESSID=myAP
CHANNEL=11
RATE=AUTO

Once you have your card configured for master
mode, you can treat ath0 as any other Ethernet
interface. Assign IP addresses, set up routing, and bind processes to
the interface as needed. Madwifi takes care of all the details of
managing wireless clients attached to your access point.

The Madwifi driver at this time does not support MAC address
filtering, but you can set up bridging using an Atheros card. (See
the Section 6.2.2.1 previously
in this chapter where we discussed setting up a bridge with HostAP
and a Prism card.) To set up a bridge with your Atheros card, simply
substitute ath0 for wlan0
in the bridge setup.

6.2.4 Hermes AP

Hermes-based radio cards (the tremendously popular but
confusingly named Lucent/Orinoco/Avaya/Proxim silver and gold cards)
are notoriously difficult to operate as an access point. By design,
the cards themselves are actually not able to provide 802.11 BSS
master services on their own. You might find this surprising, because
they are the radio cards embedded in the original AirPort AP, as well
as the RG1000, RG1100, AP1000, and many others.

Before these cards can operate as a BSS master, they need additional
firmware uploaded to the card. Orinoco and many other cards
originally based on the Prism designs can actually host three
firmware images: primary or operating firmware; station or client
firmware; and tertiary firmware. This tertiary
firmware is uploaded to the card''s RAM
and lost if the card loses power. To make matters even more
difficult, the firmware in question is licensed software and
can''t legally be distributed by anyone but the
manufacturer.

The ingenious Hermes AP project (http://hunz.org/hermesapl) addresses both
of these tricky issues. It consists of a set of modified drivers, a
utility for uploading the tertiary firmware, and a simple script that
downloads the firmware from Proxim''s public FTP
server. Running Hermes AP successfully is not trivial, but it can be
the perfect piece of software if you absolutely need a host-based
Orinoco AP.

To get Hermes AP running, you need a kernel with Dev FS enabled. This
allows the kernel to manage the /dev directory,
dynamically creating device files for every physical device that the
kernel supports. Run a make menuconfig
or make xconfig, and select Code
maturity level options Prompt for development and/or
incomplete code/drivers. Now go back to the main menu, and under File
systems enable /dev file system support, as well as Automatically
mount at boot. When running Dev FS, it''s also a good
idea to disable /dev/pts filesystem support, as Dev FS automatically
manages your ptys for you.

Before you recompile your kernel, copy all of the source code under
the drivers/ directory from Hermes AP over top
of the existing drivers in the kernel (right over the files in
linux/drivers/net/wireless/). Now build your
kernel and modules as you normally would, and reboot.

Your Orinoco card should come up as normal with the new driver, but
it won''t support BSS master mode yet. First,
cd to the Hermes AP source directory. To download
a copy of the tertiary firmware from Proxim''s site,
run the hfwget.sh script in the
firmware/ directory. Next, build the
hfwload utility by running make in the
hfw/ directory. This utility uploads the
tertiary firmware to your card. Copy the utility and the card
firmware somewhere handy (we keep ours in
/usr/local/hermesap), and run a command like
this at boot time, before the interface comes up, replacing
eth1 with the actual interface name and
FIRMWARE with the firmware filename (such
as T1085800.hfw):

# cd /usr/local/hermesap; ./hfwload eth1 FIRMWARE

Note that the card must not be configured up when you load the
firmware; if it is already up, an ifconfig
eth1 down brings it
down for you. If all goes well, an iwconfig should
show that eth1 is in master mode! You can now configure the radio
with an ESSID, WEP keys, and any other features as you normally
would.

Hermes AP is still beta software, but it seems to run quite well. For
situations where you don''t have the option of using
HostAP and a Prism-based card, Hermes AP is a good alternative
solution.

6.2.5 Agere Wlags49

Linux drivers for the Hermes cards have unfortunately hit a
stopping point with the recent acquisition of the Orinoco line by
Proxim. If you look for any information about Linux support on the
Proxim web site, you will find that the latest Proxim-provided driver
for Hermes-based cards is 6.20 from May 2002.

An interesting twist to this storyline is that Agere, who was
originally spun off from Lucent and also produced Hermes-based radio
cards, has updated drivers available on its web site dating from
September 2003. If you browse to http://www.agere.com/support/drivers, you
will find the Linux LKM Wireless Driver Source Code, Version 7.14
listed, which you can download from http://www.agere.com/support/drivers/wl_lkm_714_release.tar.gz.

If you dig into the README, you will find that this is a major update
of the previously provided wavelan2_cs driver. It has been renamed
wlags49, for reasons that are not clear. What is clear, however, is
that the driver provides support for not only the classic Hermes I
chipset that powers Orinoco Gold/Silver cards, but the Hermes II
chipset that is found in newer 802.11b PC Cards, MiniPCI, and CF
adapters from Agere and Proxim.

Even more interesting is the list of new features in the release:

Began updating the Wireless Extensions

Added support for access point (AP) mode

Added support for tertiary firmware downloads

Added support for WDS in AP mode

The requirement for the driver is a 2.4.x kernel. The README does say
that this driver should compile under architectures other than x86,
but that has not been verified. You''ll also need a
working gcc compiler environment. If you have been able to compile
kernels, pcmcia-cs, and the HostAP driver to this point, compiling
this driver will not be a problem.

If you already have the standard orinoco_cs or a compiled HostAP driver on your system, be warned: wlags49 does not play nice with these drivers. Once compiled and loaded as a module, wlags49 will be the default driver for any Hermes or Prism-based card in your system. We recommend you use only wlags49 on a system where you are not going to use the orinoco_cs or HostAP drivers.

Getting the driver to compile is rather
tricky. In order to configure the source code for compilation, you
must first obtain the pcmcia-cs source code. In Chapter 2, we covered in detail how to compile and
install pcmcia-cs. In brief, you can obtain the source code from
http://pcmcia-cs.sourceforge.net.

You''ll want to unpack the pcmcia-cs source
somewhere. (On our Mandrake 9.2 system, we put the source in
/usr/src/pcmcia-cs-3.2.7.) Once you have done
that, copy the gzipped Agere source into the
pcmcia-cs directory and extract it:

# cp /root/download/wl_lkm_ 714 _release.tar.gz pcmcia-cs-3.2.7 
# cd pcmcia-cs- 3.2.7 
# tar xzvf wl_lkm_ 714 _release.tar.gz 

To configure the source for the driver, run
./Configure. This will look familiar to you if you
have already compiled pcmcia-cs, because the
Configure script is part of the pcmcia-cs
release. You must configure the wlags49 source this way, even if you
have kernel tree PCMCIA enabled.

You don''t have to completely reinstall pcmcia-cs
once the configuration is completed. To install the wlags49 default
driver, which supports Hermes I and II cards in both
STA (station adapter or managed) mode and AP
mode, run the scripts that came with the wlags49 source:

./Build
./Install

Once installed, you must stop and restart the pcmcia-cs subsystem,
unless you have a MiniPCI Hermes II card, in which case you may want
to simply reboot.

The wlags49 source also gives you the option of building a driver
that supports either Hermes I or II in STA or
AP mode only. Instead of the
./Build command, you can issue one of the
following commands before ./Install:

# make -f wlags49.mk h1_cs_sta     # Hermes I, STA mode
# make -f wlags49.mk h1_cs_ap      # Hermes I, AP mode
# make -f wlags49.mk h2_cs_sta     # Hermes II, STA mode
# make -f wlags49.mk h2_cs_ap      # Hermes II, AP mode

If you only wish to build the driver to support a PCI/MiniPCI card in
either STA or AP modes, you
can issue these commands:

# make -f wlags49.mk pci
# make -f wlags49.mk pci_install

Once the driver is loaded, you have the option of
configuring wireless parameters in
three different ways. The documentation seems to suggest that you
should perform all wireless configuration in the
/etc/pcmcia/config.opts file. This is rather
nonstandard, and we did not even attempt to go down this road.

The documentation goes on to say that you can also configure the
driver using a file in /etc/agere/iwconfig-eth1.
This directory was not created as part of the installation, so we
also did not attempt to use this method. We did not have a Hermes II
MiniPCI card to test with, but we suspect that this second method is
the one that you would need to use.

Fortunately, the third method is to simply use the pcmcia-cs standard
configuration by configuring the card in
/etc/pcmcia/wireless.opts and
/etc/pcmcia/network.opts. The
wlags49 driver takes advantage of the Wireless
Tools, so that setting up our Orinoco Silver card as an access point
is just like using HostAP:

# iwconfig eth1 essid myAP mode Master

As with Madwifi, the wlags49 driver does not
support MAC address filtering. We were able to set up a bridge using
the Orinoco Silver card in master mode, using
the example provided previously in the HostAP section of this
chapter.