LJ Archive

Setting up an All-Linux Wireless LAN

Don Marti

Issue #94, February 2002

Laptops are cheap, WiFi cards are cheap and well-supported...maybe it's time to build your own LAN.

If you've been to a Linux conference lately, you've probably seen a lot of people with wireless network cards, happily checking their e-mail while they sip refreshing beverages. The 802.11b, or “WiFi”, cards are really cheap, convenient and well supported under Linux.

If you want to do wireless networking at home, though, just plugging in a base station might not be too smart. Even with the largest key sizes, the badly named Wired Equivalent Privacy (WEP) encryption protocol that WiFi uses is vulnerable to people walking nearby—for large values of “nearby”. Security consultant Peter Shipley reports connecting to WiFi networks 25 miles away using a directional antenna. And as little as half an hour of intercepted traffic could be enough time for someone to break WEP and get on the Net using your base station (see Resources).

You can do some things to make WEP stronger, but it's inadequate as protection. (Adobe Systems, Inc. reportedly shut down all their WiFi base stations after they got the government to arrest programmer Dmitry Sklyarov. They may be trying to set software and free speech back 500 years, but they aren't stupid.)

The threat to WiFi is not that people might read your data—you're using ssh and SSL to protect sensitive information anyway. The threat is people using the network you're responsible for to do bad things. If a spammer or a script kiddie gets on the Net using your base station, it's almost impossible to find him or her. Who gets the blame? You do.

If you do decide to provide public connectivity via 802.11b, that's mighty neighborly of you. Get a separate net connection, put up a base station, join the relevant mailing lists and have fun. If someone uses your public base station to send spam or break into people's computers, and your ISP cancels the account, you'll still have your regular net connection.

So if off-the-shelf base stations are bad, what's the alternative? How about an old laptop? In case you haven't noticed, prices are coming down, and you probably can get a new laptop with half a gig of RAM and a 1600 × 1200 display for about eight dollars by the time you read this. So treat yourself to a new laptop and convert your old one into the base station. The on-line auction sites also have made damaged laptops really cheap. Busted hinge? Missing battery latch? Might not be the best thing to carry around, but with a little duct tape, there's your base station.

