Building a Wireless Access Point on Linux: Custom solution offers flexibility and customizability—and a chance to learn

In this article, I'll take you through the process of building a wireless access point running Linux. I won't cover every last line of code, every intermediate step, or every detail of hardware; that would take a book and would be obsolete by the time you read it. The goal is to show you what kinds of concerns and pitfalls you'll face should you want to do this. For this piece, we build the access point to operate as a bridge; simply forwarding packets between the wireless network and a local ethernet. This allows wireless devices to simply be turned on and attached using your existing network—no new configuration, no special routing.

	For more Linux resources and for information about the xSeries 360 and 440 Rack-Optimized Servers, visit the IBM eServer member pavilion.

The first is flexibility and customizability. Want a firewall? No problem. Custom routing? NAT? All easily managed. Custom Web-based configuration? Half an hour's work with CGI scripts. You can add traffic graphing if you like. That off-the-shelf box may have a special Windows-only configuration tool, so it won't be possible to ssh in and change your settings. You won't be able to run your weblog off of the Web server. If there's a problem, you have to wait for a "firmware upgrade"—which may or may not address your problem.

The other—and perhaps more compelling—reason is that it's fun, and it's a good way to learn about the issues you may face running an embedded Linux system. Think of this as a hobbyist's test project, and if you come up with a killer app for it, you might just be able to make a profit anyway.

To follow the whole thing, you'll also need another Linux box, to format and configure the flash card. A laptop is ideal, but anything with a USB port should work, if you have a CF reader that works under Linux.

As for software, there are existing packages that come pretty close to working out of the box, or you could start from scratch with an old set of install CDs and do it the hard way. For this article, I started with Pebble Linux, a small distribution that comes close to meeting my needs right off the bat. However, there's plenty of fun to be had tweaking settings and maybe adding a few custom features. From here on in, I'll be assuming you've got basic experience using Linux: editing files, running commands, and maybe even configuring a simple network. If you don't, your friendly neighborhood Linux hacker will probably walk you through this project for the price of a pizza, and explain what's going on if you include extra cheese.

For this project I used 802.11b wireless, the standard used by Apple's original Airport network and the most widely-available wireless standard. Theoretical bandwidth is 11Mbps, or just a tad faster than slow ethernet. The practical bandwidth is good enough to keep up with cheap broadband. The reception range is variable, but most people can reach a back yard or a neighboring apartment.

The phases are:

• Initial setup: We get the embedded system to boot and to offer a console login prompt.
• Network setup: We get the network up and running, so the machine can actually be used as a functioning access point.
• Tweaking: We start on the long road to changing and adapting our machine's functionality.

Initial Setup
Obtain an embedded system. I used the Soekris Net4521, but other systems, such as the Technologic TS-5500, are probably about the same experience. If you're desperate, you can probably use an old laptop! The important part, for now, is a PCMCIA slot and a disk you can format and configure from another machine. Embedded systems mostly use CF disks as their primary drives.

You'll also need a host system. A laptop running Linux will work, as will a desktop running Linux with a supported CF drive. Being perverse at heart, I used an already-installed embedded system with a USB CF drive, but it really doesn't make any difference.

I used a 128MB CF card for this project. That may seem huge—and it is—but it's always nice to have some spare room. The distribution in question (Pebble Linux) fits reasonably well even in a 64MB card. This spare room will be used later to install extra toys.

Once your hardware is together, boot your host system. Plug in a card reader with your 128MB CF card in it. The card should show up as sda; test this by running:

fdisk /dev/sda

You should see a prompt.

Now, partition the disk. Enter p to print the partition table. If your card hasn't been used for this before, it will probably show a single DOS partition. Delete it by entering d, and enter the partition number when prompted. Create a new partition, with the n command; the default range should be fine. Mark the partition as active by entering a, and enter the partition number when prompted. Now, enter w. You have now partitioned the drive to have a single Linux partition on it.

If you're using a PCMCIA-to-CF adapter in a laptop, your card will probably show up using the hd driver rather than sd. That's fine; just use the right name for it.

Next, format the disk. The command to do this is mke2fs /dev/sda1. Once it's formatted, mount it.

