Linux Unwired [Electronic resources] نسخه متنی

4.4 WPA on Linux

As of this writing, if you want to use WPA and/or 802.1x as a client on Linux,
you have two options:

Obtain the WLAN Driver Loader from Linuxant. This is a compatibility
wrapper that allows you to use the standard Windows NDIS drivers that
ship with wireless network cards. The advantage to this is that you
can use a wide array of WiFi cards that currently do not have open
source drivers available.

Use a Prism-based Wi-Fi card with the latest HostAP CVS code. The
newest versions of HostAP contain a WPA Supplicant in software that
allows you to connect to WPA-protected networks.

If you want to use your Linux box as a WPA Authenticator,
you're currently out of luck. The HostAP development
team is working towards a full implementation of a WPA Authenticator.
Right now, however, the hostapd daemon acts as
an 802.1x Authenticator and authenticates against a RADIUS database.

Windows XP and Mac OS X both include support for 802.1x Supplicants.
There is an open source implementation available for Linux called
Xsupplicant, which is located at http://www..

A last option is to use your Linux box as the RADIUS server
(Authenticating Server), and use an inexpensive access point as the
WPA Authenticator. You can then use any WPA Supplicant to connect to
the access points, and the backend authentication is handled by
Linux/RADIUS.

4.4.1 WLAN Driver Loader

The Linuxant WLAN Driver Loader is a compatibility
wrapper that allows the use of Windows NDIS wireless network drivers
under Linux. Open source purists have issues with this software,
because parts of it are released only in binary form, and after 30
days you must pay $20 for a permanent license. If
you're completely opposed to anything
Windows-related, keep in mind that this solution requires you to run
Windows binary drivers, so this option may not be for you.

However, at this point in time, Linuxant
is the only game in town if you need access to WPA-protected networks
from a Linux box and you don't have a Prism-based
wireless card. More to the point, the WLAN Driver Loader software
allows you to use WiFi cards that do not have any open source
drivers, including cards with chipsets from Broadcom and Texas
Instruments. For many of the popular 802.11g cards, this may be your only
option in Linux.

A completely open source project to provide NDIS driver loading for
Linux is located at http://ndiswrapper.sourceforge.net. As of
this writing, support for radio chipsets is limited and there is no
support for WPA.

You can obtain the software from the
Linuxant web site at http://www.linuxant.com/driverloader/wlan/full/downloads.php.
Linuxant provides RPM packages for Fedora, Red Hat, Mandrake, SuSE,
and Turbolinux, and has built them for various architectures. Debian
users can download a driverloader.deb package
for installation with dpkg. For other systems, or
if you wish to compile the driver, the source code can be downloaded
as well.

In order to use the WLAN Driver Loader with WPA-PSK
(personal) authentication, Linuxant provides a wpa_supplicant daemon
that is also available in its downloads section. If you need to have
WPA-EAP authentication, the Xsupplicant from Driver Loader software from source,
extract the package and change into the newly created directory. A
single make command compiles and installs:

$ tar -xzf driverloader- version .tar.gz 
$ cd driverloader- version 
$ make install

By default, WLAN Driver Loader starts up a localhost web-based
configuration tool on port 18020. You can access it by pointing a web
browser to http://127.0.0.1:18020
and logging in as root. You can also configure the software from a
shell by executing the dldrconfig command.

If you wish to disable the web configurator for security reasons, use
dldrconfig --webconf=off. To reenable it, use
dldrconfig --webconf=127.0.0.1:18020. Note that
this command enables you to choose an alternate port for web-based
configuration.

The dldrconfig command can also be used to change
certain configuration options or recompile (generic packages only)
the kernel modules after installation or kernel upgrades. Run
dldrconfig --help for usage information.

If necessary, the device drivers can be unloaded using the
dldrstop command.

Figure 4-1 shows the screen that you will see when
you point a web browser at the localhost address created by the WLAN
Driver Loader installation.

Figure 4-1. DriverLoader initial configuration

As shown, the first thing you must do is provide the DriverLoader
with Windows NDIS drivers for the device you want to use. Click on
the Upload Windows Driver link, and you will be presented with
another screen, shown in Figure 4-2, that allows
you to browse the local filesystem for an .INF
or .NTF file that comes in the Windows driver
package for your wireless card.

Figure 4-2. Browse for Windows driver files

