11 Network Analysis Checklist

Network Analysis Checklist

To illustrate how a network analyzer can aid network engineers in looking at wireless LAN traffic, this section presents checklists to assist in common authentication troubleshooting scenarios. The examples are described specifically for Ethereal but can be carried out with any of the commercial alternatives described earlier by applying similar operations.

Display Filter Primitives

Display filters are exceedingly useful on 802.11 because they are capable of operating on the minute details of decoded frames. Before diving into common troubleshooting scenarios, there are a few display filter building blocks that it is helpful to know.

Excluding Beacon frames

Beacon frames can get in the way when working with a raw 802.11 trace. Most products will send Beacon frames approximately 10 times per second, and the resulting traffic clutters the capture up. To remove Beacon frames, write a display filter that matches Beacon frames, and negate it.

• Filter on the type code for management with wlan.fc.type==0.
• Filter on the subtype code for Beacon with wlan.fc.subtype==8.
• Combine the two and negate the operation by using the exclamation point for not with an expression of !(wlan.fc.type==0 and wlan.fc.subtype==8).

Isolating traffic from one station

Often, a packet capture will be targeted at one particular station under test. There are many types of frames that fly between stations, so the method used to isolate just one station depends on what you are looking for.

The first method is to use the wlan.addr variable in a display filter, which is shorthand for traffic using that as either a source or destination address.

• Keep only data from one station by using a display filter of wlan.addr==00:02:2d:6e:ab:da, where the appropriate MAC address is filled in to the trace. This trace is equivalent to the much longer filter of wlan.sa==00:02:2d:6e:ab:da or wlan.da==00:02:2d:6e:ab:da.

Source and destination addresses only appear in 802.11 Data frames. Troubleshooting some problems may require peeking deeper into 802.11 management operations, such as frame acknowledgment. Frame acknowledgments are sent to receiver addresses, not destination addresses. To see anything to or from a station including acknowledgments, use a display filter that includes the receiver address.

• See acknowledgments by adding in the MAC address of the test station as a receiver with wlan.ra==00:02:2d:6e:ab:da, which will show any acknowledgments sent to the station. To see acknowledgments from the station, it will be necessary to add a second receiver clause, for something of the form (wlan.ra==00:02:2d:6e:ab:da or wlan.ra==00:0b:0e:84:32:91), where the second address is the serving access point.

Isolating a protocol

If the body of a data frame is available, the LLC header can be a target for a display filter. Use the llc.type variable to look for a specified protocol. Protocol numbers must be entered as hexadecimal digits without a dash.

• Look at a particular Ethernet protocol type with a filter of the form llc.type==0x888e.

The other useful task that can be done with the LLC header is to search for frames sent using 802.1H encapsulation, which uses an OUI of 00-00-F8. The llc.oui matches on a hexadecimal number of six digits. On encrypted networks, the only LLC headers that are available are likely to be found on 802.1X frames, so do not be surprised if this filter does not display higher-layer protocols.

• RFC 1042-encapsulated frames can be displayed by llc.oui==0x000000.
• 802.1H-encapsulated frames can be displayed by llc.oui==0x0000F8.

Common Troubleshooting Tasks

With a basic understanding of how to build display filters to isolate frames of interest, we can proceed to discussing common troubleshooting tasks. Rather than present detailed examples with a great number of screenshots, this section will discuss how to isolate frames of interest and give a description of what you should see.

Authentication troubleshooting

• Display filter: isolate EAPOL frames to and from a station, while looking for acknowledgments.

  llc.type==0x888e and wlan.addr==supplicant-MAC and (wlan.ra==supplicant-MAC or wlan.ra==AP-MAC)

All EAPOL frames have an identifier that serves as a sequence counter. Each EAP packet acknowledges the previously received one. Look through the 802.1X session to ensure that each EAPOL frame has a corresponding 802.11 acknowledgment, and that the EAP identifier is incrementing. Some supplicants do not handle retransmissions well, and will crash. (For that reason, many access points must deauthenticate a hung 802.1X session and start over.)

By looking at the contents of the EAP packets, you may be able to learn where the authentication is failing. If it fails after the TLS tunnel establishment, it may be that the supplicant is failing to verify the server certificate. If data is pushed through the TLS tunnel, the authentication is likely failing for another reason. Check your RADIUS server logs for details.