Now, extract the Pebble distribution. Pebble's installer assumes you'll have unpacked on another disk and will then copy over to the new disk. If you don't have another disk handy on your target system, you'll have to edit the installer; you can just extract the archive on your target disk, then update the scripts locally on it. If you're using a disk other than one of the suggested ones, you need to make a new lilo.conf file for your target drive; just copy the lilo.conf for hdc, and replace the device name. If you're determined to do things by hand, you need to run lilo, make ssh host keys, and set a root password. You also probably need to configure in some extra kernel modules; likely sets for a couple of systems are provided in /etc/modules.*. For instance, /etc/modules.net4521 is the set of modules to use with a Soekris Net4521 system.

One tricky thing here is that the disk you're targeting will likely be a different disk in the target system. The provided lilo configuration files reflect this; they specify a disk, but then specify "bios 0x80" to warn lilo that the disk will be the primary disk on the new system. Similarly, in your new fstab you'll want to make sure you refer to the right disk; in the typical embedded system, that will be /dev/hda1, not /dev/sda1. Finally, make sure you set up the right console port in inittab; for the Soekris box, the default console speed is 19200kbps, rather than the 9600 Pebble Linux shipped with.

Once this is all in place, you should have a CF card that will simply boot and come up on your target system. Once you have a login prompt, login and look around. There are some useful scripts provided with Pebble Linux to let you remount the root filesystem as either read-only or read/write. The default is to come up read-only—very nice for a system that you may want to unplug a lot.

If you're on a network with DHCP, you'll probably find that your system has already come up with an IP address on its primary ethernet port. (On the Soekris Net4521, I plugged a cable into eth0.) This will save us some work in the next step.

Network Setup
What we really want, for an access point, is a simple bridge; packets from one network show up on the other network, nothing special. The box isn't a router or a DHCP server or anything, it's just a bridge. It could, of course, be set up as a DHCP server or any of a dozen other things, but this is the easy way. A bridge will simply send packets from the wire to the wireless and back. That way, the wireless device looks for all intents as though it's simply attached to the physical network.

Pebble Linux is based on Debian, so that means playing around with /etc/network/interfaces. A quick Google search yields a sample set of commands to play with:

Listing 1. Building bridges

   iface br0 inet dhcp
     bridge_ports eth0 wlan0
     pre-up ifconfig eth0 0.0.0.0 up
     pre-up ifconfig wlan0 0.0.0.0 up
     pre-up iwconfig wlan0 mode master
     pre-up brctl addbr br0
     pre-up brctl addif eth0
     pre-up brctl addif wlan0
     post-down ifconfig eth0 0.0.0.0 down
     post-down ifconfig wlan0 0.0.0.0 down
     post-down brctl delif br0 eth0
     post-down brctl delif br0 wlan0
     post-down brctl delbr br0

#!/bin/sh
ifup --force -v br0

pre-up iwconfig wlan0 mode master key s:blahblahblah1

   #!/usr/bin/perl -w
   print <

   #!/bin/sh
   cat <
   
   
Stats:
   
   EOF

   ifconfig -a 

   cat <
   
   
   EOF

   #!/bin/sh

   cat <

To call this a security hole is to understate the point woefully. But it's a great demo of how insanely flexible our wireless access point is now. In fact, I used this script to get the other scripts off of the system; easier than using scp.

These examples aren't very in-depth; a detailed discussion of CGI programming is beyond the scope of this article. The point is just to give you a few starting ideas. You could host a weblog on a box like this, although you'd want to have some kind of secondary storage for the actual data files. Of course, you could mount a remote disk over NFS!

The embedded system I used (the Soekris Net4521) had more than 36MB of free memory and about 50MB of free disk space when I was done setting it up with the above. That's enough space for a lot of stuff, and it leaves enough CPU time free to run all sorts of small services.

Open source turned a project that once would have taken days or weeks into an idle afternoon's playing around. This makes hobbyist projects practical, but it also makes a good prototype; if you're planning to do an embedded system of some sort and want to make it an access point, this would be a good way to get some practice playing around with the software configuration long before your first hardware samples are ready.

Peter Seebach has been using wireless networks for years, and always wanted to know whether it was cheaper to do it yourself. It's not, but it's lots of fun. This is typical of his experience with do-it-yourself projects. You can contact Peter at developerworks@seebs.plethora.net.

This article was first published by IBM developerWorks at http://www.ibm.com/developerWorks.