When I started working with xsupplicant, I started with an Orinoco Gold card. It wasn’t a hard choice–Orinoco cards were so popular at one point that nearly everybody has at least one lying around. Even if you don’t have a PC Card lying around, you probably have a laptop with a Hermes chipset somewhere. Lucent was successful in making the Hermes a standard OEM part when a laptop vendor wanted to add 802.11. Many of the initial 802.11 cards supplied by laptop vendors were based on the Hermes chip, and use the same software as the PC Card. (Many of them use the mini-PCI form factor, but they are essentially a PCI-to-PC Card bridge; Linux will therefore detect them as a PC Card.)

Getting the Orinoco card running with xsupplicant is a slightly involved process. It requires two patches to fix unwanted behavior. Like many drivers, the Orinoco driver would reset the card if a new WEP key was configured. In the days of single-key static WEP, this was acceptable. However, the whole point of 802.1X is that you can dynamically push keys into the driver. There is a small patch distributed with xsupplicant to allow dynamic keying. A second patch is required to disable promiscuous mode.

Requirements

1. orinoco_cs 0.13e. The dynamic keying patch distributed with xsupplicant is written against orinoco_cs version 0.13e. Many Linux distributions using the 2.4 kernels ship 0.13d, so you will need to update the driver. You can obtain it directly from David Gibson’s distribution site.

2. Firmware update. I used the latest firmware version I could find on the Proxim support site (8.42, I think). The firmware update utility is available only for Windows, so updating firmware from an old card will probably require a Windows machine somewhere.

3. patch. There are two patches to apply, and not all installations may have installed the utility. If you don’t have it, it should be easy to get from your current distribution’s package system.

4. xsupplicant rekey patch. This is distributed with xsupplicant (drivers/Linux/rekey_patch_orinoco-0.13e), so if you already have xsupplicant, you are good to go.

5. promiscuous mode fix. There’s a second patch you will need to disable promiscuous mode in the driver; it can be downloaded from here from the University of Twente (Netherlands). I suspect that this patch is required because something in xsupplicant that calls libpcap will put the driver into promiscuous mode, and that breaks frame reception to higher protocol stack layers. This is just a theory; I’d be interested in why it’s required if anybody knows.

Building and installing the new driver

Like most other drivers, this driver is a kernel module. If you have a complete kernel configuration, you can just build the module in place and install over the earlier version. (You might also be able to integrate it into your kernel source tree, but doing so isn’t strictly necessary.)

To start building the driver, extract its source tree.

# tar -xvzf orinoco-0.13e.tar.gz

Apply the patches to the source distribution:

# cd orinoco-0.13e
# patch -p0 < ~/xsupplicant-0.8b/drivers/Linux/rekey_patch_orinoco_0.13e
# patch -p0 < ~/orinoco-no-promisc.patch

Build and install the software, just like any other driver. As always, be sure to update module dependencies after installing a new driver.

# make
  (see the output of compilation)
# make install
  (watch the module go to /lib/modules/...)
# depmod -a

Using the driver

When the Orinoco card is detected, the system will load orinoco_cs and create an Ethernet interface. If you have a build-in Ethernet interface (as most laptops do), the newly created interface will be “eth1″. Configure it and run xsupplicant as described in the previous post. If you’re watching your system log, you should see messages from the Orinoco driver indicating “orinoco_set_multicast_list: ignoring promisc setting” during the 802.1X negotiation. If you’re not, the promiscuous mode patch isn’t applied to the driver that is currently being loaded.

Related link: http://www.open1x.org

Of all the methods available to authenticate wireless LAN connections, Protected EAP (PEAP) is possibly the most widely used. Rather than using digital certificates to authenticate users, with all the complexity that implies, PEAP can instead rely on a user password. Most organizations with a predominance of Microsoft clients have standardized on PEAP as the wireless authentication protocol of choice, which means that the slender minority of other operating systems need to conform to that requirement. I spent some time recently helping a few organizations get xsupplicant running PEAP on Linux.