In our example, we used a Linksys WPC55AG PC Card. We downloaded the
latest driver in ZIP format from the Linksys web site at http://www.linksys.com/download. The file we
obtained was wpc55ag_driver_utility_v1.2.zip,
which we extracted using the unzip command. This
created three subdirectories: Drivers,
image, and utility. In the
Drivers subdirectory, we found two
ar5211.sys files and a
net5211.inf file, which are exactly what we
needed to continue. Obviously, this procedure will vary for each
different wireless card. Linuxant maintains a list of wireless cards
known to work with WLAN Driver Loader and links to
downloads of the associated Windows drivers. This list can be found
at http://www.linuxant.com/driverloader/drivers.php.

Using the browse function in Figure 4-2, we found
the Drivers directory and selected
net5211.inf. The program quickly prompted us
that the ar5211.sys file would be required and
asked us to locate it. Once we clicked OK, the driver file loaded,
and we were presented with the screen in Figure 4-3.

Figure 4-3. DriverLoader shows a missing license for the newly installed driver

As we mentioned, the Linuxant software is proprietary. Permanent
licenses can be purchased from
Linuxant,
and you can also obtain a 30-day license for trial purposes from the
Linuxant web site at http://www.linuxant.com/store. In order to
get a license, you must fill out a registration form, wait for an
email from Linuxant with a verification code, and enter that code.
Once entered, you can generate a license. In order to do this,
Linuxant requires the MAC address from your wireless card. You can
obtain this either from the web interface or by running:

# dldrconfig -info
Linuxant DriverLoader for Wireless LAN devices, version 1.61
Web configurator: listening on 127.0.0.1:18020
Wireless interface name: eth1
MAC address    : 00:0C:41:0A:24:F8
Device instance: PCI-0000:05:00.0-168c:0013-1737:0017
Device driver    : net5211
License owner    : unknown
License key    : none
License status    : MISSING

Enter the MAC address into the form on the Linuxant web site, and
after a few seconds, you will be presented with a 30-day-trial
license key, a 12-character hexadecimal string that needs to be
entered either in the web configurator or by executing
dldrconfig --license. You'll be
asked to enter the email address you used to register with Linuxant
along with the license key, as shown in Figure 4-4.

Figure 4-4. Entering the Linuxant license information

Once you've entered the license information,
you'll be returned to the main web screen, but this
time it should show that your driver is loaded. You can perform
additional configuration on the card by clicking on Settings and then
selecting Advanced. Here you'll see the license
information and any other configuration options that are supported by
the NDIS driver for your card. A sample screen is shown in Figure 4-5.

Figure 4-5. Advanced configuration under WLAN Driver Loader

After having made any changes in the Advanced configuration, exit the
web-based configuration. Your wireless card should now be active. In
this example, you can see that our Linksys WPC55AG wireless card has
been assigned to eth1:

# iwconfig
lo        no wireless extensions.
eth0      no wireless extensions.
eth1      IEEE 802.11g  ESSID:"whitecottage-wpa"  Nickname:"unknown"
Mode:Managed  Frequency:2.447GHz  Access Point: 00:0C:41:D4:71:AB
Bit Rate=54Mb/s   Tx-Power=8 dBm
RTS thr:off   Fragment thr:off
Encryption key:off
Power Management:off
Link Quality:1/1  Signal level:-38 dBm  Noise level:-83 dBm
Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
Tx excessive retries:0  Invalid misc:0   Missed beacon:0

As you can see from the ESSID, we are connected to a WPA-protected
network. To authenticate, see Section 4.4.3 later in this chapter. The
next section describes how to connect to a WPA network with a
Prism-based card and the HostAP driver without using the WLAN Driver
Loader.

Bleeding-Edge Warning

The Linuxant WLAN Driver Loader software is very new. As with any new
software, particularly software that allows cross-platform device
drivers to work, you may run into problems. The first two cards we
tried with the Linuxant software did not work.

The Linksys WPC55AG card is based on the Atheros 5211 chipset and is
compatible with 802.11a/b/g. While it was easy to load the card
driver and make it work with WLAN Driver Loader, further
configuration of the card was prohibited by the fact that we could
not change operating modes. The card remained stuck in 802.11a mode,
making it impossible to test with our 802.11g access point that
supports WPA. According to Linuxant Support, the INF file included
with the WPC55AG driver doesn't contain a section
that deals with changing the mode of the card; this is a bit odd,
because the card does support this function in Windows.

