As with 802.11b in general, the world of wireless LANs as experienced through Linux is
an interesting and challenging mix of implementations and approaches. Setting up access
to a wireless network in Linux isn’t a difficult undertaking to a motivated enthusiast, but it is
somewhat complex.
In this article, we’ll look at some common stops for setting up an 802.11b PCMCIA card
on a Linux laptop, provide a general guide to preparing to set up wireless support, and
discuss rudimentary ways to secure connections using OpenSSH — a standard method of
providing an encrypted tunnel for common TCP-based protocols.
It’s important to keep in mind that since support for the assorted families of 802.11b
chipsets in use and available off the shelf is varied and handled by different groups of
developers in the Linux world, deciding which hardware to purchase isn’t quite as simple a
matter as it is for Windows users: not all driver implementations are created equal.
Also at issue is the depth of support one requires. In our experience, a fairly modern
Linux distribution will “do wireless” out of the box, but may not provide support for WEP
or other features of a given WLAN. As a result, it’s important to track the major
projects available fairly closely, since this area of Linux development is still fast-moving.
Support for 802.11b Under Linux
Taking up wireless networking with Linux is still something of a mixed bag in terms of
ease of use and how featureful the provided solutions are. The two most prominent
chipsets supported are provided by Lucent and Intersil.
The most robust support for wireless PCMCIA under Linux exists for the Lucent Wavelan
chipset. These cards are carried under a variety of names, including the popular Orinoco
line, and they form the basis of Apple’s Airport offerings. The majority of software
tools available for configuration and connection monitoring are configured to use Jean
Tourrilhes’ Wireless Tools (see Resources at the end of this article), a suite of packages
that provide basic, textual access to a copious amount of information regarding connection
quality, rates, and basic configuration patterns. The tools are designed to integrate
easily with the existing Linux PCMCIA configuration scheme, allowing users to build them
easily and get up and running with little time invested. A second layer of graphical
applications for the popular GNOME and KDE desktops exist that provide more accessible
presentation of the information these tools produce in the form of small monitoring
applets.
Excellent support also exists for the Intersil PrismII chipset, but it’s a little more
convoluted to get a PrismII card working under Linux and the majority of the graphical
front-ends are not built to access or use the information the drivers for these chipsets
provide. The home for PrismII support under Linux is maintained by AbsoluteValue Systems,
which hosts a variety of e-mail lists and drives development of the linux-wlan project
(see Resources at the end of this article), which in turn provides drivers that work with
cards provided by LinkSys, Compaq, SMC, Samsung, Nokia, and D-Link, to name a few.
In either case, a third factor also exists besides the hardware and the software built
for supporting it: support in the Linux kernel for PCMCIA-based cards, which is generally
very good (as easy as Windows for some of the more common cards). In order to get full
802.11b support, users will at least need to be aware of which version of the PCMCIA tools
their computer has and may have to have a working build of the pcmcia-cs package available
on which to base the compilation of their wireless drives. (See Resources at the end of
this article for links to the pcmcia-cs project).
What we hope to have made clear at this point is that while Linux is fully supported
for connections to 802.11b WLANs, it isn’t necessarily a plug-n-play proposition. It
requires a little time to verify the chipset in use by a given card and matching the
appropriate driver project to that hardware.
Getting Set Up For Building Wireless Drivers
Proper preparation is an important part of setting up any device support under Linux that
doesn’t come with a generic kernel. As we mentioned earlier, building 802.11b drivers
requires coordination between the basic kernel configuration, the pcmcia-cs tools, and the
actual drivers for a given wireless card.
Step 1: Kernel support
The first step in getting wireless support
going for a Linux laptop is a working installation of either a complete kernel source tree
(if the laptop in question is running a custom-built kernel) or the kernel headers package
from the distribution in use.
Since most users who have built their own kernels are familiar with where they’ve kept
their build trees, we’ll leave our discussion of custom-built kernel configurations to
this: it’s helpful to at least have a link set from the build tree to the /usr/src/
directory. Most of the software involved in building wireless drivers expects to find the
directory /usr/src/linux or something similar (some distributors use the complete version
of the kernel for naming the source directory: /usr/src/linux-2.4.10, for instance).
Systems where the default kernel package is in use are easy enough to set up. On our
Red Hat 7.2 laptop, the following packages are installed: kernel-headers-2.4.7-10,
kernel-2.4.7-10, and kernel-source-2.4.7-10. We also have the basic kernel pcmcia drivers
installed: kernel-pcmcia-cs-3.1.27-10. Finding out which kernel packages are in use on a
given Red Hat (or any RPM-based system) can done by issuing the command:
rpm -qa|grep kernel
which queries the RPM database for its entire list of packages and searches for the ones
with kernel in their name. Users of other distributions will need to consult the
documentation for their distribution’s package management tool to learn how to issue
similar commands.
If the kernel-headers, kernel-source, and kernel-pcmcia-cs packages aren’t installed,
they can be located on the distribution CDs or via the Internet. RPM-based systems have
an excellent resource in the form of RPM Find. In the
case of kernel-related packages, it’s important to match the distribution the laptop is
running exactly: distributors all have different approaches to patching and distributing
the kernel.
Step 2: pcmcia-cs support
The next general preparatory step involves getting the pcmcia-cs packages properly
prepared, since most wireless driver packages are built based on the header files found in
this package. There are a few ways to go about this. The most direct is to verify which
version of the pcmcia-cs tools is in use on a given installation, downloading the matching
source package from the project page (see Resources, below), and building the package
while making sure to not install the package from source. Distributors usually take
quite a few steps to make PCMCIA support for Linux more smoothly integrated than it would
be by default.
The best way to verify which pcmcia-cs package is in use on a given laptop for Red Hat
and RPM-based distributions is to simply issue the command:
rpm -qa|grep pcmcia
which will return the name of the RPM installed that provides these drivers.
Unfortunately, some older Red Hat distributions aren’t reported correctly, which causes
trouble later down the line. It’s helpful to look in the package’s documentation
directory (usually either /usr/doc or /usr/share/doc) and consult the
CHANGES directory to
verify the correct version of pcmcia-cs in use on a given system. Once that has been
determined, a visit to the pcmcia-cs archive will net the proper version of the package to
use. (See Resources, below.)
Building these drivers is fairly simple, and we’ll repeat our caveat: do not install
this package once you’ve successfully configured and built it, it’s only in use to
provide headers on which to build the appropriate wireless tools.
To build the pcmcia-cs package, unpack the archive in a directory like /usr/local/src,
change to the newly created directory, and issue the following command:
./Configure
Note that the “C” in “Configure” is capitalized, unlike most source packages users will
be familiar with.
The Configure script will ask for the location of the Linux source directory, which is
where either the build tree for the kernel in use or the kernel headers are located.
Under Red Hat 7.2, this directory is /usr/src/linux-2.4. Other distributions will vary,
and this information should have been discovered during the last step of this guide.
The default options provided in the remaining are generally acceptable. Once the
Configure script is done discovering the basic system configuration, the pcmcia-cs source
is ready to build by issuing the command
make all
Once this build completes, you’re assured of complete support for installation of
whichever Linux drivers are appropriate for 802.11b support on the laptop. Consult the
Linux Wireless HOWTO (see Resources, below) to decide on a package to download. In our
experience, the bulk of difficulties in setting up wireless support come from making sure
the kernel and pcmcia-cs packages are appropriately configured, so installation of a given
set of drivers should prove a simple matter of following instructions provided in each
package. The pages in the Resources section below provide access to documentation and
mailing lists that will address the myriad configuration options that exist for each card
and possible configuration. It will also be necessary to learn how access is configured
on your local WLAN: factors that play in include whether DHCP is required, and whether WEP
is in use.
Basic Security for Linux WLAN Clients
We’re going to skip ahead now, to providing a few tips on securing wireless communications
between a Linux client and a given server.
As most are aware by now, the WEP encryption provided by vendors for their 802.11b
offerings is not bulletproof by any means. Given a suitably active network and a little
time, programs like Airsnort (see Resources, below) can easily crack WEP keys, providing
intruders the ability to sniff traffic over a WLAN. Trusting the physical layer of a
network has never been considered good practice, but with a wireless layer that can
effectively extend the “physical” presence of the LAN out to a sidewalk or neighboring
building, it’s even more important to make sure that services are adequately secured.
The immediate implication here is that traditional Linux/Unix services that relied on a
modicum of physical security, most notably NFS, are much more dangerous on a network with
a wireless component. Consider, for instance, basic NFS configurations, which rely on a
combination of IP address and user id to authenticate clients. Viewed as an acceptable
risk in a network with reasonable physical security, NFS becomes more problematic.
Efforts are underway to tunnel NFS transactions via SSH (see Resources, below), but it’s
important to remember that a security scheme built on the physical security of a network
and WEP simply isn’t a security scheme at all in the wireless world.
Fortunately, there are ways to provide more security in the form of traffic
encryption. As a springboard to further investigation we’ll offer a quick example with
OpenSSH, the open source implementation of the ssh protocol. Through use of OpenSSH,
common network protocols can be routed through an encrypted tunnel, providing a much
harder nut to crack for potential intruders.
Consider, for instance, accessing SMTP and IMAP server. Under ordinary
circumstances, these protocols pass traffic back and forth between server and client
unencrypted. An intruder who’s already compromised a wireless network can sniff the
traffic passed back and forth between client and server with impunity, harvesting
passwords and the content of messages with ease. With an ssh tunnel, though, the traffic
is encrypted and routed from ssh client to ssh server, making it much harder for the sort
of passive attacks that have spread in notoriety.
The basic recipe for creating a tunnel between client and server is to decide on an
unprivileged port on the client to route a given protocol to, and identification of the
remote port the given tunnel should access.
Returning to IMAP as an example, for instance, it’s possible to create an encrypted
tunnel to a given server by opening an X terminal and issuing the following command:
ssh -L 1234:imap.server.com:143 imap.server.com
The laptop’s IMAP client can then be directed to access its own port 1234, which will, in
turn tunnel traffic to port 143 of the machine imap.server.com. This tunnel will stay
open until the user terminates the ssh session. Another way to set up a tunnel for a
given period of time (much more dangerous if the laptop or client is going to be left
unattended) is to fork the ssh session to the background:
ssh -f -L 1234:imap.server.com:143 server.imap.com sleep 1h
This directs ssh to open the tunnel, then, once the tunnel is open, issue the command
sleep 360, which essentially tells the computer to do nothing for one hour while traffic
is passed back and forth over the tunnel.
Using the popular Evolution client, and having created this tunnel, under the
tools/mailsettings menu, one would set the IMAP host to be localhost:1234.
Using the equally popular console-based mutt, placing the following commands in the
.muttrc file will create and utilize a tunnel for each connection:
set tunnel="ssh -q imap.server.com /usr/sbin/imapd" set preconnect="ssh -f -q -L 1234:imap.server.com:143 imap.server.com sleep 5
This is by no means the be-all and end-all of security or Linux 802.11b clients, but SSH
is a flexible and secure way to encrypt many common protocols such as POP3, IMAP, and
SMTP.
Wrapping Up
In this article, we convered the basics of setting up a laptop to build 802.11b
drivers and provided a hint of how SSH can be used to secure basic services. Because of
the wide variety of possible hardware and software configurations, we avoided a specific
discussion of configuration for each package, preferring instead to leave that to the
projects themselves, which provide mailing lists and documentation on their own. The
Resources section is a collection of the very best starting points for each area we
touched on and should fill in the gaps we’ve left.
Resources:
- http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Tools.html
— The Wireless Tools Page - http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux — Wireless LAN Resources for Linux (the canonical reference, sponsored by Hewlett Packard)
- http://www.linux-wlan.com/linux-wlan/
— linux-wlan project homepage, sponsored by AbsoluteValue Systems -
http://pcmcia-cs.sourceforge.net/ftp/
— The pcmcia-cs project download area - http://www.openssh.org — The OpenSSH homepage
- http://airsnort.sourceforge.net — The Airsnort homepage