xsupplicant is an implementation of 802.1X only. It depends on the wireless card’s drivers to bring the card up, associate with a network, and do all the low-level stuff. The main point of interaction between the two is that xsupplicant will push dynamically generated keys down in to the driver. xsupplicant is still a work in progress. Today, it only supports dynamic WEP, though I imagine that WPA support is coming quickly.

This article describes how to get xsupplicant itself working. There are a few details to worry about with cards, so I’ll post further details on the cards that I’ve used in the future.

Environment

I’ve used two Linux systems with xsupplicant. One is based on the latest Debian unstable distribution (”sid”), and the other was a SuSE 9.0 system. Both use 2.4 series kernels.

I’ve now used a couple of different cards with xsupplicant. One is an old Hermes-based card (essentially a mini-PCI Orinoco Gold card), and the other was an Atheros-based Linksys dual-band/tri-mode a+b/g card.

The last major packaged release of xsupplicant is 0.8b, which was released on December 11. Newer code has been checked into CVS since then, and a current CVS version is quite a bit different. The configuration file from the CVS version (retrieved March 2004) isn’t compatible with the configuration file from the December packaged distribution. I was unable to get the CVS version to run cleanly, but the 0.8b version ran just fine.

Requirements

1. OpenSSL, version 0.9.7 or later. All the commonly used 802.1X authentication protocols work with TLS. EAP-TLS uses the certificate exchange directly as authentication; TTLS and PEAP use TLS to authenticate the network to the user and provide security for the user-to-network authentication. xsupplicant uses the OpenSSL TLS implementation, so you will need to have a development version of OpenSSL installed. Chances are that you can install this from your distribution’s package system.

2. libpcap and libdnet.. xsupplicant 0.8b requires these two libraries, which perform packet capture and miscellaneous network functions. The CVS version has been rewritten so as not to require them, but I had trouble making it work the day that I fetched the CVS tree. Chances are that you can fetch these from your distribution’s package system, too. Debian Linux has a name clash–libdnet is the DECnet library, not Dug Song’s “dumb” networking library. Due to the name clash, you’ll either have to rewrite the xsupplicant configuration script tests, or just install libdnet from source.

3. Perhaps most importantly, 802.11 should already be working!. Many of the “wireless” problems that you will encounter are really PC Card problems. Obviously, you will not be able to attach to an authenticated network until building and configuring xsupplicant, but you should be able to insert your wireless card and have it be recognized by the system. Card Services will generally sound a high-pitched beep when a card is inserted to indicate it is recognized, resources were successfully allocated, and the driver was loaded. (A second low-pitched beep may follow indicating a configuration failure, but that is OK. Chances are that you want your ultimate configuration to run xsupplicant, so it’s acceptable at the outset to not have configuration support immediately.) With the driver successfully loaded, you should be able to run iwconfig and obtain statistics from the driver.

4. Driver support for dynamic WEP. One of the biggest things that 802.1X enables to improve the security of wireless networks is that keys for the radio layer can be provisioned dynamically. One of the problems with some earlier cards is that the drivers assumed there would only be one WEP key in use on the network at any time. Therefore, whenever the key is changed, it is obviously time to reset the card to make the new key take effect. Resetting the card on key change is problematic because it can push the card into a vicious loop. After authentication completes, the dynamic key is pushed into the card, which causes the card to reset, which triggers another authentication and key generation, which pushes a new key into the card, and so on…

By definition, any card you want to use with xsupplicant should support the use of dynamic keys. Many modern cards have driver support for dynamic WEP already, but a few older cards require patches. The popular Hermes-based Orinoco 802.11b cards fall into the latter category. Depending on the driver, you may also need to rebuild your kernel (or at least get a copy of your kernel’s configuration) in order to compile a driver.

Compiling and installing xsupplicant 0.8b

There isn’t much to say about installing the code. Generally speaking, it follows the same routine that any other open-source package. Fetch the code from sourceforge, and compile in the standard Unix way:

# tar -xzvf xsupplicant-0.8b.tar.gz
  (output for filenames in the tarball)
# cd xsupplicant
# ./configure
  (output for configuration tests)
# make
  (output for build)
# make install
  (output for install)

As a result of the build, you get three executables installed; the only one you are likely to use is /usr/local/bin/xsupplicant.

Configuring xsupplicant

When run, Xsupplicant searches for its configuration file in /etc/1x. The config file, /etc/1x/1x.conf, does not get installed by default, but it’s easy enough to copy over.

# mkdir -p /etc/1x
# cd etc
# cp xsupplicant.conf /etc/1x/1x.conf

The CVS
(Note: The CVS version uses a default file name of /etc/xsupplicant.conf, but you can symlink /etc/xsupplicant.conf to /etc/1x/1x.conf)

You specify the user identity, possibly the password, and the root CA certificate in the configuration file. Passwords are stored in cleartext, so you may wish to have the system prompt for the password to avoid putting sensitive information in configuration files. When no password is in the file for the network you are connecting to, xsupplicant will prompt the user.

You must have the CA certificate that will be used to validate that you are connecting to the right network. xsupplicant does not have a configuration option to disable certificate validation. The configuration file appears to request the root CA in PEM format; you may need to use OpenSSL to convert your root certificate into the right format. (See the section at the end for more details.)

In the configuration file, settings can be stored as part of a profile for an SSID. If I were to connect to a network named “batnet”, the configuration file might have some entries that looked like this:

batnet:id = msg
batnet:pref = peap
batnet:phase2auth = MS-CHAPv2
# defaults to same as phase 1 ID
# batnet:phase2id = msg
batnet:random_file = /dev/urandom
batnet:root = /etc/1x/MyCA.pem

xsupplicant will need to be integrated into your configuration startup. The PC Card subsystem on Linux can run scripts to configure cards, and you will probably want to integrate the entire startup script to connect to a network, authenticate to it, and run a DHCP client.

Connecting and authenticating to a network

Step 1: Configure the network.You need to use the Linux utilities to connect to a network. The first step is to use iwconfig, or whatever other method your driver may require, to select a network and put in a dummy WEP key. The dummy key is used to indicate to the driver that it should run in encrypted mode; xsupplicant will replace the key after successful authentication. The most common way of configuring the connection is to use iwconfig to plumb a key and configure the network, and then use ifconfig to bring the interface up and start searching for the network:

# iwconfig eth1 key 12345678901234567890123456
# iwconfig essid essid "batnet"
# ifconfig eth1 up

Depending on the driver, your interface name may not be “eth1″. Some drivers may use the “wlan” prefix, and the Atheros driver uses a prefix of “ath”.

Step 2: Run xsupplicant. Use the “-i” option to indicate which interface it should run on. Although the documentation refers to a “-n (networkname)” option, it did not appear to be implemented in xsupplicant 0.8b.

# xsupplicant -i eth1
Calling do_eapol, with device eth1
Setup on device eth1 complete
Done with init.
Loading profile for batnet from /etc/1x/1x.conf.
Sending EAPOL-Start #1
Connection Established, authenticating...
Please Enter Your Password :
PEAP Version changed to 0
Authentication Succeeded
EAPOL Key processed: broadcast [2] (13 bytes)
Successfully set WEP key  [2]
EAPOL Key processed: unicast [1] (13 bytes)
Successfully set WEP key  [1]
Successfully set the WEP transmit key  [1]

Note: Certificate conversions

It is not always guaranteed that you will get the CA certificate in the format you want. Many CAs will give you the certificate in DER format, but xsupplicant appears to want the key in PEM foramt. Both of the CAs I have worked with recently handed out the certificate in DER format, so I had to use OpenSSL to convert between the two:

# openssl x509 -inform DER -outform PEM -in MyCA.der -out MyCa.pem

For the curious that wish to see all the fields in the certificate, take a look with the following command:

# openssl x509 -in MyCA.pem -text

OpenSSL converts between certificate formats very well; see the X.509 documentation for full details.