We then attempted to load the drivers for an Orinoco Gold 802.11b
card. Agere has recently released Windows drivers that support WPA on
this card, available from http://www.agere.com/support/downloads. While
we were able to load the drivers, WLAN Driver Loader was not able to
find any compatible devices on the system. We suspect this is because
our test system already had the orinoco_cs driver loaded, but even by
disabling orinoco_cs, we were unsuccessful.

Our last, and only, successful test used a Linksys WPC54G 802.11G
radio card. This is based on a Broadcom chipset and worked
flawlessly, in both the setup and with the wpa_supplicant
software.

4.4.2 HostAP

Jouni Malinen, the developer behind the HostAP
project, has developed a package called
wpa_supplicant. In this section, we
discuss how you can use a Prism-based wireless card, the HostAP
driver, and the wpa_supplicant to connect your Linux box to a
WPA-protected network.

In order to use the wpa_supplicant in conjunction with HostAP, you
must have a Prism-based Wi-Fi card with station firmware Version 1.7
or later. The latest version of firmware as of this writing is 1.8.0,
although Version 1.7.4 is more widely available and works as well.
The most complete collection of Prism firmware is located at
http://www.red-bean.com/~proski/firmware

To update your Prism card firmware, refer to the
excellent tutorial at http://linux.junsun.net/intersil-prism. If
you have questions or problems with the firmware update process, we
recommend that you check there first. However, we do go over the
basics of updating your firmware later in this section. To determine
whether you need to update the firmware.

Build and install the hostap utilities (see
Section 4.4.2.2 later in this
chapter).

Use the hostap_diag wlan0 command to determine the
current version of your Prism firmware. Alternatively, use
dmesg | grep wlan0.
hostap_diag returns output similar to the
following:

NICID: id=0x8013 v1.0.0 (PRISM II (2.5) Mini-PCI (SST parallel flash))
PRIID: id=0x0015 v1.1.0
STAID: id=0x001f v1.4.9 (station firmware)

You should be concerned with the Station Firmware version, which must
be at least Version 1.7.0. Chances are that your card is below that
version, and you will need to upgrade the firmware. Take note of the
NICID in the output of dmesg or
hostap_diag. This is the ID of your Prism card
and there are many different IDs. Some IDs have only certain firmware
versions available. To determine the software that is required for
your card, consult the tutorial at http://linux.junsun.net/intersil-prism.

Once you've determined which firmware you need, you
can build hostap and its utilities, and then
update the firmware, as described in the following sections.

4.4.2.1 Building hostap from CVS

While you don't necessarily
need the CVS version of the HostAP code to
update your Prism firmware, you will need it to use the
wpa_supplicant features and to obtain the wpa_supplicant code.

You can obtain the CVS development snapshot from the HostAP web pages
at http://hostap.epitest.fi.
Select the link for development branch in the
section titled "CVS snapshot of the driver source
code." You must have the development branch of the
code to get the WPA features.

Once you've downloaded the compressed file, extract
it and change to the newly created directory:

# tar xzvf hostap.tar.gz
# cd hostap

You must edit the file
drivers/modules/hostap_config.h and make sure
these two items are uncommented: #define PRISM2_DOWNLOAD_SUPPORT and #define
PRISM2_NON_VOLATILE_DOWNLOAD. In the CVS version,
the first #define statement is already uncommented.

Once you have edited this file, go back to the
hostap directory and build the software:

# make
# make install

To load the new
HostAP
drivers, stop and restart the PCMCIA services:

# /etc/init.d/pcmcia restart

4.4.2.2 Building the hostap tools

In the
hostap source directory is a subfolder
containing the hostap utilities. Building them
is easy:

# cd utils
# make

There is no make install command, so if you want
the tools installed outside of the utils
directory, you must move them yourself. Our examples merely run the
utilities out of the directory where they are compiled.

4.4.2.3 Updating the firmware

Copy the version of firmware files that you need for your prism card
into the utils directory. The utility that
manages the firmware upgrade is prism2_srec. This
utility not only updates the station
firmware of your card, but also the
primary firmware. Updating the primary firmware is
beyond the scope of your needs, so focus simply on updating the
station firmware.

Station firmware is always provided in the format
s[platform][version].hex.
The tutorial web pages at http://linux.junsun.net/intersil-prism give
you information on determining your platform. Make sure that you are
using the station firmware file and no other file. You could render
your card useless if you were to update it with the wrong firmware
(the faint of heart may want to consider updating their card using a
Windows-based updater from the manufacturer, which is likely to be
the only supported technique).

First, do a test run in verbose mode:

# ./prism2_srec -v wlan0 s1010701.hex