Key distribution troubleshooting

• Display filter: isolate EAPOL key frames to and from a station.

  llc.type==0x888e and eapol.type==3 and wlan.addr==supplicant-MAC

There are six steps to correctly distributing keys. A portion of the handshake is shown in Figure 24-5. First, the four-way handshake must complete. As an initial sanity check, make sure that each frame is acknowledged. The quick way to do so is to look at the frame number in Ethereal. If the frame number increases by two, it is likely that the skipped frame is an 802.11 acknowledgment.

One of the most common reasons for key distribution to fail is a mismatch between the supplicant and authenticator security parameters. Ethereal has dissectors built to decode the information elements included in key frames. Figure 24-5 shows the start of an information element decode at the bottom of the tree view pane. In it, the group key is decoded as dynamic WEP. Later on in the decode, there is only one unicast cipher suite. WPA specifies that only one unicast cipher suite should be used, but this stricture is regularly broken by most products. Some supplicants, however, are unable to cope with common practice and will fail partway through the authentication. If the decodes of the information elements in the Association Request do not match those in the key handshake, the authenticator should fail the exchange.

Performance troubleshooting

Resolving performance issues is frequently much easier than identifying them. Generally speaking, performance issues fall into one of the following categories.

• Display filter 1: isolate frames to and from a station, while looking for acknowledgments.

  wlan.addr==client-MAC and (wlan.ra==supplicant-MAC or wlan.ra==AP-MAC)

This filter displays all traffic to and from a particular station, along with any acknowledgments. Search through the trace and look for frames that are transmitted repeatedly. If no acknowledgment is received, the frame must be retransmitted in full. When it is not received after multiple attempts, the card will step down its transfer rate to improve reliability. Lower signal to noise ratios are required for slower speeds. One option for resolving this type of performance problem may require increasing the density of access points in the area to improve signal quality. Improving the antenna system on the AP or the client may also help.

Figure 24-5. Key handshake

• Display filter 2: traffic below a certain speed.

  prism.rate.data < (speed tag)

In conjunction with the previous filter, it may help to look only for frames above or below a certain speed. The prism monitoring header adds a single integer for the speed of the frame. It is reported in units of 500 kbps, so double the value of megabits per second for use in this expression. To see all frames transmitted slower than 2 Mbps, for example, use prism.rate.data < 4.

At the very bottom of the Ethereal screen below the data view pane is a window which reports the number of packets along with the number of displayed packets. In Figure 24-1, the capture has 261 frames (noted with the P), and all 261 are displayed (noted with the D). Applications of display filter 2 with a calculator will give you an idea of what fraction of frames are transmitted at which data rates. Many commercial tools report this analysis in real-time through a wizard.

• Display filter 3: data traffic from overlapping networks.

  wlan.bssid != AP-MAC

Users may complain about performance because a different network is overlapping. 802.11b/g networks are especially prone to performance hits from overlapping networks because there are only three channels. To assess the degree of overlap, run a capture, and then use display filter 3 to keep only frames that are from other networks. If a substantial number of frames remain, try to locate the APs from those networks and turn the power down.

Decrypting WEP traffic

Many analyzers have the ability to decrypt WEP-encrypted frames by entering the keys. In Ethereal, for example, go to the Preferences option on the Edit menu, and select the IEEE 802.11 protocol to see the WEP options displayed in Figure 24-6. Upon entering keys, Ethereal will attempt to decrypt all frames with the specified keys. Manual WEP keys are easy to find; dynamic WEP keys need to be recovered from either the supplicant or the AP. Linux supplicants will display the encryption key in the output of iwconfig. Many access points have ways of dumping the contents of the key table, which network administrators may use to find the key derived from that station.

RADIUS analysis

Although not strictly related to wireless LANs, Ethereal also has the ability to decrypt RADIUS frames. In the preferences configuration for the RADIUS protocol, it is possible to enter the RADIUS shared secret. Once entered, any protected fields will be recovered automatically. By using RADIUS traffic, it would be possible to automatically recover dynamic keys, although I am not aware of any Ethereal add-ons to do so.