ONLamp.com    
 Published on ONLamp.com (http://www.onlamp.com/)
 See this if you're having trouble printing code examples


Big Scary Daemons

Setting up Wireless Cards on FreeBSD

04/19/2001

Also in Big Scary Daemons:

Running Commercial Linux Software on FreeBSD

Building Detailed Network Reports with Netflow

Visualizing Network Traffic with Netflow and FlowScan

Monitoring Network Traffic with Netflow

Information Security with Colin Percival

FreeBSD supports a few different types of wireless cards. WaveLAN cards use the wi driver. Aironet cards use the an driver. The Raylink cards use the ray driver. The user interfaces are similar. I'll discuss WaveLAN cards in detail below, but this should work for the other cards as well.

Most wireless cards work with one of these drivers. Even if the names "WaveLAN," "Aironet," or "Raylink" don't appear on the card, it's probably supported. Remember how many different cards use the NE2000 Ethernet card, known in FreeBSD as "ed"? Well, the literal NE2000 is just Novell's card; the hundreds of others are "NE2000-compatible."

If you have questions about a particular card, check the freebsd-mobile@freebsd.org mailing list archives. Unless your card is brand-spanking new, it's been discussed there. At length. Many times.

The important thing to remember with making wireless cards work is that everything on all devices connected to the network must match. Ethernet is easy; you install the card, plug in a cat5 cable, check for a link light, configure, and go! Wireless cards replace the cat5 cable and hub with radio waves. You need to jump through some hoops to configure things properly.

If you're running in ad-hoc mode, you just need to set up all the cards in exactly the same way. Install each card normally. Confirm that your kernel recognizes it. If your kernel doesn't include the driver for that card, rebuild your kernel. If it's a PC Card, just use kldload before inserting the card.

The main tool to configure WaveLAN cards is wicontrol(8). If you enter wicontrol without any arguments, it displays the configuration of the wi0 interface. (You can change the interface with the -i command-line option.) Similarly, an cards have ancontrol, and ray cards use (wait for it...) raycontrol.

We'll look at the commands needed for the bare minimum to get your wireless card securely in operation. Errors in any of these commands will prevent your network from working.

First of all, there's the port type. In the previous article we discussed the differences between ad-hoc and infrastructure mode. If you're in ad-hoc mode, the default (3) is correct. If you have an access point, set your port type to 1. I'm using an Apple Airport access point, so I tell the card to search for it with:

wicontrol -p 1

In the case of my home network, infrastructure mode was really my only option. I could have opened the case on my firewall and installed a network card, but I'm afraid of what could happen if I even touch that ancient piece of crud.

Then you have a network name. You can only network with hosts with the same network name, so this needs to be correct. This helps keep neighbors off your LAN, and vice versa. Since Lucent cards attach to the first network they find, such wrong connections can be a perfectly innocent error instead of a blatant attempt to steal your bandwidth. You set the network name as such:

wicontrol -n YourNameHere

You could technically start networking here. WEP (Wired Equivalent Privacy) encryption isn't set up yet, however. Any traffic you send now will be broadcast in clear-text across the neighborhood. You enable encryption with the -e flag:

wicontrol -e 1

You can then set a WEP cryptographic key. This is a hexadecimal shared secret between the various network nodes. Much like a password, if your key is discovered, anyone can access your network. Set the key with:

wicontrol -k 0x1234567890

Only network cards that have the same cryptographic key and network name can talk to each other. Don't use the key in the example; pick your own.

The wicontrol command only displays keys if run as root. They appear empty when run as a regular user.

If all of your network devices are configured identically, you should be able to assign IP addresses normally and ping. If you can't, one of these settings is probably wrong.

One other issue might arise, and that's frequency. All the wireless stations must be on the same frequency to communicate. There are 14 different 802.11b frequencies. If you find that your network shuts down when you're microwaving a burrito, try a different frequency. You can do that with:

wicontrol -f frequencynumber

The default frequency on cards sold in the US is 3.

If you have an access point, you'll need to configure that as well. In addition to allowing you to bridge your wireless and Ethernet networks, an access point can allow you to control which MAC addresses can connect to your network, and can act as a central point for monitoring. I used the Apple Airport base station as an access point, with great success. It speaks SNMP, so if I wanted to get really funky I could monitor throughput and connections. Best of all, the Airport can be configured from your FreeBSD system with the help of the "airport" tool (/usr/ports/net/airport). Many other access points only have Windows-based configuration tools.

I only had one problem with the airport tool; some of the input windows were too small to hold text. This turned out to be a bug in Java's Swing classes; if the application window isn't large enough to hold the fields, the fields shrink like this. Expand the application window, and input boxes will suddenly appear.

From there it's fairly simple. Hit the "discover devices" button. It will scan the network and look for Airports. When it finds one, it'll open a window containing the IP address. Enter the IP address and the SNMP community string ("public" by default), and you can retrieve the Airport's configuration.

Don't try to create an Airport configuration from scratch in the airport tool. The tool's author freely admits that the Airport has certain configuration requirements that the program cannot set. This information can only be retrieved from a running Airport. Retrieve a good configuration before you try to make any changes.

You need to configure your access point in exactly the same way as your network cards. Give it an IP address on your local network, and set the encryption keys, network name, and channel. You don't need to set the network type -- if you have an access point, you are either running in infrastructure mode or doing something really, really weird.

Take a look at the "bridging functions" tab. This is where you control how the Airport integrates with your existing network. To simply add wireless functions to an existing network, select "Act as transparent bridge."

When everything looks correct to you, hit "Update Base Station." This will reconfigure the Airport. If you did everything right, you can walk down the block reading oreillynet.com on your laptop. I plan to mail this article from the park at the end of the street.

Wireless is just a little bit different than regular Ethernet. Once you understand the requirements, however, setting up wireless is much less confusing. It's well worth the effort, though. My only regret about my wireless setup is that it's too cold outside for me to sit on the patio while writing my column. Thanks, Michigan.

Michael W. Lucas


Read more Big Scary Daemons columns.

Return to the BSD DevCenter.

Copyright © 2009 O'Reilly Media, Inc.