The -v argument specifies verbose mode, and
because we have not called the tool with any other options, it simply
tests the firmware against the card. If at the end of the output you
see OK, you can proceed to the next step. If you see anything else at
the end of the output, do not proceed. You will know that the
firmware is not compatible with your card if you see output like:

NICID was not found from the list of supported platforms. Incompatible update data

Assuming that your test run returned an OK, you can proceed to the
next step, and write the firmware to the flash on the Prism card.
First, if you use a laptop, make sure it has a fully charged battery
and is plugged into the wall outlet. If your computer is a desktop,
be sure that it is plugged into a UPS. (If the power fails during
this step, your Wi-Fi card will be useless.)

# ./prism2_srec -v -f wlan0 s1010701.hex

The process takes about 30 seconds, and you should make sure that the
card is not removed during the update. Once finished, you should see
output that shows the new firmware versions on the card and that
should be returned to a shell prompt:

Components after download:
NICID: 0x8003 v1.0.0
PRIID: 0x0015 v0.3.0
STAID: 0x001f v1.7.1
#

The card driver is unloaded after the firmware update, so you should
remove the card and reinsert it to reload the driver.

4.4.3 Authenticating with wpa_supplicant

The supplicant software is included in the CVS releases
of HostAP 0.2.x source, so you have already downloaded it when you
installed the CVS version of HostAP in the previous section. Linuxant
also provides the source for wpa_supplicant in the downloads section
of its web site, but as of this writing, the version included with
HostAP 0.2.x source is more current. We recommend obtaining the
HostAP source to build wpa_supplicant even if you plan on using it
with the WLAN Driver Loader.

Operating wpa_supplicant with either HostAP or the WLAN Driver Loader
doesn't require a different setup. You must make
sure that the wireless card that you intend to use with WLAN Driver
Loader supports WPA in both the card firmware and the Windows NDIS
driver. See the sidebar Bleeding-Edge Warning for details on how some
WPA-enabled cards may not work.

The only difference between running wpa_supplicant with HostAP and
WLAN Driver Loader is what interface you call from the shell. HostAP
interfaces are always wlanX, typically
wlan0. For all of the cards we tried with WLAN
Driver Loader, the interface came up as eth1.

In the hostap source directory is a subfolder
that contains the wpa_supplicant. Building it from source is easy:

# cd wpa_supplicant
# make

Again, there is no make install, so you must copy
the generated executables to where you want them: wpa_supplicant and
wpa_passphrase, and the configuration file
wpa_supplicant.conf.

According to the README file included with the source, wpa_supplicant
is designed to run as a background daemon. A frontend program that
provides a user interface is planned but is not yet available.

On currently available access points, there are two possible
operating modes for WPA:

WPA-PSK (pre-shared key)

Also called "WPA-Personal" by the
Wi-Fi Alliance; this somewhat resembles WEP in that it allows you to
use an identical key (a pre-shared key) on both the access point and
the client. The access point, acting as the WPA Authenticator, uses
this pre-shared key to generate a master session key.

WPA-EAP

Also called "WPA-Enterprise" by the
Wi-Fi Alliance; this relies on an external authentication server,
most likely RADIUS, and the EAP used by 802.1x. The master session
key is generated by the Authentication Server and then passed to the
access point, which authenticates the client with that key.

In both cases, WPA implements a 4-Way Key Handshake and Group Key
Handshake, which generates and exchanges data encryption keys between
the Authenticator (access point) and Supplicant (client). The only
difference between the two methods is where the master session key is
generated.

You want to start wpa_supplicant as a daemon, give it the path to the
configuration file, and specify the wireless interface. In most
cases, you can use the line shown in Example 4-1.

Example 4-1. Launching wpa_supplicant

# /path/to/ wpa_supplicant -Bw -c /path/to/ wpa_supplicant.conf -iwlan0

This makes the process fork into the background and wait for the
wlan0 interface, so you can insert this command
into an appropriate place in your startup environment. WPA handshakes
must be complete before data frames can be exchanged, so
wpa_supplicant must be started before a DHCP client, for instance.

wpa_supplicant must be running when using a WPA-protected wireless
network, so it should be started from system startup scripts using
the command shown in Example 4-1, or it can be
called from the pcmcia-cs scripts if you are using
a PC card.

To enable WPA support using the pcmcia-cs scripts,
add these lines to /etc/pcmcia/wireless.opts:

MODE="Managed"
WPA="y"

Add the following code to the end of the start
action handler in /etc/pcmcia/wireless:

