Monday, April 25, 2011

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.


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:


  1. Do you prefer WireShark with AirPcap over Omnipeek?

  2. I personally prefer Wireshark, but I would advise engineers to use whatever tool they are most familiar and comfortable using assuming it has the features to get the job done.

    Go with what you know works!


  3. Andy, can we cheat ? Can you export your colors and share them !? :)

  4. A big thanks, Andrew, for the compliments! It was great having you at the CWAP beta class. Thanks for all of your input and expertise. You da man!!!

  5. ++george;
    (Andy, can we cheat ? Can you export your colors and share them !? :))

  6. Sure... why not :)

    Here are some of my coloring rules exported from Wireshark:

    # DO NOT EDIT THIS FILE! It was created by Wireshark
    @802.11 Retry@wlan.fc.retry == 1@[64625,65535,30485][0,0,0]
    @802.11 Roaming@wlan.fc.type_subtype <= 0x03 || wlan.fc.type_subtype == 0x0b || eapol@[33822,65535,34155][0,0,0]
    @802.11 Probing@wlan.fc.type_subtype == 0x04 || wlan.fc.type_subtype == 0x05@[37136,45913,65535][0,0,0]
    @802.11 Deauth@wlan.fc.type_subtype == 0x0c@[65535,37737,37737][0,0,0]
    @802.11 Power Mgmt@wlan.fc.pwrmgt == 1@[455,53024,51784][0,0,0]
    @802.11 Null Data (Pwr Mgmt)@wlan.fc.type_subtype == 0x24@[47638,64807,63302][0,0,0]
    @802.11 Unencrypted Data@wlan.fc.protected == 0 && wlan.fc.type == 2@[65535,56717,12400][0,0,0]