802.1x on Linux with xsupplicant
When WEP's flaws became apparent, the wireless industry started developing new protocols to address the published weak points. These new protocols grew up around the IEEE 802.1x framework, which is a way of using the Extensible Authentication Protocol (EAP) and all of its methods on a LAN link. 802.1x client software programs, called supplicants, were brought to market by operating system vendors as well as by third-party developers.
Linux, however, initially was left out of the 802.1x frenzy. Network administrators who supported power users were forced to rely on manual WEP-based solutions with MAC address filtering or VPNs to secure Linux before supplicants were widely available. Happily, now two open-source supplicants are bringing high-quality wireless security to Linux. This article describes the process of setting up xsupplicant, which is also known as Open1X.
The wireless extensions API originally was designed to provide a unified way of having programs interact with drivers. Like any API, it saves developers from having to know the details of how to interact with every card. 802.1x supplicants, for example, are able to use a wireless extensions system call to set keys, rather than using card-specific calls for every card that exists.
The wireless extensions interface has gone through several versions. WPA support was added in wireless extensions version 18 (WE-18). Some distributions using the 2.6 kernel already have WE-18 support. Older kernels need to be patched, however. My test laptop runs Slackware, which still is using the 2.4 kernel. The 2.4 kernel has support for version 16 of wireless extensions, but patches are available for version 2.4.30. Patch download locations appear in the on-line Resources for this article. Begin by applying two patches to the kernel source:
# patch -p1 ~/iw249_we17-13.diff patching file include/linux/netdevice.h patching file include/linux/wireless.h patching file include/net/iw_handler.h patching file net/core/dev.c patching file net/core/wireless.c # patch -p1 ~/iw240_we18-5.diff patching file include/linux/wireless.h patching file net/core/wireless.c
To keep modules straight, I often find it helpful when patching kernels to edit the Makefile to include an extra version number in addition to the patch level. My wireless extensions 18 kernel is built as 2.4.30WE18.
The most common tools used with wireless extensions are the wireless toolset, and the most common tool you will use is iwconfig. Wireless tools version 28 is the current version and supports WE-18. Grab the source code from the Web site (see Resources). A simple make command builds the tools.
Many cards are supported under Linux, but a handful of drivers have captured the bulk of the popularity:
MADwifi, the Multi-band Atheros Driver for Wi-Fi: Atheros-based cards have some of the best hardware support for 802.11a networking. Chances are good that if your card supports 802.11a, it uses an Atheros-designed chip.
Intel IPW drivers for Centrino chipsets: Intel sponsors open-source driver development projects for the various Centrino chipsets. Due to the sheer number of Centrino chipsets on the market, these drivers are widely used.
orinoco_cs: the first widely used 802.11 card was the Orinoco Gold card, based on the Hermes chipset. These cards were sold under a variety of names, and they all performed quite well in their day. Although the radio performance and throughput of these cards is no longer cutting-edge, the driver is well understood and often serves as a testbed for new ideas.
This article is not meant to be a definitive treatment of working with drivers. I use Atheros-based cards because I have an 802.11a network at home and want a dual-band card for packet analysis. Therefore, I am writing about MADwifi.
MADwifi has not released any packaged source files. To use the driver, you must download the code from CVS. The build files distributed with MADwifi use your current kernel. If you have patched the kernel to update wireless extensions, reboot before building MADwifi:
$ cvs -z3 -d:pserver:email@example.com: ↪/cvsroot/madwifi co madwifi $ cd madwifi $ make root@bloodhound:/home/user/madwifi# make install
Atheros-based cards do not use firmware. Instead, they have a binary-only object called the hardware abstraction layer (HAL). Atheros has interpreted FCC regulations in such a way that requires the HAL to be kept closed-source. The HAL serves the same purpose as firmware on other cards—it implements low-level operations for the driver. The HAL is distributed as a uuencoded file, so you must install the uudecode program to install the HAL. It probably is in the shell archive utilities package for your distribution, but the location may vary. The OpenBSD Atheros driver includes an open-source, reverse-engineered HAL, but it has not been ported yet to Linux.
The kernel modules built as part of the process are installed in your modules directory. The driver includes its own 802.11 support layer composed of the modules wlan, wlan_wep, wlan_tkip and so on. The hardware-specific part of MADwifi is composed of modules that begin with the prefix ath_: the driver ath_pci, the HAL ath_hal and rate adaptation algorithms (ath_rate_*). All the modules are installed in the net/ directory.
|Jarvis, Please Lock the Front Door||Aug 31, 2016|
|Contrast Security's Contrast Enterprise||Aug 30, 2016|
|illusive networks' Deceptions Everywhere||Aug 29, 2016|
|Happy Birthday Linux||Aug 25, 2016|
|ContainerCon Vendors Offer Flexible Solutions for Managing All Your New Micro-VMs||Aug 24, 2016|
|Updates from LinuxCon and ContainerCon, Toronto, August 2016||Aug 23, 2016|
- Jarvis, Please Lock the Front Door
- Download "Linux Management with Red Hat Satellite: Measuring Business Impact and ROI"
- Contrast Security's Contrast Enterprise
- illusive networks' Deceptions Everywhere
- Tech Tip: Really Simple HTTP Server with Python
- What I Wish I’d Known When I Was an Embedded Linux Newbie
- Happy Birthday Linux
- New Version of GParted
- All about printf
- Returning Values from Bash Functions
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide