Ethereal

Ethereal is the standard open source network analyzer. Like the commercial analyzers, it supports a long list of protocols and can capture live data from a variety of network interfaces. Unlike the proprietary analyzers, Ethereal comes complete with a slogan ("Sniffing the glue that holds the Internet together").

Ethereal runs on most Unix platforms as well as Windows. Source code is freely available for both, but modifications are easier to make on Unix because of the availability of compilers in the Unix programming environment. Like many open source projects, Ethereal is distributed under the terms of the GNU Public License. Protocol decodes are included for many common networking protocols. For the purpose of this section, the important protocols are IEEE 802.11 and LLC, both of which are used on every 802.11 frame. Of course, the TCP/IP suite is included as well.

As 802.11 has become more popular and better supported on Linux, the choice of analysis hardware has opened up. Initially, only Prism-based cards were supported. However, most common interface cards are now supported out of the box. This section was written about Ethereal version 0.10.9, which was released in late January 2005.

Packet Capture on Windows

Binary packages are more important in the Windows world because of the lack of a high-quality, free development environment. Although Ethereal does not provide the same level of 802.11 support under Windows, it can still be a valuable program to have, especially in a day job that requires use of Windows systems. Binary versions of Ethereal for Windows are available from http://www.ethereal.com. They require the WinPcap library to provide the libpcap-type support on Windows. WinPcap can be downloaded from http://netgroup-serv.polito.it/winpcap/. WinPcap is supported only on 32-bit Windows systems (95, 98, ME, NT, and 2000) and is licensed under a BSD-style license. Interestingly enough, WinPcap was supported in part by Microsoft Research.

Ethereal depends on pcap, the packet capture library. WinPcap, a port of pcap to Windows, can be used with Ethereal on Windows. Although nearly every Ethernet interface is supported on Windows, wireless cards present different programming interfaces. Many cards cannot capture any frames when using promiscuous mode. By disabling promiscuous mode, many cards are able to capture frames to and from the station only. Wireless packet capture is much more card-dependent on Windows than Linux, so I tend to use Linux instead of Windows.

 

Compilation and Installation

Building Ethereal for wireless network analysis is much easier than it used to be. Many of the patches formerly required for wireless analysis have been integrated into the main source tree, so wireless analysis works "out of the box."

Ethereal depends on both libpcap, the packet capture library, and the GTK+ display library. Packet capture also requires kernel support to grab packets, in the form of Packet Socket (CONFIG_PACKET) support.

Ethereal itself is compiled using the standard open-source routine of downloading the source code from http://www.ethereal.com, running ./configure, make, and make install.

Ethereal on Windows

Binary packages are more important in the Windows world because of the lack of a high-quality, free development environment. Although Ethereal does not provide the same level of 802.11 support under Windows, it can still be a valuable program to have, especially in a day job that requires use of Windows systems. Binary versions of Ethereal for Windows are available from http://www.ethereal.com. They require the WinPcap library to provide the libpcap-type support on Windows. WinPcap can be downloaded from http://netgroup-serv.polito.it/winpcap/. WinPcap is supported only on 32-bit Windows systems (95, 98, ME, NT, and 2000) and is licensed under a BSD-style license. Interestingly enough, WinPcap was supported in part by Microsoft Research.

 

Setting the Wireless Interface for Monitor Mode

To capture packets, the wireless interface must be put into monitoring mode, which is the equivalent of running an Ethernet interface in promiscuous mode. Each wireless driver has its own method of activating monitor mode.

Cisco Aironet cards

Cisco Aironet cards have two flavors of monitoring mode. In the first mode, called rfmon, the driver will pass up any frames in the station's current network. In the second mode, denoted with a simple y, the driver will capture any frames on the current channel. Both modes are selected by modifying the driver's running configuration through the proc file system:

 bloodhound:~# echo "Mode: rfmon" >/proc/driver/aironet/ethX/Config
 bloodhound:~# echo "Mode: y" >/proc/driver/aironet/ethX/Config

