802.11 interfaces act like Ethernet interfaces once they are active, but they have many more configuration options than Ethernet interfaces because of the underlying radio technology. Rather than have each driver responsible for implementing its own configuration utility and reporting mechanisms, the Wireless Extension API was developed to allow all drivers to implement common functionality and use common configuration commands. Wireless extensions are also a great help to application developers needing to get details from the interface because they can do it in a device-independent way. For example, xsupplicant makes use of wireless extensions to set WEP keys on an interface without having to understand each driver's operations for setting keys. (At press time, system calls for WPA keying were not yet part of the official wireless extensions release.)
Compiling and Installing
Wireless LAN extensions are enabled with the CONFIG_NET_RADIO kernel configuration option. CONFIG_NET_RADIO-enabled kernels collect wireless statistics and expose additional data structures used by most drivers. Most distributions that include kernels with wireless extensions also include the wireless tools. If more recent versions are required, you may download them from http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux, although it is probably easier to wait for your distribution's kernel source to integrate the latest version and rebuild the kernel.
Interface Configuration with Wireless Tools and iwconfig
The main command-line tool for managing a wireless-extension-enabled driver is iwconfig, which is designed to be a "wireless ifconfig." It can be used to set the radio interface parameters before using ifconfig to set traditional network parameters.
When run with no parameters, iwconfig displays a list of system interfaces. Interfaces that are not wireless will report that they have no wireless-specific data, while interfaces that do report wireless data will dump out the data that they have. Not all drivers implement all features. When iwconfig is run on a system with an old Orinoco card and an Atheros CardBus card, for example, the output will probably resemble this:
[root@bloodhound]# iwconfig lo no wireless extensions. eth0 no wireless extensions. eth1 IEEE 802.11-DS ESSID:"11b-is-slow" Nickname:"HERMES I" Mode:Managed Frequency:2.457GHz Access Point:00:E0:03:04:18:1C Bit Rate:2Mb/s Tx-Power=15 dBm Sensitivity:1/3 RTS thr:off Fragment thr:off Encryption key:off Power Management:off Link Quality:46/92 Signal level:-51 dBm Noise level:-94 dBm Rx invalid nwid:0 invalid crypt:0 invalid misc:0 ath0 IEEE 802.11 ESSID:"11a-is-very-fast" Mode:Managed Frequency:5.28GHz Access Point: 00:0B:0E:00:F0:43 Bit Rate:36Mb/s Tx-Power:off Sensitivity=0/3 Retry:off RTS thr:off Fragment thr:off Encryption key:E452-94AC-09DB-2200-1256-6D7D-74 Security mode:open Power Management:off Link Quality:31/94 Signal level:-64 dBm Noise level:-95 dBm Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0
Both cards report the frequency of operation and some statistics about the quality of reception. The "nickname" reported by the Orinoco card is not reported by the Atheros card because it is a feature that is not implemented by the Atheros driver. (By default, the nickname is set to "HERMES I" after the name of the Lucent chipset used in the Orinoco card.)
Wireless Extensions reports information on the link quality in two ways. It reports a noise floor and signal level, and both are printed out by the driver. The signal to noise ratio is the difference between them. In the previous example, the SNR on eth1 was 43 dB, and the SNR on ath0 is 31 dB. The Link Quality statistic printed out by the driver reports the RSSI and the noise floor. In the previous example, the card is reporting an RSSI of 31 dB over a noise floor of -94 dBm.
Finding networks
Some drivers support the use of wireless extensions to build a list of networks in the area. Rather than configuration, use the iwlist command to get information from the card. As arguments, it takes the interface and a subcommand. scan will print out the list of information discovered in the area. Root privileges are required to retrieve scan data.
root@bloodhound:~# iwlist eth1 scan eth1 Scan completed : Cell 01 - Address: 00:07:50:D5:CE:88 ESSID:"LuminiferousEther" Mode:Master Frequency:2.417GHz Quality:0/10 Signal level:-70 dBm Noise level:-256 dBm Encryption key:on Bit Rate:1Mb/s Bit Rate:2Mb/s Bit Rate:5.5Mb/s Bit Rate:11Mb/s Cell 02 - Address: 00:09:5B:72:12:58 ESSID:"Mom's House" Mode:Master Frequency:2.467GHz Quality:0/10 Signal level:-22 dBm Noise level:-256 dBm Encryption key:on Bit Rate:1Mb/s Bit Rate:2Mb/s Bit Rate:5.5Mb/s Bit Rate:11Mb/s Cell 03 - Address: 00:0D:72:9B:FE:69 ESSID:"2WIRE086" Mode:Master Frequency:2.442GHz Quality:0/10 Signal level:-28 dBm Noise level:-256 dBm Encryption key:on Bit Rate:1Mb/s Bit Rate:2Mb/s Bit Rate:5.5Mb/s Bit Rate:11Mb/s Bit Rate:22Mb/s Bit Rate:6Mb/s Bit Rate:9Mb/s Bit Rate:12Mb/s
Setting the network name
To connect to a network, the first task is to select the network that will be joined. That is done by configuring the SSID with the essid[*] parameter. If the network name includes a space, it must be enclosed in quotation marks. The network interface probably will not become active and start searching for the network until you use ifconfig to activate it. Progress of the scan can be checked by repeatedly running iwconfig and looking at the frequency. For example, the scan searching out an AP on channel 56 might look something like this:
[*] I use the term SSID in this book to refer to a network name. Some drivers, including the WaveLAN drivers, use ESSID instead. The distinction is that an ESSID is a network name assigned to an extended service set, not any old service set.
[root@bloodhound]# iwconfig ath0 essid "Space Cadet" [root@bloodhound]# ifconfig ath0 up [root@bloodhound]# iwconfig ath0 . . . Mode:Managed Frequency:2.412GHz Access Point: 00:00:00:00:00:00 . . . [root@bloodhound]# iwconfig ath0 . . . Mode:Managed Frequency:2.447Hz Access Point: 00:00:00:00:00:00 . . . [root@bloodhound]# iwconfig ath0 . . . Mode:Managed Frequency:5.17GHz Access Point: 00:00:00:00:00:00 . . . [root@bloodhound]# iwconfig ath0 . . . Mode:Managed Frequency:5.28GHz Access Point: 00:0B:0E:00:F0:43 . . .
When the card discovers the network, it will associate with the AP and report the AP's MAC address in the iwconfig output. Associating with the network is merely the first step. Other configuration may be necessary before the logical network connection.
Some drivers have problems if the channel is automatically configured. If the channel is hard set, the driver may not search. To get a driver stuck on a channel to search, disable the card with cardctl eject, reset the SSID, and then reenable the interface with ifconfig.
Setting the network channel
Different cards support different operating frequencies. On a modern Atheros-based card, the entire ISM band is supported up to channel 14, and all three of the 5 GHz bands are supported as well. With drivers that support the operation, it is possible to get a list of supported channels by using the iwlist command:
root@bloodhound:~# iwlist ath0 channel ath0 255 channels in total; available frequencies : Channel 01 : 2.412 GHz Channel 02 : 2.417 GHz Channel 03 : 2.422 GHz Channel 04 : 2.427 GHz Channel 05 : 2.432 GHz Channel 06 : 2.437 GHz Channel 07 : 2.442 GHz Channel 08 : 2.447 GHz Channel 09 : 2.452 GHz Channel 10 : 2.457 GHz Channel 11 : 2.462 GHz Channel 12 : 2.467 GHz Channel 13 : 2.472 GHz Channel 14 : 2.484 GHz Channel 34 : 5.17 GHz Channel 36 : 5.18 GHz Channel 38 : 5.19 GHz Channel 40 : 5.2 GHz Channel 42 : 5.21 GHz Channel 44 : 5.22 GHz Channel 46 : 5.23 GHz Channel 48 : 5.24 GHz Channel 50 : 5.25 GHz Channel 52 : 5.26 GHz Channel 56 : 5.28 GHz Channel 58 : 5.29 GHz Channel 60 : 5.3 GHz Channel 64 : 5.32 GHz Channel 100 : 5.5 GHz Channel 104 : 5.52 GHz Channel 108 : 5.54 GHz Channel 112 : 5.56 GHz Current Frequency:5.28GHz (channel 56)
The operating frequency can be selected in three ways. Most cards will hunt for an SSID if it is given to them as described previously. For cards that do not support scanning, the freq parameter can take an operating frequency directly, or the channel parameter can be used with the appropriate channel number, and the driver will derive the frequency from the channel number. The following two commands are equivalent:
[root@bloodhound]# iwconfig ath0 freq 2.432G [root@bloodhound]# iwconfig ath0 channel 4
Setting the network mode and associating with an access point
Most 802.11 stations are in either ad hoc networks or infrastructure networks. The iwconfig nomenclature for these two modes is Ad-hoc and Managed. Select between them by using the mode parameter:
[root@bloodhound]# iwconfig ath0 mode Ad-hoc [root@bloodhound]# iwconfig ath0 mode Managed
For stations in an infrastructure network, the ap parameter may be used to request an association with the specified MAC address. However, the station is not required to remain associated with the specified access point and may choose to roam to a different access point if the signal strength drops too much:
[root@bloodhound]# iwconfig ath0 ap 01:02:03:04:05:06
Setting the data rate
Most cards support multiple bit rates. iwconfig allows the administrator to choose between them by using the rate parameter. Bit rates can be specified after the rate parameter, or the keyword auto can be used to specify that the card should fall back to lower bit rates on poor-quality channels. If auto is combined with a bit rate, the driver may use any rate lower than the specified rate:
[root@bloodhound]# iwconfig ath0 rate auto
Configuring static WEP keys
The key parameter controls the WEP function of the driver. Keys can be entered as hexadecimal strings using the key subcommand. Enter the string without any delimiters, four digits at a time with dashes between the two-byte groups, or in the colon-separated byte form. The following commands are equivalent:
[root@bloodhound]# iwconfig ath0 key 0123456789 [root@bloodhound]# iwconfig ath0 key 0123-4567-89 [root@bloodhound]# iwconfig ath0 key 01:23:45:67:89
Many drivers support the use of 104-bit WEP keys as well. 104 bits is 13 bytes, or 26 hexadecimal characters:
[root@bloodhound]# iwconfig ath0 key 12345678901234567890123456 [root@bloodhound]# iwconfig ath0 key 1234-5678-9012-3456-7890-1234-56 [root@bloodhound]# iwconfig ath0 key 12:34:56:78:90:12:34:56:78:90:12:34:56
Although multiple keys can be entered using a bracketed index number, this capability is not used on many networks. Dynamic WEP key assignment through 802.1X is a much easier way to ensure the use of multiple keys, and is much more secure.
[root@bloodhound]# iwconfig ath0 key 0123-4567-89 [root@bloodhound]# iwconfig ath0 key 9876-5432-01 [2] [root@bloodhound]# iwconfig ath0 key 5432-1678-90 [3]
Once multiple keys have been entered, select one by entering the index number without a key value:
[root@bloodhound]# iwconfig ath0 key [2]
Activate WEP processing using key on and disable WEP using key off. These can be combined with an index number to select a new WEP key:
[root@bloodhound]# iwconfig ath0 key [3] on [root@bloodhound]# iwconfig ath0 key off
Finally, two types of WEP processing can be done. An open system accepts data frames sent in the clear, and a restricted system discards cleartext data frames. Both of these parameters can be combined with an index number:
[root@bloodhound]# iwconfig ath0 key [4] open [root@bloodhound]# iwconfig ath0 key [3] restricted
The key parameter may also be accessed with the encryption parameter, which may be abbreviated to as few characters as enc. I prefer to use key because it seems clearer to me, but you may choose whichever you like.
Tuning 802.11 parameters
iwconfig allows you to tune the RTS and fragmentation thresholds. The RTS threshold of most drivers is 2,347, which effectively disables RTS clearing. In an environment likely to have hidden nodes, it can be set using the rts_threshold parameter with iwconfig. rts_threshold can be abbreviated as rts.
[root@bloodhound]# iwconfig wvlan0 rts 500
The default value of the fragmentation threshold is 2,346. In noisy environments, it may be worth lowering the fragmentation threshold to reduce the amount of data, which must be retransmitted when frames are lost to corruption on the wireless medium. Set the parameter by using the fragmentation_threshold argument to iwconfig. It may be set anywhere from 256 to 2,356, but it may take on only even values. fragmentation_threshold may be abbreviated as frag.
[root@bloodhound]# iwconfig ath0 frag 500
802.11 stations maintain several retry counters. When frames are retransmitted "too many" times or wait for transmission for "too long," they are discarded. Two retry counters are maintained. The long retry counter, set by the retry parameter, is the number of times transmission is attempted for a frame longer than the RTS threshold. The short retry counter, set by the retry min parameter, is the number of times transmission will be attempted for a frame shorter than the RTS threshold. Unlike many drivers, iwconfig also allows for configuration of the maximum frame lifetime with the retry lifetime parameter. To specify a value in milliseconds or microseconds, append "m" or "u" to the value:
[root@bloodhound]# iwconfig ath0 retry 4 [root@bloodhound]# iwconfig ath0 retry min 7 [root@bloodhound]# iwconfig ath0 retry lifetime 400m
Introduction to Wireless Networking
Overview of 802.11 Networks
11 MAC Fundamentals
11 Framing in Detail
Wired Equivalent Privacy (WEP)
User Authentication with 802.1X
11i: Robust Security Networks, TKIP, and CCMP
Management Operations
Contention-Free Service with the PCF
Physical Layer Overview
The Frequency-Hopping (FH) PHY
The Direct Sequence PHYs: DSSS and HR/DSSS (802.11b)
11a and 802.11j: 5-GHz OFDM PHY
11g: The Extended-Rate PHY (ERP)
A Peek Ahead at 802.11n: MIMO-OFDM
11 Hardware
Using 802.11 on Windows
11 on the Macintosh
Using 802.11 on Linux
Using 802.11 Access Points
Logical Wireless Network Architecture
Security Architecture
Site Planning and Project Management
11 Network Analysis
11 Performance Tuning
Conclusions and Predictions