if [ $WPA = "y" -a -x /usr/local/bin/wpa_supplicant ]; then
/usr/local/bin/wpa_supplicant -Bw -c/etc/wpa_supplicant.conf -i$DEVICE
fi

Finally, add the following code to the end of the
stop action handler in
/etc/pcmcia/wireless:

if [ $WPA = "y" -a -x /usr/local/bin/wpa_supplicant ]; then
killall wpa_supplicant
fi

The combined effect of these changes make cardmgr start up
wpa_supplicant when the card is plugged in. wpa_supplicant waits
until the interface is set up, and then negotiates keys with the
access point.

The example wpa_supplicant.conf file can be used
to generate a configuration for your environment. The file needs at
least two mandatory parameters, and it has several options depending
on how your network is configured. The general file format should be
as in the example below. Empty lines and lines starting with # are
ignored.

network={
ssid="locked-down"
psk="s00pers3cr3t"
key_mgmt=WPA-PSK
pairwise=CCMP TKIP
group=CCMP TKIP
}

Here is a list of the possible fields in the configuration file:

ssid=

A mandatory field that can be either an ASCII string in quotes or a
hex string.

bssid=

Optional, only needed if your network uses a BSSID.

key_mgmt=

A list of accepted key management protocols. Options are
WPA-PSK, WPA-EAP, and
NONE. If not set, this defaults to
WPA-PSK WPA-EAP.

pairwise=

A list of accepted pairwise (unicast) ciphers for WPA. Options are
CCMP (AES encryption), TKIP, or
NONE. If not set, this defaults to CCMP TKIP.

group=

A list of accepted group (broadcast/multicast) ciphers for WPA.
Options are CCMP, TKIP,
WEP104, and WEP40. If not set,
this defaults to CCMP TKIP WEP104 WEP40.

psk=

A mandatory field when using WPA-PSK. This field can be entered as 64
hex digits or as an ASCII passphrase. The ASCII passphrase must be at
least 8 characters in length and can be a maximum of 63 characters.

In our example configuration, we are connecting to a WPA-PSK network,
and we have chosen to put the ASCII passphrase in the text
configuration file. If you want more protection, the included tool
wpa_passphrase can be used to generate 256-bit keys from an ASCII
passphrase. This tool uses a fair amount of CPU time, so it should be
used only when the passphrase has actually changed.

If you don't have WPA set up on your access point,
see Section 4.4.3.2, which
provides information on setting up a Linksys access point for WPA.

wpa_supplicant has an experimental interface for integrating with
Xsupplicant. This allows you to connect to a WPA-EAP network by
having Xsupplicant manage the 802.1x and EAP authentication. In order
for this to work properly, Xsupplicant must be modified to send the
master session key to wpa_supplicant after successful EAP
authentication.

The latest wpa_supplicant code includes an
xsupplicant.patch that can be used to patch the
source code for Xsupplicant. However, this patch has been merged into
the Xupplicant CVS code, so we recommend you check out CVS code
instead of dealing with the separate patch.

4.4.3.1 Xsupplicant

The folks at the Open1x project build the Xsupplicant
software, available at http://www.. The latest stable
release is Version 0.8b. However, for our purposes, we need the CVS
code, which you can check out from the SourceForge CVS server using
the following commands (press Enter when prompted for a password):

# cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/open1x login
# cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/open1x co xsupplicant

These commands check out the CVS code and deposit it in a newly
created xsupplicant directory.

Xsupplicant requires that Openssl 0.9.7 or greater be installed.
Mandrake, Fedora, and Red Hat users can install the
openssl package, Debian users can run
apt-get install openssl, and the source can be
downloaded from http://www.openssl.org. Most distributions
already have this package installed by default, but you may need to
upgrade it to ensure that you have the version required.

In order to get the CVS code running, you must install the
automake1.7 and autoconf2.5
packages (or more recent compatible versions). Once these are
installed, compiling from source is straightforward:

# cd xsupplicant
# ./configure
# make
# make install

This installs xsupplicant and some related tools
in /usr/local/bin. However, the CVS
make install does not install a
config file, so you must copy the sample
etc/xsupplicant.conf to
/etc/1x/1x.conf (this is the default location of
the conf file).

Edit the 1x.conf file. Many of the defaults can be left in
place, but you must change a few particulars starting with the
identity, then moving on to the EAP type. Although the sample
configuration file gives you a starting point for each type of EAP,
we'll use EAP-MD5 because it's easy
to implement and doesn't require us to generate a
certificate. After that, you need to configure the phase2
authentication type and chap:

identity =

What Xsupplicant responds with when presented with an EAP ID Request.
This is typically the username, and because this can be an arbitrary
string, you should enclose it with a <BEGIN ID> and <END
ID>.

eap-md5

In this section, you must enter a username and password.

phase2_type

Here you must specify the type of phase2 authentication. The default
is chap, which we use for our example.

chap

In this section, you must enter a username and password.

If you're uncomfortable entering confidential
information into clear text files, Xsupplicant can be called from the
command line with switches that allow you to enter your username and
password with the -u and -p
options. However, these options allow anyone who can execute a
ps command on your system to see your password.

Xsupplicant can be used both to authenticate your Linux machine to an
802.1x server as well as in combination with wpa_supplicant to
connect to WPA networks.

In either case, Xsupplicant must be activated after the interface is
brought up so it can transmit authentication information; Xsupplicant
is unlike wpa_supplicant, which must complete the WPA handshakes
before any data can be transmitted.

After you have entered all of the correct information into the
1x.conf file, call Xsupplicant from the command
line:

# xsupplicant -i wlan0 -D

This command line puts Xsupplicant into daemon mode after it receives
the password. Put the 1x.conf file in the
default location so you don't need to specify the
location of the conf file. This command allows
you to authenticate against any 802.11x server.

To use
Xsupplicant in combination with
wpa_supplicant to connect to a WPA-EAP network, you must change a few
things:

First, you must edit the wpa_supplicant.conf
file and change the key_mgmt entry to
WPA-EAP.

Now you can start Xsupplicant, but it must be started with an extra
command line switch:

# xsupplicant -I wlan0 -D -W

The -W switch tells Xsupplicant that it must
communicate the master session key that it obtains from the
802.11X/EAP server back to wpa_supplicant.

Xsupplicant also comes with some example ifup and
ifdown scripts in the tools
directory of the source tarball. We suggest that you use these
scripts instead of the normal distribution scripts when you wish to
bring up or down an interface that uses 802.1x
authentication.

4.4.3.2 Example WPA setup on a Linksys access point

All of our testing with WPA-PSK and WPA-EAP was done using a Linksys
WRT54G Wireless Router. With Version 2.0 and above of firmware, the
WRT54G is capable of both WPA methods as well as TKIP and AES
encryption.

Figure 4-6 shows the configuration necessary for a
WPA-PSK setup.

Figure 4-6. WPA-PSK setup for a Linksys WRT54G

Figure 4-7 shows configuration for a WPA RADIUS
setup.

Figure 4-7. WPA RADIUS setup for a Linksys WRT54G

4.4.3.3 WPA RADIUS setup details

In order to make this work, we set up a Mandrake 9.2 system as a
dedicated RADIUS server. For a RADIUS server, we installed the
freeradius packages and their dependencies with
urpmi freeradius. RedHat, Fedora, and Debian users
should be able to install the freeradius
packages similarly on their systems. We did not attempt to compile
the source code for our testing, but it can be downloaded from
http://www.freeradius.org.

FreeRadius supports a wide variety of database backends, including
LDAP, MySQL, and others. This was major overkill for our purposes. In
order to run FreeRadius, we had to edit two files:

/etc/raddb/users

We didn't use any backend database for users, so we
simply added several test users to this file. A sample user entry is
shown here:

"roger"       Auth-Type := Local, User-Password =  = "useless"
Reply-Message = "Hello, %u"

/etc/raddb/clients.conf

For each client of the RADIUS server, you can define an entry with a
shared secret. This isn't particularly secure,
because RADIUS shared secrets are sent in the open with no encryption
(for this reason, you should use a wired link on a physically secured
network between the RADIUS server and access point). If this shared
secret were compromised, it would not compromise the integrity of the
802.1x-protected communication. However, an attacker with knowledge
of the secret and physical access to your network could replace
either the RADIUS server or access point. We defined an entry for our
Linksys WRT54G and made sure that we entered the same shared secret
here as we did in the Linksys setup:

client 10.42.7.14 {
secret          = s00pers3cr3t
shortname       = wrt54g
nastype         = other     
}

Once we edited these files, we started FreeRadius manually with
debugging enabled so we could watch for any problems:

# /usr/sbin/radiusd -x

At this point, we were able to use the combination of Xsupplicant and
wpa_supplicant described earlier in the chapter to establish a WPA
link with the WRT54G, and authenticate through to the RADIUS
server.