To return to a normal station setting, change the mode back to ess:

 bloodhound:~# echo "Mode: ess" >/proc/driver/aironet/ethX/Config

Ethereal requires a network interface name to capture packets. In kernel versions up to 2.4.19, use the Ethernet name of the interface (ethX). In 2.4.20 and later, use wifiX.

Prism cards

Prism-based cards can use one of two drivers: the linux-wlan-ng from Absolute Value Systems (http://www.linux-wlan.org), and the HostAP driver (http://hostap.epitest.fi). Monitoring has been a driver feature of the linux-wlan-ng driver since version 0.1.15. It is activated by using the wlanctl-ng command, rather than a wireless extensions command:

 bloodhound:~# wlanctl-ng wlan0 lnxreq_wlansniffer enable=true channel=6

To turn off monitor mode, send a request to disable it:

 bloodhound:~# wlanctl-ng wlan0 enable=false

Monitoring with Prism-based cards can also be done with the HostAP driver. It uses a private system call for monitoring mode, similar to wireless extensions. Monitoring is activated by sending a monitor mode command to the card of either 2 or 3, depending on whether you want full monitoring headers (2) or just 802.11 headers (3). Monitoring is deactivated by sending a mode of zero:

 bloodhound:~# iwpriv eth1 monitor mode
 bloodhound:~# iwpriv eth1 monitor 0

 

Orinoco cards

Version 0.15 and later of the orinoco_cs driver supports moinitoring mode without requiring patches. Patches against earlier versions may be found at http://airsnort.shmoo.com/orinocoinfo.html. To check that a driver has been patched, run iwpriv to look for the monitor control call:

 bloodhound:~# iwpriv eth1

If the driver supports monitoring, it can be activated with iwpriv as well. The monitoring driver has two modes. Mode 1 prepends Prism-style monitoring headers that report signal strength and other physical parameters, while Mode 2 has only the 802.11 header. Select one of the two modes, and a channel to monitor. To monitor channel 6 with full Prism-header monitoring information, run this command:

 bloodhound:~# iwpriv eth1 monitor 1 6

To stop monitoring, use a mode of zero:

 bloodhound:~# iwpriv eth1 monitor 0

 

Atheros-based cards

Atheros-based cards use the MADwifi driver discussed in Chapter 19. With current versions of MADwifi, the card can be placed into monitoring mode with iwconfig. If necessary, a channel can also be selected with iwconfig, as in the following examples for interface ath0:

 bloodhound:~# iwconfig ath0 mode monitor
 bloodhound:~# iwconfig ath0 channel 6

With some driver versions, I have found it necessary to assign an IP address to the interface before the interface appears in the capture list. The IP address does not need to be used on the network.

 bloodhound:~# ifconfig ath0 1.2.3.4
 bloodhound:~# ifconfig ath0 up

 

Running Ethereal

Starting Ethereal pops up the main window, which is shown in Figure 24-1. Any user may start Ethereal, but administrator privileges are required to capture packets. (Any user may load files for analysis, however.) The main window has three panes. The top pane, called the packet list pane, gives a high-level view of each packet. It displays each packet's capture time, source and destination address, the protocol, and a basic decode of the packet. The Protocol field is filled in with the final decode, or dissector, used to analyze the frame. On 802.11 networks, the final decode may be IEEE 802.11 for management frames, or it may go all the way to the final TCP protocol for analysis, as in the case of an 802.11 frame holding an LLC-encapsulated IP packet with a TCP segment carrying HTTP. With the increasing use of link-layer encryption, the end decode is often 802.11 because Ethereal's raw capture cannot decrypt frames and "see" the protected higher-layer protocols.

Figure 24-1. Main Ethereal window

The middle pane, called the tree view pane, is a detailed view of the packet selected in the packet list. All the major headers in a packet are shown and can be expanded for more detail. All packets have the basic "Frame" tree, which contains details on arrival time and capture length. 802.11 networks may add the Prism Monitoring header, which contains radio-link data. The Prism header was originally developed for use with Prism devices, but has been adopted by most drivers. The capture in Figure 24-1 was taken with an Atheros card, but the MADwifi driver appends the Prism monitoring header. Some drivers have the option of enabling or disabling the Prism header.

The bottom pane is called the data view pane. It shows the raw binary data in the selected packet. It also highlights the field selected in the tree view pane. If further dissectors can be called to decode the frame, they will be. For unencrypted traffic, Ethereal can see the Logical Link Control (LLC) header. From there, the LLC may contain ARP packets, IP packets, TCP segments, and so on. Ethereal includes dissectors for all the commonly used protocols, so 802.11 frames are fully decoded when available. However, encrypted frames, such as the one in the figure, are presented as opaque data.

By selecting a field in the tree view pane, the corresponding bits are highlighted in the data view pane. In Figure 24-1, the Data field of the frame is selected, and highlighted at the bottom. I prefer to use a monospace font so that the data view pane at the bottom is presented in columns.

At the top of the Ethereal window is a bar with four important elements. The leftmost button, "Filter:", is used to create filters that reduce the captured packet list to the packets of interest. The text box just to the right allows you to enter filters without going through the construction process. Ethereal maintains a filter history list that enables easy switching between filters. At the right is a text field that displays several kinds of information, depending on what Ethereal is doing. It may indicate that Ethereal is currently capturing data, display the name of the capture file loaded, or display the field name currently highlighted in the tree view.

Capturing data

Capturing data is straightforward. Go to the "Capture" menu and choose "Start". The Capture Preferences window opens. Ethereal can use any detected interface, even wireless LAN interfaces.

The first thing to do is select the interface you want to monitor. For wireless interfaces, the name may begin with eth, ath, or even wlan. Before starting the capture, however, you must place the interface into monitor mode. Ethereal accepts the -i command-line option to specify an interface. If you plan to do all of your analysis on one interface, you can define a shell mapping of ethereal to ethereal -i ath0.

I typically turn on "Update list of packets in real time" and "Automatic scrolling in live capture". If the former is left unselected, the trace appears only when the capture stops. If the latter is left unselected, the trace does not scroll to the bottom. Speed is important to real-time analysis. Disabling name resolution eliminates overhead for every packet captured and may allow a station to avoid missing frames in the air.

Data Reduction

Raw captures can be quite large, and extraneous packets can make finding wheat among the chaff a challenge. One of the keys to successful use of a network analyzer is to winnow the torrent of packets down to the few packets at the heart of the matter. Ethereal provides three ways to reduce the amount of data captured to a manageable amount: capture filters, display filters, and marking packets.

Capture filters

Capture filters are the most efficient way to cut down on the amount of data processed by Ethereal because they are pushed down into the packet sniffing interface. If the packet capture interface discards the packet, that packet does not make it to Ethereal for further processing. Unfortunately, capture filters are not tremendously useful with 802.11. If the Prism monitoring header is appended, capture filters cannot be applied.

Ethereal uses libpcap, so the capture filter language is exactly the same as the language used by tcpdump. A number of primitives are available, which can be grouped into arbitrarily long expressions. These primitives allow filtering on Ethernet and IP addresses, TCP and UDP ports, and IP or Ethernet protocol numbers. Many can be applied to source or destination numbers. Unfortunately, most of the protocol numbers they apply to are encrypted on many 802.11 networks, and are therefore not useful.

802.11 frames carry the Ethernet protocol number in the LLC header, so it cannot be filtered on easily if the network is encrypted.

 

Display filters

Display filters can be used on any field that Ethereal identifies, which makes them far more powerful than capture filters. Display filters inherit the knowledge of all the dissectors compiled into Ethereal, so it is possible to filter on any of the fields in any of the protocols that Ethereal is programmed to recognize. Wireless LAN administrators can filter frames based on anything in the 802.11 or LLC headers. Examples specific to 802.11 are presented later in this chapter.

Using Ethereal for 802.11 Analysis

Several Ethereal features are handy when applied to 802.11 networks. This section lists several tips and tricks for using Ethereal on wireless networks, in no particular order.

Display filters

Ethereal allows filtering on all fields in the 802.11 header. Frame fields are structured hierarchically. All 802.11 fields begin with wlan. Two subcategories hold information on the Frame Control field (wlan.fc) and the WEP Information (wlan.wep) field. Figure 24-2 shows the variable names for 802.11 header components; in the figure, each field is labeled with a data type. Boolean fields are labeled with a B, MAC addresses with MA, and unsigned integers with U plus the number of bits. Table 24-1 shows the same information, omitting the Ethereal display fields that are unlikely to be useful for filtering.

Figure 24-2. Header component variables

Table 24-1. Ethereal fields for 802.11 header components

802.11 header field	Ethereal field
Header fields
Either source or destination address	wlan.addr
Transmitter address	wlan.ta
Source address	wlan.sa
Receiver address	wlan.ra
Destination address	wlan.da
BSSID	wlan.bssid
Frame control subfields
Frame type	wlan.fc.type
Frame subtype	wlan.fc.subtype
ToDS flag	wlan.fc.tods
FromDS flag	wlan.fc.fromds
Retry flag	wlan.fc.retry
Protected frame (WEP) flag	wlan.fc.wep
Protection fields
WEP Initialization vector	wlan.wep.iv
TKIP IV	wlan.tkip.extiv
CCMP IV	wlan.ccmp.extiv
Key identifier	wlan.wep.key

Fields can be combined using operators. Ethereal supports a standard set of comparison operators: == for equality, != for inequality, > for greater than, >= for greater than or equal to, < for less than, and <= for less than or equal to. An example of a display filter would be wlan.fc.type==1 to match Control frames.

Logical operators and and or are supported; as in many programming languages, the exclamation point is used for logical negation. Boolean fields can be tested for existence, so Control frames with WEP enabled would be matched by the display filter (wlan.fc.type==1 and wlan.fc.wep).

Figure 24-3 shows a complete 802.11 header in the tree view. Selecting the 802.11 header in the tree view highlights the bits that comprise the 802.11 header in the ASCII view at the bottom. Expanding the 802.11 header tree decodes all the fields in the 802.11 header.

Understanding the LLC header to isolate a protocol

To multiplex higher-level protocol data over the wireless link, 802.11 uses the LLC SNAP encapsulation. SNAP encapsulation is described at the end of Chapter 3. 802.11

Figure 24-3. An 802.11 header in tree view

does not include a protocol field, so receivers cannot discriminate between different types of network protocols directly from the header. To allow multiple protocols, an 8-byte SNAP header is added. The SNAP header is decoded in Ethereal's tree view, as shown in Figure 24-4, for an EAPOL key frame.

Highlighting the LLC header in the tree view shows the corresponding 8-byte header in the packet dump. The eight bytes in the SNAP header are clearly visible in the data view pane. Five fields make up the header:

The destination service access point (DSAP)--llc.dsap

This is always set to 0xAA for SNAP encapsulation.

The source service access point (SSAP)llc.ssap

This is always set to 0xAA for SNAP encapsulation.

Figure 24-4. LLC SNAP header

 

Controlllc.control

This is derived from HDLC. Like all data transfer using HDLC, it labels the data following the LLC header as unnumbered information (0x03). Unnumbered information indicates the use of a connectionless data transport and that the data need not be sequenced or acknowledged.

An organizationally unique identifier (OUI)llc.oui

This is used to determine how to interpret the following bytes. IP is encapsulated in LLC using the standard in RFC 1042, which specifies the use of the OUI 0x00-00-00. (Some vendors may use an assigned OUI for proprietary communications.)

Protocol Typellc.type

This is copied from the corresponding Ethernet frame. The Type field matches the Ethernet type codes. On IP networks, it will be either 0x08-00 for IP or 0x08006 for ARP. In the figure, it is 0x88-8e because the frame in question is an EAPOL (802.1X) frame.

LLC encapsulation is required by the 802.11 specification because it saves the 802.11 frame from having to carry protocol information directly. In many cases, however, the LLC header is encrypted and is not visible to the sniffer without first decrypting the trace.