6.2 Software
| < Day Day Up > |
| 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 DistributionsThere 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 cardOne 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:
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.
6.2.1.2 PebbleThis 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:
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.
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-DistLEAF 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:
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, however ”you 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:
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 LinuxAPThe 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:
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.
6.2.1.5 Other distributionsAs 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:
6.2.2 HostAPIn 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 necessary ”some 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.
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 BridgingIn 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:
6.2.2.2 MAC address filteringWe 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 MadwifiUnfortunately, 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 APHermes-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/hermesap.html) 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 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 Wlags49Linux 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:
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.
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. |
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. 
| < Day Day Up > |
EAN: 2147483647
Pages: 100