Iwpriv, or the private extension, is the important companion tool to iwconfig:
Whereas iwconfig deals with setting generic standard-defined parameters, iwpriv enables driver-specific configuration changes. Iwpriv is used for setting wireless roaming with some 802.11 card drivers (e.g., wavelan_cs). The main implication of iwpriv in security testing and wireless protocol debugging is setting the card into a monitor mode. For Hermes chipset cards running under the Shmoo-patched Orinoco driver, the command to put such a card into the monitor mode is as
follows:
arhontus:~# iwpriv eth0 monitor <mode> <channel>
where the mode can be 1 (append Prism II headers-specific data to the frame, ARPHRD_IEEE80211_PRISM device type), 2 (monitor mode with no Prism II-specific info, ARPHRD_IEEE80211 device type), and 0 (turn the monitor mode off). For Prism chipset cards running under HostAP drivers, this would be the corresponding command:
arhontus:~# iwpriv wlan0 monitor <mode>
where the mode value 2 is ARPHRD_IEEE80211 device type, mode value 3 is ARPHRD_IEEE80211_PRISM device type, and mode value 0 is also turning the RFMON mode off. Interestingly, the Linux Wireless Extensions version 25 and
later iwconfig can be used to set Prism cards under HostAP into the monitor mode:
arhontus:~# iwconfig wlan0 mode monitor
This might make obsolete the use of iwpriv with the latest HostAP and also Madwifi versions. You can still set the device type and dumped headers data to both possible values with this:
arhontus:~# prism2_param wlan0 monitor_type <type>
where type 0 is IEEE 802.11 headers (ARPHRD_IEEE80211) and type 1 is Prism2 + IEEE 802.11 headers (ARPHRD_IEEE80211_PRISM).
HostAP drivers come with their own 802.11 frame parser called wlansniff in the sniff subdirectory:
arhontus:~# ./wlansniff -h
wlansniff [-h] [-b#] [auth] <wlan#>
-h = help
-b0 = do not show beacons
-b1 = show only one line of data for each beacon -b2 = show full beacon data
-auth = show only authentication frames
You need to put the card into the monitor mode (both ARPHRD_IEEE80211 and ARPHRD_IEEE80211_PRISM device types would do) before running wlansniff.
Finally, when you use iwconfig to set an Atheros chipset 802.11a card into the monitor mode the command is this:
arhontus:~# iwconfig wlan0 mode monitor
After executing this command, bring up the wireless interface (ifconfig wlan0 up). A simple vt_ar5k_monitor.sh shell script to do this can be found in the vt_ar5k/misc directory. You can also enable prism2-compatible headers appending with iwpriv wlan0 prism 1 command if necessary.
802.11 Basics: Prism Headers and RFMON Mode
The Prism monitor header we referred to earlier is not a part of the 802.11 frame header as defined by the IEEE standard. It is a physical layer header generated by the firmware of the receiving Prism chipset.
This header includes Received Signal Strength Indication (RSSI), Signal Quality (SQ), Signal Strength and Noise (in dBm), and Data Rate (in Mbps) parameters; watching it can be helpful. The Prism header is defined by a hex value different from the standard 802.11 header in the if_arp.h file on different
Unices:
/* Dummy types for non ARP hardware */
...
#define ARPHRD_IEEE80211 801 /* IEEE 802.11*/
#define ARPHRD_IEEE80211_PRISM 802 /* IEEE 802.11 + Prism2 header */
(This is an example from Linux if_arp.h.) We hope that now all references to ARPHRD_IEEE80211 and ARPHRD_IEEE80211_PRISM in the text are more understandable.
As for the RF monitor (RFMON) or monitoring mode itself, it is commonly confused with the promiscuous mode on the Ethernet (as in ifconfig eth0 promisc). These are two completely different modes.
Promiscuous mode on 802.3 networks is accepting all frames and it doesn't matter to whom on a LAN segment the frames are addressed by MAC. RFMON mode on 802.11 networks is passing all 802.11 frames information (usually dealt with by the client card firmware) to the end-user applications, thus allowing dumping and analysis of such frames. This is why so much attention is paid to the client card driver's ability to support RFMON and the ways of enabling the mode. Let's look at the practical example of a PCMCIA card in three possible states:
arhontus:~# ifconfig wlan0 up arhontus:~# tcpdump -i wlan0
tcpdump: WARNING: wlan0: no IPv4 address assigned tcpdump: listening on wlan0
tcpdump: WARNING: wlan0: no IPv4 address assigned tcpdump: listening on wlan0
0 packets received by filter 0 packets dropped by kernel
Again, no traffic can be seen, even though one of the wireless hosts is pinged from this machine. The traffic is encrypted with WEP; if it wasn't you would see the packets flying by, but you still won't see 802.11 frames. Now we put the card into the monitor mode and run tcpdump again:
arhontus:~# iwconfig wlan0 mode monitor arhontus:~# tcpdump -i wlan0
17:53:59.422074 Beacon ( ) [ 11.0 Mbit] ESS CH: b , PRIVACY 17:53:59.440055 Acknowledgment RA:0:90:4b:6:15:4f
17:53:59.442675 Acknowledgment RA:0:2:2d:8e:74:5e
17:53:59.524466 Beacon ( ) [ 11.0 Mbit] ESS CH: b , PRIVACY
Here they are! We hope this example is sufficiently convincing.
A few other utilities included with Linux Wireless Extensions are iwevent,
iwgetid, iwlist, and iwspy. Iwevent reports changes of settings such as ESSID, channel, mode, WEP, and network ID, as well as joining new access points or ad-hoc cells, dropped transmitted packets, and the registration or unregistration of new clients if the card is run in a master mode (acts as an access point under the HostAP drivers). As such, iwevent can be useful for creating network monitoring and even intrusion detection scripts. Iwgetid is an auxiliary utility that shows current wireless network parameters such as access point (AP) MAC address, interface mode, channel, and ESSID and can be useful in scripting together with iwevent. Iwspy sets a list of host names, IPs, or MAC addresses for wireless hosts and monitors the link quality for every device on the list using
/proc/net/wireless. Iwlist is another parameter-showing utility that has some very useful options including these:
arhontus:~# iwlist -h
Usage: iwlist [interface] frequency [interface] channel
[interface] ap
[interface] accesspoints [interface] bitrate
[interface] rate
[interface] encryption [interface] key
[interface] power [interface] txpower [interface] retry [interface] scanning
The iwlist frequency or channel commands demonstrate a list of frequencies supported by the selected interface and currently used frequency; for example:
arhontus:~# iwlist eth1 freq
eth1 14 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
Current Frequency:2.412GHz (channel 01)
Ensure that the interface you use supports all frequencies you might encounter in the country of operation.
802.11 Basics: 2.42.5 GHz (Medium ISM Band) Frequencies
In different countries the available channels vary due to legal and licensing regulations. 802.11b channel is 22 MHz wide. The IEEE standard defines minimum space between channels as 5 MHz. Thus, the channels start from 2.412 ± 11 MHz followed by 2.417 ± 11 MHz and so forth. As you can see, the channels badly overlap (Figure 4-4).
Figure 4.4. DSSS channels 2.4Ghz spectrum.
[View full size image]
In theory, nonoverlapping channels would be 5 x 5 MHz apart, because 25 > 22 MHz. Thus, there could only be three access points in a single network coverage area. In the United States it means channels 1, 6, and 11. In the rest of the world there is the possibility to have up to 14 channels (83.5 MHz 11 MHz)/5 MHz = 14.5. That would mean 2, 7, 12/3, 8, 13/4, 9, 14 and many other (1, 8, 14, etc.) combinations of three access point channels are possible. Now you know where to look for APs channel-wise and how many APs would be there, unless the system administrator does not understand the concept of radio interference and deploys multiple APs on overlapping channels.
The iwlist rate command lists the supported connection speed values and the current connection speed, iwlist key/enc shows the WEP keys available and lists their sizes (ensure proper iwlist and /etc/pcmcia/wireless.opts
permissions), and iwlist txpower can help you find out if your card supports regulated transmitted power output:
arhontus:~# iwlist eth1 txpower eth1 6 available transmit-powers:
0 dBm (1 mW) 7 dBm (5 mW)
14 dBm (20 mW) 15 dBm (30 mW) 17 dBm (50 mW) 20 dBm (100 mW)
Current Tx-Power=20 dBm (100 mW)
(This example is a Cisco Aironet 350 card.)
The most interesting iwlist command is iwlist scan (the obsolete one is
iwlist ap/accesspoint), which shows all APs and ad-hoc networks in range and even gives a variety of their settings like the signal quality. If you run HostAP in a master mode, you have to use the old iwlist ap and not iwlist scan command, although by the time this book comes out this might change. Also, iwevent has an option of showing that iwlist scan request is completed (iwlist <interface>
scanning), which can come in handy in your scripting adventures. The iwlist scan option gives you an opportunity for the quick discovery of access points in range while staying connected to your AP and without putting the card into the monitor mode.
We have included the fine manpages for Linux Wireless Extensions in Appendix D.
Although many consider including manpages or Requests for Comments (RFCs) a waste of space, in our experience sometimes there is no substitution to printed text, and manpages make perfect bedtime reading. :)