I put Debian on mine because it has packages for all the software mentioned in this article and a good automatic upgrade system. But any current distribution will work. (I didn't have to compile anything from source or reboot to do this article, although I did reboot a couple times after configuration to make sure everything came up in the right order.)

I shouldn't have to say this, but buy WiFi cards that are well supported by your distribution of choice. I got a pair of Orinoco cards.

Since your base station will be exposed to anyone who walks by with a WiFi card, take a few basic administration and security measures (which apply to any internet server) before you plug the card in.

First, forward root's mail to your real e-mail address, so important messages don't go unread.

Check that log rotation is working and that plenty of space is available in /var/log.

Configure the mailer dæmon to listen only on the loopback interface.

Set up either ntpd or a cron job to run ntpdate, so all times in the logs will be correct.

Remove all unused software, and apply any security fixes or updates.

Copy your main ssh key into .ssh/authorized_keys2 in your home directory on the base station, so that you never need to send your password over the Net, even encrypted. Configure sshd to refuse passworded or root logins.

Make sure you are subscribed to the security mailing list for the distribution the base station is running.

Finally, run Nmap against the base station from outside to make sure that no unnecessary services are running. From outside you should see ssh and that's it.

Just in case your base station does get compromised, make sure that no information or keys on the base station would help people get into any of your other systems. For example, accounts on the base station should not have ssh keys.

In this article, I use 10.2 addresses for the underlying WiFi, and 10.3 addresses for the VPN. Now it's time to get on the air.

Set up the PCMCIA Cards in the Base Station

The actual order of eth0, eth1 numbering depends on the order in which the drivers are insmod-ed, and the cardmgr dæmon probes the slots in order on boot. On my laptop (now base station) the WiFi card and conventional Ethernet card will only fit if the WiFi card is in the top slot, slot 0. That means that my WiFi interface is eth0, and my regular Ethernet is eth1.

By default, when you boot the base station, the PCMCIA script will start the cardmgr dæmon and possibly exit before all the cards are initialized. If you're running a server of any kind, this is not what you want to happen. All the interfaces should be up before dæmons try to start. Pass the -f option to cardmgr by putting it in the PCMCIA init script or configuration file; on Debian it's /etc/pcmcia.conf (see Listing 1). Below is /etc/pcmcia/wireless.opts:

# use "Ad-Hoc" mode to act as a base station.
# Set your own ESSID.
case "$ADDRESS" in

Listing 1. /etc/pcmcia/network.opts

To check your work, do an ifconfig and an iwconfig on the base station, and make sure the information is correct. Make sure that you can still log in to the base station over the regular Ethernet.

Set up WiFi on the Client

All you should have to do is put in an extended service set ID (ESSID) that matches the one on the base station.

Set up the DHCP Server on the Base Station

To make the base station work as a DHCP server, you also will need to add a route to, which is the destination address for DHCP traffic. Unless the route exists, DHCP packets will take the default route instead of the WiFi interface, which is not what you want. You can add this route to the dhcp init script. While you're editing this script, make dhcpd run it only on the WiFi interface (in the case of solanum, eth0). You don't want the base station spewing DHCP traffic to places it isn't wanted. So replace



route add -host dev eth0
/usr/sbin/dhcpd eth0
Set up a dhcpd.conf file on the base station to give out IP addresses only to your own systems:
# /etc/dhcpd.conf for solanum
# run the DHCP server on the WiFi interface only!
default-lease-time 1800;
max-lease-time 7200;
subnet netmask {
subnet netmask {
host cannabis {
    hardware ethernet 00:02:2d:2e:56:df;
This is not a security measure, but it will keep your DHCP server from wasting time on any of your neighbors who set up their clients incorrectly.

At this point you should be able to ping the base station from the client over WiFi.


There are many virtual private network (VPN) options for Linux, and you might have one installed already for a different reason. If so, you can skip installing a separate VPN just for WiFi, and simply configure IP masquerading on the base station to allow traffic only from the WiFi network to the VPN server and vice versa, and you're done. If you need to set up a VPN between several locations for travelers or for home offices, and you also need VPNs for WiFi at each location, save time by picking one VPN that works for both.

Otherwise, choose and install a VPN just for WiFi. For this article, I chose vpnd (see Resources), which has the advantages of working with an “out-of-the-box” kernel, being available as a Debian package and being simple to configure.

The kernels of clients and the server will need to have the kernel random number generator and SLIP support as a module. The stock kernels that come with distributions have this, but if you built your own kernel and didn't compile any modules you didn't need then, you'll have to go back, make menuconfig, choose SLIP and then do:

make modules && make modules_install.

The good news is that you don't have to reboot to do this if you're running a modular kernel and still have the kernel source and kernel .config that you built from. If you took out kernel random number generator support, shame on you—put it back in, as not only vpnd but much other fine crypto software depends on it.

To set up keys for vpnd, run vpnd -m on the base station, then copy the resulting /etc/vpnd/vpnd.key to the client. Configuration files for vpnd are pretty simple; Listing 2 shows an example.

Listing 2. /etc/vpnd/vpnd.conf

At this point you should be able to ping the base station's virtual address ( in this case) from the client, and vice versa. If not, check the logs for vpnd errors, and use ifconfig and route at both ends to make sure the IP address and routing information are correct.

IP Masquerading

Every distribution has its own IP masquerading setup tool, and IP masquerading articles are as common as pig tracks, so turn it on however it says in the book. You will need to make sure that the WiFi network ( in our example) doesn't get masqueraded—just the VPN. To test that masquerading is set up correctly, don't only surf the Web and send mail from the client—temporarily change the default route on the client to go over the WiFi directly instead of the VPN, and make sure that you can't.

Many exciting future developments in wireless networking are on the way. Future security protocols should make the VPN dance unnecessary, and community networks such as NoCatNet are working out protocols to let you share your access point with neighbors without opening yourself up to abuse. But, today's 802.11b cards are going to be common and serviceable for a long time.


email: dmarti@zgp.org

Don Marti is technical editor of Linux Journal and editor in chief of Embedded Linux Journal.

LJ Archive