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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- SourceClear Open
- Parsing an RSS News Feed with a Bash Script
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