|
|
|
5.1 Anatomy of a Wireless GatewayTo a Linux machine, the wireless card appears to be just another Ethernet device. The wireless driver in the kernel provides a network device (e.g., eth0 or wlan0) that can do all of the things that any other network device can do. The rest of the system is completely unaware that communications are happening over radio. If you have ever built a firewall with Linux, much of this section should seem familiar to you. If you haven't built a firewall with Linux, I highly recommend building one with old-fashioned Ethernet to get familiar with the process. O'Reilly's Building Internet Firewalls, 2nd Edition covers the specific networking issues involved in much greater detail than I have space for here. Another excellent document to work through is the Firewall and Proxy Server HOWTO at http://www.linuxdoc.org/HOWTO/Firewall-HOWTO.html. 5.1.1 HardwareWhile Card Flash (CF), USB, PCI, and mini-PCI adapters have recently come to market, most 802.11b cards you will encounter are PCMCIA devices. At the time of this writing, wireless cards cost anywhere from $35-$100, with the average hovering around $65. Don't be fooled by their small size; these tiny cards are capable of sending a signal several miles with the proper antennas. Obviously, to set up a machine as a wireless gateway using a PCMCIA card, you need a computer with at least one PCMCIA slot. Although the most common computers that support PCMCIA are laptops, a desktop or rack mount box with a PCMCIA converter card will also work. Many vendors sell PCMCIA to PCI or ISA converters specifically to fit wireless cards into desktop machines. There are also a number of inexpensive PCI cards on the market, including the Linksys WMP11 and the D-Link DWL-520. Both of these cards are supported by the Host AP driver. If you have any doubts about whether your hardware is supported under Linux, consult the current Hardware HOWTO at http://www.linuxdoc.org/HOWTO/Hardware-HOWTO/.There is also a lot of great information available in the Wireless HOWTO at http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Wireless.html. Note here that there are a bunch of older 802.11 frequency hopping cards floating around. They come in both PCMCIA and ISA/PCI packages and, unfortunately, are not 802.11b compliant. If you want to support 802.11b clients and data rates greater than 2Mbps, these cards will not help you. Always look for the "b" before you buy (there's a reason why the guy at the computer show is running a killer deal on $20 "wireless adapters"). In addition to a PCMCIA slot for the wireless adapter, you'll need an interface that connects to another network. In a laptop, this device is usually a network card in the second PCMCIA slot, although a built-in modem or Ethernet port will also work. In a desktop or rack mount machine, you can use any sort of network device but an Ethernet card is probably the most common (second only to dialup). As far as actual computing hardware goes, you might consider using an older laptop or tablet PC as a gateway. It draws less power than a desktop, has built-in battery backup, and typically gives you two PCMCIA slots to work with. A 486 DX4/100 laptop can easily support several people as a masquerading gateway, as long as it has enough RAM (16 to 32MB should be plenty) and isn't doing anything other than routing packets and providing DHCP. We'll design our gateway to work "headless," so a working LCD panel won't be a requirement (assuming your laptop has an external video connector to initially configure it). You can often pick up older used laptops at thrift stores or computer surplus stores for under $200 (just be sure to try before you buy; it does need to boot!). There are also a number of embedded-style computers that work quite well as host-based access points. Here are some examples of popular host hardware:
Whatever hardware platform you choose, be sure that it meets your needs. When choosing a piece of hardware, you should remember to consider the number and type of radio and network interfaces, cooling and power requirements, size, RAM and CPU available, and, of course, the cost. If you already have a machine on your network providing firewall services, it's a relatively simple matter to install a wireless adapter in it and have it serve as a gateway. If you already have a firewall running Linux, feel free to skip Section 5.1.2. 5.1.2 Linux DistributionChoosing a distribution (much like choosing an operating system) should be a straightforward process: identify your project goals and requirements, assess what each of the competing choices provides, and make your choice. Unfortunately, the ultimate choice of "which one" seems to be increasingly driven by marketing machinery and passionate treatises on Usenet rather than simple design details. Rather than settling on a particular Linux distribution (and accidentally revealing my tendency to Slack), here are some components that are absolutely vital to a wireless gateway, and should ideally be provided by your distribution. Mandatory components:
Optional components:
Some things you will not need (and they'd probably just get in the way):
Installing Linux is very straightforward with most modern distributions. Typically, simply booting from the CD will get the process going. I'll assume that you have the system installed and running on your existing network for the rest of this section. If you need help getting to your first login: prompt, there are tons of great references on how to install Linux online. You might start with the wealth of information from the Linux Documentation Project athttp://www.linuxdoc.org/. Of course, there are a number of existing Linux distributions that might allow you to skip the rest of this chapter altogether. For embedded solutions, there are a number of ready-to-run distributions specifically designed for wireless work. Two of the more popular distributions are Pebble (http://www.nycwireless.net/pebble/) and Leaf (http://leaf.sourceforge.net/). Pebble is a terrific project developed by Terry Schmidt of NYCWireless, and fits a very usable read-only, Debian-based Linux distribution (including Perl!) into less than 64MB of space. The WISP-Dist flavor of Leaf is designed to fit in under 16MB of space and includes many tools you need for a simple gateway. In addition to embedded distributions, there are a few bootable CD distributions floating around that can easily be adapted for wireless work. The LinuxCare Bootable Toolkit (http://lbt.linuxcare.com/) and Knoppix (http://www.knopper.net/knoppix/) are two options. While a CD-ROM drive is obviously required, a hard drive or other storage medium is completely optional. All too frequently, community projects are centered around "what can we do with what we have" rather than "what can we buy to do what we want." If you have a pile of donated equipment and much of it can boot from CD, one of these distributions might be exactly what you need. 5.1.3 Kernel ConfigurationOnce your system software is installed, you'll need to configure the kernel to provide wireless drivers and firewall services. The parameters that need to be set depend on which kernel you're running. The 2.2 kernel has been around for quite a while and has proven itself stable in countless production environments. The 2.4 kernel is up to 2.4.20 as of this writing. While much more rich in features and functionality, it is also a much larger and more complex piece of software. For a new installation on a machine with adequate RAM (at least 16MB for a simple gateway), the 2.4 kernel is probably the best choice, as more and more developers are actively developing drivers for this platform. If space is tight, or you have an existing machine running 2.2 that you would like to turn into a gateway, 2.2 works fine in most cases. Let's look at the specific kernel parameters that need to be set for each kernel. In either case, first cd to your Linux source tree and run make menuconfig. For these examples, we'll assume you're using either 2.2.23 or 2.4.20. Feel free to compile any of these options as loadable modules. 5.1.3.1 Linux 2.2.23In addition to drivers specific to your hardware (SCSI or IDE drivers, standard filesystems, etc.), make sure the following parameters are compiled into the kernel: Under Loadable module support:
Under Networking options:
Under Network device support:
Note that you need to enable only the Wireless LAN category, not any of the specific drivers. This enables the kernel's Wireless Extensions, and provides the /proc/net/wireless monitoring interface. Don't worry about PCMCIA network drivers as these will be provided by the PCMCIA-CS package or the Host AP driver. 5.1.3.2 Linux 2.4.20Verify that the following are built into your kernel: Under Loadable module support:
Under General setup:
This enables the PCMCIA/CardBus support category. Under that section, enable the following:
Under Networking options:
This enables the IP: Netfilter Configurationcategory. Under that section, enable the following:
Under Network device support there are two subcategories of interest. Under Wireless LAN (non-hamradio) enable:
Also enable support for any PCMCIA radio cards you intend to use here. If you want to use Host AP for your Prism-based radio, don't worry. We'll build that after we're finished with the kernel. I prefer to build these as modules, but you can build them into the kernel as well. Under PCMCIA network device support, be sure to enable the following:
Beyond these required components, include the drivers you need for your specific hardware. If this is your first time building a new kernel, remember to keep things simple at first. The dazzling assortment of kernel options can be confusing, and trying to do too many things at once may lead to conflicts that are difficult to pin down. Just include the minimum functionality you need to get the machine booted and on the network, and worry about adding fancy functionality later. The Linux Documentation Project has some terrific reference and cookbook-style material in the Kernel HOWTO at http://www.linuxdoc.org/HOWTO/Kernel-HOWTO.html. RTFM[1] and encourage others to do the same!
5.1.4 PCMCIA-CSPCMCIA and Card Services provide operating system support for all kinds of credit card-sized devices, including Ethernet and wireless cards. The PCMCIA-CS package is actually made up of two parts: the drivers themselves and utilities that manage loading and unloading the drivers. The utilities detect when cards are inserted and removed and can give you status information about what has been detected. If you are using a non-PCMCIA radio card, you can configure the card just as you would any other network device. As methods vary wildly between distributions, consult your distribution documentation for configuration options. 5.1.4.1 SoftwareIf your distribution includes a recent release of PCMCIA-CS, feel free to skip this section. You can tell what version you have installed by running /sbin/cardmgr -V. The latest (and recommended) release as of this writing is 3.2.3. If you need to upgrade your PCMCIA-CS, follow the installation instructions in the package (it comes with a current version of the PCMCIA-HOWTO). When building from source, the package expects you to have your kernel source tree handy, so build your kernel first and then PCMCIA-CS. You can download the latest release at http://pcmcia-cs.sourceforge.net. 5.1.4.2 ConfigurationSetting up radio parameters is very straightforward. All of the wireless parameters are set in /etc/pcmcia/wireless.opts. Here's an example wireless.opts for IBSS mode: # # wireless.opts # case "$ADDRESS" in *,*,*,*) INFO="Any card in IBSS mode" ESSID="NoCat" MODE="Ad-Hoc" RATE="auto" ;; esac Here's another example for BSS Master (i.e., Host AP) mode: #
# wireless.opts
#
case "$ADDRESS" in
*,*,*,*)
INFO="A card in Host AP Master mode"
ESSID="NoCat"
MODE="Master"
CHANNEL="6"
RATE="auto"
;;
esac
You may be thinking, "My God, it's full of stars . . . " But if you have ever worked with network.opts, the syntax is exactly the same. If you haven't, those asterisks allow for tremendous flexibility. The script is passed a string in $ADDRESS that gives details about the card that was inserted, so you can have different entries for different cards. The address-matching syntax is: scheme, socket, instance, MAC address) The scheme allows for setting up as many arbitrary profiles as you like. The most common use for schemes is on a client laptop, where you may have different network settings for your office wireless network than for your home network. You can display the current scheme by issuing the cardctl scheme command as root, and you can change it by using a command like cardctl scheme home or cardctl scheme office. Both wireless.opts and network.opts are scheme-aware, allowing you to change your network and wireless settings quickly with a single command. The second parameter, socket, is the socket number that the PCMCIA card was inserted into. Usually, they start with 0 and go up to the number of PCMCIA slots you have available. To find out which is which, insert a card in one slot and issue the cardctl status command. The third parameter, instance, is used for exotic network cards that have more than one interface. I haven't come across one of these, but if you have a network card that has more than one network device in it, use this to set different parameters for each device, starting with 0. I find the last parameter, MAC address, very useful, as you can match the setting to a specific MAC address. You can even include wildcards to match a partial MAC address, like this: *,*,*,00:02:2D:*) This would match any recent Lucent card inserted in any slot, in any scheme. Keep in mind that the wireless.opts is called only to set radio parameters. Network settings (such as IP address, default gateway, and whether to use DHCP) are set in network.opts. For our wireless gateway example, we'll need to set up an Ethernet card and a wireless card. Include the previous code in your wireless.opts. Create entries in your network.opts like these: *,0,*,*) INFO="Wired network" DHCP="y" ;; *,1,*,*) INFO="Wireless" IPADDR="10.0.0.1" NETMASK="255.255.255.0" NETWORK="10.0.0.0" BROADCAST="10.0.0.255" ;; Be sure to put these above any section that starts with *,*,*,*) as it will preempt your specific settings. These settings assume that the wired network will get its IP address via DHCP. You can set DHCP="n" (or just remove the line) and include IP address information as in the second example if your ISP uses static IPs. The examples assume that the Ethernet card is in slot 0, and the radio is in slot 1. You could also match the MAC address of your cards if you want the flexibility to plug either card in either slot, although generally, once your gateway is up and running you'll want to forget it's even on. See the PCMCIA-HOWTO for full details on all of the tricky things you can do with $ADDRESS. 5.1.5 Host APThe Host AP driver allows a Prism-based radio card to operate as a BSS master or slave, and it can also use IBSS mode. It is highly recommended that you use a 2.4 Linux kernel if you use Host AP. To get started with Host AP, download the driver at http://hostap.epitest.fi/. Once the driver is unpacked, simply run a make with the name of the driver you want to build: make pccard builds the PCMCIA driver, make plx builds the non-PCMCIA (plx-based) PCI PC Card driver, and make pci builds the PCI driver. The hardware-independent driver code is automatically built regardless of the driver you choose. It doesn't hurt to build all of the drivers, unless space is a critical consideration on your system. To install the drivers, run make install_pccard, make install_plx, or make install_pci respectively. If you are installing the PCMCIA driver, the make process automatically copies hostap_cs.conf to your /etc/pcmcia/ directory, so that your cards are properly detected when they are inserted. It doesn't hurt to stop and start PCMCIA services once you have installed the Host AP driver. Once installed, the wireless device will be called wlan0 (and the second is called wlan1, etc.). 5.1.6 Wireless ToolsThe excellent Wireless Tools package is maintained by Jean Tourrilhes. You can get it online at http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html. From his page:
These tools provide a method of controlling the parameters of a wireless card, regardless of what kind of card is installed (assuming that the wireless card driver uses the kernel's wireless extensions). It allows you to set the ESSID, WEP keys, operating mode (BSS or IBSS), channel, power saving modes, and a slew of other options. Simply unpacking the archive and running make; make install should copy the binaries to /usr/local/sbin (see the installation notes in the package for more details). The tools currently bundled in Version 21 are iwconfig, iwspy, iwlist, and iwpriv. They are absolutely necessary for any Linux gateway or client. Like its networking counterpart ifconfig, the iwconfig tool operates on a specific interface and lets you view or change its parameters. You can run it at any time from the command line as root to see what's going on. In addition, PCMCIA-CS calls iwconfig when a card is inserted in order to set the initial parameters. Here's a typical iwconfig output: root@entropy:~# iwconfig eth0
eth0 IEEE 802.11-DS ESSID:"NoCat" Nickname:"Entropy"
Mode:Ad-Hoc Frequency:2.412GHz Cell: 00:02:2D:FF:00:22
Bit Rate:11Mb/s Tx-Power=15 dBm Sensitivity:1/3
RTS thr:off Fragment thr:off
Encryption key:off
Power Management:off
Link Quality:56/92 Signal level:-40 dBm Noise level:-96 dBm
Rx invalid nwid:0 invalid crypt:0 invalid misc:0
As you can see, eth0 is a wireless device. The ESSID is set to "NoCat" and WEP encryption is off. For security reasons, the encryption parameter is shown only if iwconfig is run by root. If there are any other wireless cards in range with the same parameters set, they can see this node and communications can commence, exactly as if they were on the same physical piece of wire. Run a man iwconfig for the full list of parameters. The iwconfig binary should be in a common binary path (such as /usr/sbin or /usr/local/sbin) for PCMCIA-CS to be able to use it. The other tools allow nifty features such as monitoring the relative signal strength of other IBSS nodes, showing available frequencies and encoding bit rates, and even setting internal driver parameters, all from the command line. See the documentation for the full details, and some more examples in Chapter 7. For most operations involving a wireless gateway, the iwconfig tool will provide all of the functionality we need to program the wireless card. While you're at Jean Tourrilhes' site, pick up a copy of hermes.conf and copy it to /etc/pcmcia. It will tell PCMCIA to use the new orinoco_cs driver (rather than the older wvlan_cs) for all compatible radios. See his site documentation for more details. 5.1.7 MasqueradingFrom the IP-Masquerade-HOWTO document (available at http://www.linuxdoc.org/HOWTO/IP-Masquerade-HOWTO.html):
IP masquerading makes it almost trivial to give an entire private network access to the Internet, while only using one official, registered IP address. By configuring the gateway's wired Ethernet to use your ISP-assigned address and enabling masquerading between the wireless and the wire, all of your wireless clients can share the Internet connection as shown in Figure 5-1. The internal hosts think they're connected directly to the Internet, and there is no need to specially configure any applications (as you would with a traditional proxy server). Figure 5-1. Using masquerading, an entire private network can "hide" behind a single real IP address As with any form of NAT, masquerading isn't without its drawbacks. For example, the connectivity is one-way by default. Internal hosts can connect to Internet resources, but users from the Internet cannot connect to internal nodes directly. To configure masquerading for the 2.2.23 kernel, save the following script to /etc/rc.d/rc.firewall (or /etc/init.d/firewall, depending on your distribution), and add a call to it in one of your startup scripts: #!/bin/sh echo "Enabling IP masquerading..." # Set the default forwarding policy to DENY /sbin/ipchains -P forward DENY # Enable masquerading from the local network /sbin/ipchains -A forward -s 10.0.0.0/24 -j MASQ # Turn on forwarding in the kernel (required for MASQ) echo "1" > /proc/sys/net/ipv4/ip_forward For Linux 2.4.20, install these commands in the same place, but use iptables to set up the masquerading rules: #!/bin/sh echo "Enabling IP Masquerading..." /sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE # Turn on forwarding in the kernel (required for MASQ) echo "1" > /proc/sys/net/ipv4/ip_forward Be sure to substitute eth0 with the interface name of your wireless card. Of course, this is a very simple example; feel free to elaborate on these rules according to your particular needs and desires. You can also get a copy of these sample scripts at: http://examples.oreilly.com/wirelesscommnet2/. These rules enable anyone within range of your radio to masquerade behind your live IP address and access the Internet as if they were directly connected. 5.1.8 DHCP ServicesAs we saw in Chapter 3, DHCP lets network clients automatically discover the proper network parameters without human intervention. If we want our wireless clients to use DHCP, we need to provide it on the wireless interface. The standard DHCP server was written by the Internet Software Consortium. If it wasn't provided by your distribution, pick up a copy at http://www.isc.org/products/DHCP/. Configuration is very straightforward. Just create an /etc/dhcpd.conf with the following information: subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.100 10.0.0.200;
option routers 10.0.0.1;
option domain-name-servers 1.2.3.4;
}
Substitute 1.2.3.4 with your local DNS server. Once that is in place, add an entry in your /etc/rc.d/rc.local script to call dhcpd on the wireless interface. Assuming your wireless card is at eth0, this should do it: echo "Starting dhcpd..." /usr/sbin/dhcpd eth0 If dhcpd complains about a missing dhcp.leases file, try touch /var/state/dhcp/dhcpd.leases as root, and start it again. See the documentation for more troubleshooting techniques and examples, including how to set up static leases, WINS servers, groups, and all sorts of things you probably never thought a DHCP server could be capable of.
There a few free alternatives available to the standard ISC dhcpd. One interesting package is udhcpd, available at http://udhcp.busybox.net/. While it doesn't have nearly the bells, whistles, and vibraslaps (http://www.helixmusic.com.au/vibraslap.htm) of the ISC's implementation, it does provide simple DHCP service very, very quickly. If you would rather use your existing network's DHCP server, you might consider Layer 2 bridging. There are great examples of how to accomplish bridging in the Host AP package (in the README.prism2 file) and at http://bridge.sourceforge.net/. Generally speaking, a routed access point is more efficient than a bridged access point because it can help prevent unnecessary traffic from being broadcast over the air. But if you are the adventurous type, jump in and give it a try. If your wireless card supports Layer 2 bridging, you can configure it for bridging just like any other network interface. 5.1.9 SecurityThe examples shown earlier create a simple, open gateway configuration. If you don't care who associates with your gateway (and uses your network), this configuration should work fine for you. An example of such a public-access service would be at a conference or user group meeting, or in a community network project. In these cases, many clients will be connecting to the network and ease of connection is the primary concern. In other circumstances, you may not want to allow just any stranger to use your network. Suppose you wanted a wireless gateway for your network at home, and you set up the gateway to use your DSL line's external IP address. Anyone who was within range of your radio could potentially connect, drain your bandwidth, and even send spam or attack other machines on the network. All of this traffic would originate from your IP address, which you are contractually (not to mention socially) responsible for. If you want to simply allow access for yourself and your friends, enabling WEP encryption can serve as an easy and effective deterrent to would-be network hijackers. When using a WEP, all clients that want to talk to each other must use the same key. In most clients, it can be specified either as a hexadecimal number, or as an ASCII string. The length of the key depends on the level of encryption you want to use. As the 802.11b spec allows for 40-bit keys, using it will allow any kind of hardware that complies with the specification to communicate with each other. Some manufacturers have released their own 128-bit encryption implementations, but because it isn't part of the current standard, such cards will work only with equipment of the same manufacturer. I highly recommend using 40-bit encryption for simple access control, as it will cause fewer compatibility issues later. As we've seen, simply adding more bits to a key doesn't necessarily do much for greater security. To use 40-bit keys in Linux, specify either a 5-character string or a 10-digit hexadecimal number as the enc parameter to iwconfig. Many people like to use strings because they're easier to remember. If you do use an ASCII string, you need to preface it with s: to tell iwconfig that a string follows. If you want to set the key to the ASCII string pLan9, you could use either of these two commands: root@gateway# iwconfig eth0 enc s:pLan9 root@gateway# iwconfig eth0 enc 704C-616E-39 Note that when using ASCII keys, the key is case-sensitive. To enable WEP on your gateway at boot time, edit your /etc/pcmcia/wireless.opts to add a KEY= line to your wireless section, like this: KEY="s:pLan9" Remember that when making changes to files in /etc/pcmcia/, it is necessary to stop and start PCMIA services (or reboot) before the changes become active. See Section 5.1.4 for full details on how to set up wireless.opts. Once your gateway is set up, give your private key to all of the wireless clients that you want to grant access to. As long as the ESSID and WEP keys match, you can have a private network that provides Internet access. Other radios in the area cannot use your gateway without this information. If your intent is to offer network access to your local area without exposing yourself to risk or giving away all of your bandwidth, take a look at Section 7.8. 5.1.10 Putting It All TogetherTo recap everything that goes into building the gateway:
Once all of that is in place, reboot the gateway to be sure everything initializes properly without human intervention. Congratulations, you now have a wireless gateway! Now that you can talk to wireless clients with your host-based AP, your imagination is the limit. Some innovative networking techniques are provided in Chapter 7. |
|
|
|
