802.1x on Linux with xsupplicant

Many of the well-known problems in 802.11 security are quite old and can be addressed by using 802.1x appropriately. Here's the client side.
Testing the Driver

In addition to having up-to-date wireless support in the kernel, you need to have a properly configured wireless networking subsystem. Many “wireless” problems encountered when dealing with 802.1x on Linux are PC card configuration problems. When the card is inserted, you should get a high-pitched beep indicating that Card Services has loaded the right driver. A second beep is used to communicate the status of the card configuration, so a second lower beep is fine because the configuration of the card hasn't been set up yet.

If the card is recognized and the right driver is loaded, try firing up a wireless network with no encryption and no authentication. Configure association to the network with iwconfig, and bring up the card with ifconfig. The MADwifi driver creates interfaces that begin with the prefix ath, so my interface is ath0. Depending on the driver you use, your interface may be different. When the card first comes up, you can see it scan for the network as the frequency reported by iwconfig changes. When the card successfully associates to a network, it reports the access point MAC address as well as the operating frequency. At that point, you should be able to ask the network for an IP address, using whatever tool is favored by your Linux distribution:

# iwconfig ath0 essid "clearnet"
# ifconfig ath0 up
# iwconfig ath0
ath0  IEEE 802.11g  ESSID:"etherclear"
      Mode:Managed  Frequency:2.412 GHz  Access Point: 00:0B:0E:2F:0A:40
      Bit Rate:12 Mb/s   Tx-Power:50 dBm   Sensitivity=0/3
      Retry:off   RTS thr:off   Fragment thr:off
      Power Management:off
      Link Quality=39/94  Signal level=-56 dBm  Noise level=-95 dBm
      Rx invalid nwid:107  Rx invalid crypt:0  Rx invalid frag:0
      Tx excessive retries:22  Invalid misc:22   Missed beacon:0
# dhcpcd -d -t 10 ath0
dhcpcd: MAC address = 00:20:a6:4c:ca:4b
dhcpcd: your IP address =

If you can associate to a network, your card is functional. Although it is not necessary to find out if you can obtain an IP address from an unencrypted network, it is helpful to know that the frame handling and network stacks are working and that DHCP service is configured correctly on the network. With the wireless network system having basic functionality, we can move on to providing security for it.


Two major supplicants exist for Linux: xsupplicant, also known as Open1X, and wpa_supplicant. This article discusses only the former. Before getting to work on xsupplicant, check the version of OpenSSL on your system. xsupplicant requires OpenSSL 0.9.7 or later to provide transport layer security (TLS) support. All the commonly used 802.1x authentication protocols require TLS, either for authentication directly with digital certificates (EAP-TLS) or as a protective tunnel for some other form of authentication (TTLS or PEAP). You need a development version of the packages to get the expected headers.

Download the source code from SourceForge (see Resources) At the time of this writing, the current release is 1.2pre1:

$ tar -xzf Xsupplicant-1.2pre1.tar.gz
$ cd xsupplicant
$ ./configure --with-madwifi-path=~/madwifi
. . .
Adding MADWIFI WPA support.
. . .
$ make

# make install

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

Certificate Wrestling

Secured EAP authentication generally depends on digital certificates. Certificate data is encoded using either the privacy-enhanced mail (PEM) format or the distinguished encoding rules (DER). My experience is that xsupplicant likes its certificates in PEM format, but many certificate authorities hand out certificates in the DER format. Fortunately, OpenSSL is quite good at converting between formats:

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

To see the actual data encoded within the certificate, you can use the openssl command to print textual output:

# openssl x509 -in MyCA.pem -text

How exactly you obtain the certificate is up to your network administrator. Many certificate authorities make the root certificate available on a Web page.

Configuring xsupplicant

When run, xsupplicant searches for its configuration file in /etc. The config file, /etc/xsupplicant.conf, is not installed by default, but it's easy enough to copy over:

# cp xsupplicant.conf /etc/xsupplicant.conf

Specify the user identity, possibly the password and the root CA certificate in the configuration file. Each network can have its own configuration by bracketing the entire network configuration. A simple configuration for a network that uses PEAP with MSCHAP-V2 for inner authentication might look something like this:

  identity = testuser
  eap_peap {
      root_cert = /usr/local/etc/myCA.der
      random_file = /path/to/random/source
      allow_types = eap_mschapv2
      eap-mschapv2 {
        username = testuser
        password = "testpw"

Linux has two random number devices, /dev/random and /dev/urandom. Both pull random numbers from a system entropy pool, but the former device returns only strong random numbers. As a result, I highly recommend using /dev/random as the random number device file. Many 802.1x implementations can cope with relatively large delays while waiting for a response. At the Interop Labs in Las Vegas in May 2005, we authenticated a user account through a multi-hop global distributed RADIUS system, so end-to-end latency was much higher than on most networks.

For testing purposes, certificate validation can be disabled by setting the root_cert location to NONE. Although useful for testing purposes, disabling certificate authentication removes the protections provided by the certificate and should not be done for normal deployments.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Unable to get Xsupplicant to work

Satish's picture


I am not able to get Xsupplicant to work for me.
Can somebody help?

Here are the network details:
SSID (Network Name: TTUnet
WEP data encryption Enabled
Automatically provided WEP key Enabled
IEEE 802.1x authentication Enabled
EAP type: Protected EAP (PEAP)
Protected EAP Authentication Method Secured password (EAP-MSCHAP v2)
EAP MSCHAP v2 Properties - Automatically Login Disabled

Here is the content of my /etc/xsupplicant.conf

network_list = all
default_netname = TTUnet
startup_command = echo "some command"
first_auth_command = dhclient %i
reauth_command = echo "authenticated user %i"
logfile = /var/log/xsupplicant.log
allow_types = all
identity = msg
eap-peap {
root_cert = NONE
chunk_size = 1398
random_file = /path/to/random/source
allow_types = all # where all = MSCHAPv2, MD5, OTP, GTC, SIM
eap-mschapv2 {
username = user
password = "passwd"

And I am using SUSE Enterprise Desktop Linux 10
I have my wireless adapter configured and works well with normal WEP/WPA networks.


Xsupplicant error

Jack's picture

why I have this error with starting ?

syntax error:

startup_command = /sbin/iwconfig eth1 essid aeriusEAP enc open
General Parse error!
There was a problem with the config file. We cannot continue.

wrong version

Anonymous's picture

remove the command, if you are using version 1.2.6 like i am then that command doesn't work for some reason. Remove it and other like "first_auth_command", then give it a try.

Geek Guide
The DevOps Toolbox

Tools and Technologies for Scale and Reliability
by Linux Journal Editor Bill Childers

Get your free copy today

Sponsored by IBM

8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
On Demand
Moderated by Linux Journal Contributor Mike Diehl

Sign up now

Sponsored by Skybot