Wireshark WLAN Traffic Statistics and IO Graphs

Protocol analysis skills continue to be increasingly important for network engineers in all fields, especially for wireless engineers. As the 802.11 protocol continues to increase in complexity, maintaining interoperability while implementing support for numerous optional features becomes critical. Even more critical is having the skill set to investigate, diagnose, and resolve issues.

Engineers attempting to learn protocol analysis techniques often start with free tools that allow them to get comfortable looking at packets and expected versus abnormal behavior. However, this often comes at the expense of sophisticated analysis features which can greatly simplify the process and reduce analysis time. This can be both a blessing and a curse at the same time. It's a blessing for engineers because it forces them to learn the fundamentals of protocol analysis without the aid of automated tools that abstract the underlying protocol operation. This is a good thing (despite initial grumblings by those learning). It can also be a curse, because engineers often need to resolve issues quickly and efficiently, where sophisticated analysis tools can help identify and determine the root cause much faster.

Smart IT organizations will implement a mix of both scenarios, purchasing the (expensive) analysis tools for experienced engineers and the support organization, while training junior engineers or those new-in-role using the fundamentals approach.

The first step is for an engineer to learn and understand the fundamental Wi-Fi protocol exchanges such as active scanning, association, 802.1X/EAP authentication, the 4-way handshake, as well as various packets of interest including 802.11 power management techniques, retransmissions, fragmentation, medium reservation (RTS/CTS), and protection mechanisms. Easy identification of these exchanges can be achieved using Wireshark coloring rules and display filters as previously discussed.

In this post, we will continue our look at free methods to enhance Wi-Fi protocol analysis using incrementally more sophisticated analysis techniques. In subsequent posts, we will explore professional analysis tools that can automate many of these techniques.

Wireshark WLAN Traffic Statistics
The WLAN Traffic Statistics tool provides engineers with a high-level overview of the networks (BSSIDs) that are observed within the capture.

Navigate to the Statistics menu, then select WLAN Traffic.

Wireshark WLAN Traffic Statistics View

The top frame displays network traffic volumes by BSSID as a percentage of packets observed, as well as breakdowns for common wireless frame types such as beacons, probe req/resp, authentications, and de-auths. This information can be useful to identify which base stations and SSIDs are most active in the area and time the packet capture was taken.

By selecting a network from the top frame, a list of traffic within the BSSID is shown in the bottom frame. This can give engineers valuable information about top talkers within the network and can be useful for identifying bandwidth hogs, problematic clients, or clients having issues indicated by excessive probing or de-auth behavior. This can also be a rough measure of quality of service based on packet transmissions on the network. However, be sure NOT to use this as a measure of airtime fairness, as most vendor algorithms are based on byte-level fairness to override packet-level fairness inherent in the 802.11 protocol.

If you want to limit WLAN traffic statistics to a subset of packets in the capture, apply a display filter for the desired traffic, then open the statistics tool and check the box that states "Limit to display filter". This allows more focused analysis on subsets of data within the packet capture.

If you find a network or station of interest, Wireshark does provide some basic drill-down filtering capabilities by right-clicking on the entry, as show below.

Wireshark's Basic Drill-Down Filtering

Wireshark IO Graphs
The Wireshark IO Graphs tool allows engineers to graphically represent data within the packet capture for more intuitive analysis of information. This can be useful to graph the occurrence of events or packet exchanges over time, or to graph the relationship between multiple types of packets over time. This automates many analysis scenarios, eliminating manual compilation of such data.

Navigate to the Statistics menu, then select IO Graphs.

Wireshark IO Graphs

For example, the graph above shows the relationship between wireless data frames (line graph) and wireless retransmissions of data frames (bar graph). This allows the engineer to graphically observe network health over time and identify periods of degraded performance due to retransmissions. Here we see a spike of retransmissions around time mark 13:51:28 in the packet capture.

IO Graphs use the same syntax as display filters and coloring rules, so virtually any field or information within a packet capture can be graphed. Also note, that if the filter is modified you must un-select and re-select the Graph1 through Graph5 buttons to the left for the new filter to be applied and shown.

Additional Wireshark Features
In addition to WLAN traffic statistics and IO graphs, take time to explore the use of other built-in analysis tools. These include:

• Enabled Protocols - used to decode various protocols for interpretation and analysis. Be sure to enable wireless protocols such as IEEE 802.11, LWAPP, CAPWAP, EtherIP (EoIP), RADIUS, EAPoL, EAP, and WLCCP. This will aid analysis of encapsulated protocols used in lightweight architectures as well as common wireless protocols either over the air or on the wire.
  
  
• Endpoints - to identify top talkers and data volume per station, based on either frames or bytes.
  
  
• Set Time References - used to mark packets and adjust time displayed in subsequent packets based on the marked packet. Useful for marking the beginning of a client roam and calculating the time required for an individual roam event. It's also useful for quickly setting time references on all first packets of roaming events to at once (tip - set a display filter for EAPoL Start or EAP Request Identity frames), or to see how long a client was associated to each AP before roaming.

Sample Roam Time Calculation Using the Wireshark Set Time Reference Feature

Also, combine output from multiple tools to provide focused analysis. For example:

• Identify the BSSID and/or station transferring the most frames in the WLAN traffic statistics tool, apply an appropriate display filter to limit the scope of analysis, then review the frame and byte level data using the Endpoints tools.
  
  
• Identify a period of time where there are a large percentage of 802.11 retransmissions in the IO Graphs, apply a display filter to narrow the packet range to just that time interval and only retransmitted frames, then view the WLAN Traffic Statistics limited to displayed packets to see what BSSIDs or stations were having the most problems. This will help identify if there is an issue with one station (hidden node, localized interference by STA, bad hardware, multipath, etc.), all stations on one access point (failing AP, localized interference by AP, installation error, etc.), or if there are problems with multiple APs and stations in the area (larger source of interference, environmental issue, etc.).