I wrote a blog entry the other day about building a client-side DNS subversion tool. After poking around a bit more, I’ve found some relevant links. Here is a list of alternate TLD servers that follow various policies for establishing new TLDs.

Bucking the “one true root server” ethic certainly has a colorful history. The best known alternate root was probably AlterNIC, which had a flurry of activity back in 1997 (including the arrest in Toronto of Eugene Kashpureff, AlterNIC’s founder.) Remember him? He hijacked InterNIC (remember them?) to protest the way that the root servers were administered. He also spent at least 55 days in jail, was extradited from Toronto, and eventually pled guilty to fraud charges, despite having earlier stated that he believed he committed no crime. All of that for temporarily rerouting InterNIC’s traffic to AlterNIC for a couple of days in July of 1997. (Of course, he probably shouldn’t have done it twice, and fleeing the country probably didn’t go over too well…) I can find no record of his actual sentencing.

It appears that alternic.org is now down, and alternic.net has been reclaimed by a domain squatter.

While it is a very impressive feat to circumvent the DNS and expose the inherent weaknesses of those who would claim authority over the Internet, I propose a more grass roots solution. I want to see an “Advanced” tab on the DNS configuration page of every laptop and desktop on the planet. It should allow me to specify a many-to-many mapping of DNS servers to try for any number of arbitrary domains. This list should be tried first, overriding the default DNS servers specified elsewhere or by DHCP. And I want to see a “retrieve settings from web address” box that will automatically load these settings from a URL that the user specifies. It would be nice to see these settings in all of the home routers and wireless points on the planet, as well.

With that simple feature, the politically charged hierarchy of the current domain root system will neatly be sidestepped. And good heavens, there is certainly a business model in there somewhere. It’s no use whining that the powerful ad-hoc nature of the Internet has been co-opted. It’s time to take it back.

Should the DNS system be overhauled, or is the stability of the Internet something best left to the professionals?

I’m really surprised nobody has written an open source tool to disrupt
this whole TLD silliness. It’s very easy to set up your own TLDs in
BIND (I’ve already written about it at length.) With a tiny shim
program, it should be trivial to redirect requests for new, funky TLDs
to an arbitrary root server.

If such tools were widespread on Windows and OS X, that would completely disrupt the ICANN and all of this “.mobile” and “.aero” and “.name” silliness. Alternative root servers could come in vogue that provide a different way of mapping IP addresses to names. “Private” DNS servers could even be an antidote to the sue-’em-all-and-let-the-courts-sort-’em-out hysteria of preemptive intellectual property protection that currently dominates the domain name industry.

Think of the current domain resolution system as the phone comany’s published phone book. While the phone book is certainly useful for looking up people and businesses, you probably don’t carry it with you or consult it to look up the numbers of your friends and family. If you’re like most people, you use a private phone book (or your personal mobile phone) for that.

If you could choose a new root name server for any number of arbitrary top level domains, then you could share the same view of name-to-number mappings as anyone else who also used that root server. Rather than a pyramid with the ICANN and traditional name servers at the summit, IP to name mapping would suddenly become peer to peer. It’s the difference between sharing private phone lists between friends and enforcing one, true mapping of names to numbers called “the phone book”.

Unfortunately, the few companies who have attempted this technique made it a proprietary service and foolishly tried to build a business on it. I guess that’s why I can’t remember any of their names. (Links, anyone? I know I’ve seen a couple of upstarts offering this service for a fee, complete with a proprietary resolver library…) IMHO, this business model is about as effective as trying to charge people money for maintaining their own personal information.

This functionality is already present in DNS, is fairly straightforward to bring about in Linux and BSD, and is just waiting for some enterprising person to enable it on the other major platforms. All we need is a simple, more flexible, open source resolver client.

Remember kids, the hierarchical appearance of the Internet is an illusion. It only seems to exist because people are afraid to change their default settings.

Are unrestricted TLDs a good idea, or does this herald the apocalypse of the Internet?