Revolution or Evolution? - Andrew's Take
Using free tools such as Wireshark are great for engineers that need to learn how protocols operate by experiencing them first hand. Also, by knowing some of the advanced features of such tools, both beginning as well as seasoned engineers can perform more in-depth and sophisticated protocol analysis.

However, there are limitations to free protocol analysis tools. They often have problems opening and analyzing large packet captures, difficulty or complexity in identifying and narrowing the focus of analysis, and limited ability to perform trending analysis. They also take time to learn and master.

In subsequent posts, I will explore more professional (paid) tools that eliminate some of these limitations, and automate sophisticated analysis techniques to reduce the learning curve required to accomplish similar tasks.

Cheers,
Andrew

Other Posts You Might Like:

• Using Wireshark Coloring Rules to Enhance Wi-Fi Protocol Analysis
• Cisco Wireless SSID to BSSID Mappings

Using Wireshark Coloring Rules to Enhance Wi-Fi Protocol Analysis

Two weeks ago I attended the Certified Wireless Analysis Professional (CWAP) version 2 beta class, held by CWNP Inc. The class was full of wireless LAN experts and was a great opportunity to share experiences and perspectives on wireless protocol operations (and to network with professionals in the field). Numerous times throughout the course attendees would exchange relevant details, tips, and tricks they found useful in real-world networks to analyze the environment. This allowed attendees to share valuable expertise they have acquired with others and promote knowledge sharing within the community.

I would like to share a few tips and tricks that I use with the broader Wi-Fi community as well.

Using Wireshark Coloring Rules to Enhance Wi-Fi Protocol Analysis
Speed up your protocol analysis kung-fu by using Wireshark coloring rules. By using packet colorization, engineers can quickly identify and find packets of interest that warrant deeper analysis within large trace files. Coloring rules can be defined in the View > Coloring Rules menu section.

Often times, engineers are using protocol analysis to either understand how a protocol operates or to troubleshoot an issue. Therefore, you may not know exactly what you're looking for until you find an anomaly or start digging deeper into a sequence of packet exchanges. When was the last time a support ticket came in with packet analysis level detail like "our handhelds are being de-authenticated by a rogue wireless IPS system"? Yeah, never.

In order to help you spot interesting packet exchanges during your initial scan of the packet trace, use coloring rules to visually distinguish common protocol exchanges and anomalies. Coloring rules use the same syntax as Wireshark Display Filters. As you find new protocol fields or interesting packets as you analyze various situations, simply create a display filter and copy it into a new coloring rule.

Here is an example of a packet trace where packet colorization indicates a station's probing (blue) and roaming (green) behavior.

Wireshark packet colorization visually identifies client probing and roaming behavior

Since most wireless networks are encrypted to meet security requirements, most protocol analysis will focus on layer 2 network operation. As such, the default coloring rules provided with Wireshark usually have little to no value for wireless engineers. Create your own custom coloring rules using Wi-Fi protocol fields found in the layer 2 header. Wireshark provides a WLAN display filter reference listing all of the available wireless fields for use in display filters.

Note - Coloring rules are applied in top-down order. If multiple coloring rules match the same frame / packet, then the higher rule is applied for colorization. Carefully select the order of coloring rules to highlight packets in the desired manner.

To help you get started, here are some of my favorite coloring rules / display filters (you download this text file and import it into Wireshark):

• 802.11 Bad FCS
  This indicates frames which were not received correctly. This is common in wireless protocol analysis due to signal differences that may exist between the intended receiver and the analysis station. These frames should be ignored as the information is likely corrupt and incorrect.
  
  wlan.fcs_bad == 1
  
  
• 802.11 Retries
  This indicates frames which were re-sent by the transmitting station, indicating RF collisions, interference or multipath. Retransmissions are common in all wireless networks, and engineers should baseline normal conditions in each environment to understand what level is abnormal. Real-time applications such as voice may require lower level of retries than other applications (typically <10%).
  
  wlan.fc.retry == 1
  
  
• 802.11 Probing
  This indicates when wireless clients are probing for infrastructure access points in preparation for a future roaming event. Behavior will vary between client devices, and can impact battery life for highly mobile clients. Additionally, poor roaming implementations can be identified if clients wait too long to probe for new access points and complete a roaming event prior to application impact.
  
  wlan.fc.type_subtype == 0x04 || wlan.fc.type_subtype == 0x05
  
  
• 802.11 Roaming (802.11 authentication, (re)association, and EAPoL / EAP)
  This indicates when a wireless client roams to a new access point and can be useful to analyze total time required by a client to complete a roam, time to complete various stages of a roam (association, EAP authentication, 4-way handshake, etc.), or to diagnose at which stage in the process a roam fails.
  
  wlan.fc.type_subtype <= 0x03 || wlan.fc.type_subtype == 0x0b || eapol

A few others that I like include 802.11 fragmentation, de-authentication, and unencrypted data.

The saying goes "you're only as good as the tools you use". Take the time to invest in your tools and learn how to properly use them to be a better engineer.

Cheers,
Andrew

P.S. A huge thanks to Kevin, Marcus, and Abbey at CWNP Inc. for organizing such a great course! The CWNP program is the best in the industry. I always look forward to the high quality content your company produces and the fostering of such a great wireless community!

Other Posts You Might Like:

• CWAP Beta Course Recap by Douglas Haider (@wifijedi)
• Locating Wireless Devices Through Spectrum Analysis by Douglas Haider (@wifijedi)