Showing posts with label Wireshark. Show all posts
Showing posts with label Wireshark. Show all posts

Wednesday, 2 January 2019

WLANPiShark: Wireless Capture With a WLANPi on Windows

One huge advantage that Apple Mac users have over owners of Windows 10 machines is the ability to perform a native 802.11 wireless packet capture direct from their built-in wireless NIC. This is extremely useful for wireless pros who want to take a quick over-the air-capture into Wireshark to analyze traffic for troubleshooting purposes. Windows users don’t have the luxury of this native wireless capture capability. In this article, we take a look at how we can use a WLANPi unit as an adapter to capture traffic over the air, straight into Wireshark on a Windows machine. With the WLANPi being powered from the USB of the laptop, this is a super convenient, portable and powerful capture method that gets Windows users a little closer to the capabilities of their cousins on Apple Macs.


I’ve always felt really bad for Windows users who want to use their laptop for wireless packet capture purposes. I’ve been a long time Windows user and have often looked at how I might best use my Windows laptop to capture 802.11 frames over the air. This is a trivial exercise for Apple Mac users, as the native drivers on Macs allow their adapters to be put in to monitor mode and capture frames over the air. It’s been a goal of mine to find a low-cost solution to enable Windows users to be able to perform over the air captures. It was something I dreamed of the whole time I was studying for my CWAP in the days before I could afford a Mac!

Windows wireless NIC drivers, unfortunately, do not provide the required monitor mode capability to allow wireless packet capture. I’m guessing this is down to the huge variety of NICs that may be used by Windows devices. It simply isn’t worth the development costs for NIC manufacturers to code in the capability for their wireless NIC drivers to support monitor mode (as most users will never need it!). There are one or two software companies that provide specialist NIC drivers that they have developed for their own capture software for Windows, but these are only available with the purchase of specific packet capture software, which has a significant price tag.

There are a few lower cost software solutions that support Windows packet capture, but they rely on wireless NDIS drivers that have a number of compromises when capturing packets. I’m guessing this is because they aren’t operating directly at the NIC driver level. Limitations include the inability to select capture channel widths and limited/inaccurate RadioTap header information. These are OK(ish)...but they don’t provide the flexibility and depth of information I need to see for activities such as troubleshooting.

Earlier this year, I became interested in the “WLANPi “initiative started by Jerry Ola at the Phoenix 2018 WLAN Pros Conference. Jerry’s idea was to develop a single board computer platform equipped with a suite of free tools for wireless LAN pros to use in their testing and commissioning work. A number of excellent open source tools already exist, and were included in the distribution he created for the platform (find out more here). The WLANPi is a Linux-based (Debian), single board computer in the same vein as the Raspberry Pi, but is provided as a much smaller form factor. It also has low power requirements, so can be run from the USB port of a laptop. It has no onboard wireless adapter, but there is good driver support for the Comfast CF-912AC adapter, which is relatively low cost NIC that can be plugged in to the USB socket of the WLANPi. The WLANPi also has a Gig Ethernet port, which allows high speed data transfer between the WLANPi and a laptop. This combination of characteristics means that it can be used as a powerful wireless capture device, hooked up to a Windows laptop via its Ethernet port, and powered directly by the laptop’s USB port. Here is a picture to show you what it looks like. You can think of the WLANPi as a wireless adapter on steroids for your Windows laptop:

To allow the WLANPi to capture frames over the air, I have created a Windows batch file (a script file) that will set up the WLANPi to capture frames, then stream the capture over the Ethernet port of the WLANPi to a copy of Wireshark running on your laptop.

This might sound complicated, but trust me...after some initial setup, it’s really straightforward to use. Here is an overview diagram:

Quickstart Guide

For those of you in a bit of rush and who are comfortable with all of the concepts shown later in this article, here’s a very quick “get-you-going” setup guide. (For everyone else, I suggest you carry on to the next section of this article.)

  • Build/obtain a WLANPi with the latest image installed (unmodified) 
  • Plug in a Comfast CF-912AC adapter to a USB port on the WLANPi 
  • Install Wireshark on your Windows laptop - note the installation location 
  • Install Putty on your laptop (we need Plink which is installed along with Putty) - note its installation location 
  • Download the windows batch file from GitHub to your Windows laptop (use “Clone or Download” to download the zip archive) - 
  • Place the WLANPiShark.bat file in a convenient directory on laptop (your home directory) 
  • Edit WLANPiShark.bat file with notepad to configure user-configurable variables 
  • Hook up the WLANPi to your laptop with a USB to microUSB cable (provides power) 
  • Hook up the WLANPi to your laptop with an Ethernet cable (streams capture data) 
    • Ethernet port of laptop must be set to use DHCP 
  • Wait for WLANPi display to show its address - note this address for later (this may take around 30 secs to appear) 
  • Open Windows command shell (i.e. cmd), change to the directory where WLANPiShark.bat installed and type : WLANPiShark.bat -h (verify help screen shown) 
  • In the Windows command shell, start test capture with: WLANPiShark.bat -c 1 
  • You’re done...

What You’ll Need

You’re going to need a few component parts to get things set up to allow you to try out this packet capture method for yourself. If you’ve ever attended one of the WLAN Pro’s Conferences in the recent past, you may already already have most of these components. If not, I’ll give you a few pointers along the way.

WLANPi Hardware

To complete this exercise, you must have a WLANPi. These have been provided as part of the some the deep dive sessions at recent WLAN Pros conferences, so you may already be lucky enough to have one.

If you don’t have one, I’d advise you think about getting hold of one for a number of reasons: it comes packed with some useful free performance tools, it’s a great platform to practice your Linux and coding skills, and it will allow you to have a go at trying out various projects (such as the one in this article) that are being developed by enthusiasts in the WLAN community.

If you don’t have one, you have two options:

  • Buy one pre-built from the WLAN Pros store: 
  • Buy one direct from the supplier, but do the build and burning work yourself (full instructions on this site: Note that you will also need to buy a Comfast CF-912AC adapter and micro SD card reader if you use this option - the full parts list is available from (If you buy direct from the supplier, the platform is known as a NEO2, not a WLANPi)

Once you receive your WLANPi, ensure that it has the latest image from installed. Some of the older images had NIC drivers issues, so go with the latest and greatest. Once installed, do not globally update the packages using ‘apt-get’ on the WLANPi CLI, as this may overwrite the install NIC drivers and stop things working as expected. I tend to just stick to the vanilla image as provided at

Windows 10 Laptop

I’m guessing you already have a Windows 10 laptop, otherwise you likely wouldn’t have got this far in your reading! I’ve only tested the batch file I created on Windows 10, so I’m not sure if this will work for any of you diehard Windows 7 users out there.

Software Packages

There are a couple of software packages you will need to install on your Windows laptop, if you don’t already have them:

Wireshark is our (free) packet capture and decode software, which hopefully needs no further explanation.

Putty is a free terminal emulation software that is used by many network engineers who want a robust, reliable piece of software to SSH to devices around their network. Putty software is installed with a number of supporting utilities. We are not interested in Putty itself, but in the accompanying utility: Plink. Plink allows us to send single commands to devices over an SSH session. You don’t need to install Plink separately - it is automatically installed as part of the standard Putty installation.

When installing Wireshark and Putty, make a note of the location in which they are installed. This will be useful to us later when configuring the batch file that ties everything together and performs the magic. If you already have both software packages installed you may need to use the search tools in Windows File Explorer, or poke about in some well known install locations such as “C:\Program Files\ or ”C:\Program Files (x86)” to find their installation location.


As we’ll be hooking up the Ethernet port of our laptop to the WLANPi, we need to configure the IP setup of our laptop Ethernet adapter. To keep things nice and simple, just set the laptop adapter to use DHCP - no static IP addressing is required.

The reason for doing this is that when connected to the WLANPi, it will fall back to using its RFC3927 address ( The WLANPi will also do the same thing, so that they can communicate using their addresses when directly connected. This keeps thing nice and simple and avoids having to keep configuring static addresses every time you need to use the WLANPi with your laptop.

Hooking it all Together

Once you’ve installed the required software on your Windows laptop, you’re ready to hook everything together.

To connect your laptop to the WLANPi, you’ll need 2 cables:

  • USB to micro-USB cable (supplied with the WLANPi) 
    • Connect this between your laptop USB port and the micro USB port of the WLANPi - this will power the WLANPi 
  • Standard Ethernet UTP cable 
    • Connect this between your laptop Ethernet port and the Ethernet port on the WLANPi

When the WLANPi is connected to the laptop, it will initially show a address on its display. After 30 secs or so, it will fall back to a 169.254.x.x address, which will replace on the WLANPi display.

Obtaining and Configuring the Batch File

The glue that pulls all of this together is a Windows batch file that I wrote that will automatically set up the WLANPi to start collecting data over its WLAN adapter, and then stream the captured data back to Wireshark on your laptop. Once you’ve got hold of the batch file, you need to do a one-time configuration exercise, then it’s good-to-go to run from the command line of your Windows laptop.

Lets step through what you need to do:

1. Get the Latest Batch File

Visit my Github repository and download the latest file archive that contains the batch file. If you go to the GitHub site and select “Clone or download”, then select the “Download Zip” option (see screenshot below)

You will then be prompted to download a zip archive which contains the batch file that you will need. Download the zip file to a suitable location on your laptop so that you can unzip it and access the files that it contains.

2. Extract the Batch File

Once you have downloaded the zip file, open Windows file explorer, right click on the downloaded file and hit the extract option - this will extract all files in the archive to a new directory.

There are several files included in the zip file that is downloaded. The only file we are interested in using is the file titled “WLANPiShark.bat”:

Using Windows file explorer, move the “WLANPiShark.bat” file to your home directory.To find your home directory, open up a Windows command shell and check out the directory path indicated before the command prompt (see below):

3. Configure the Batch File

The final step is to configure the batch file for your environment. Don’t worry, you should only need to do this once.

Using a plain text editor such as Notepad or (even better) Notepad++, open the WLANPiShark.bat file. (Sidenote: if you don’t already have Notepad++, get it. You can thank me later. There are so many things you can use it for.)

When you open the file, it can look a little overwhelming as there is a lot of stuff in there! Scroll down to around line 50 and you should see something that looks similar to this:

There are 6 variables that need to be configured. These are indicated by the “set” statements shown above. All that needs to be done is to edit the value shown after the “=” symbol with a value for your environment. Many of them likely won’t need changing if you have a default WLANPi setup. When making any edits, ensure that you don’t add any leading or trailing whitespace characters (yes, I got stuck for a long time trying to figure that out at one stage...)

Make sure you hit “Save” when you’ve made your edits!

Let’s take a look at each variable:
  • WLAN_PI_USER: this is the username used to login to your WLANPi via an SSH session. The default is “wlanpi”, so unless you’ve created new accounts on the WLANPi, you can leave this as-is. 
  • WLAN_PI_PWD: this is the password of the account name specified in the previous variable. Again, if you’ve left everything as default, this is also “wlanpi”. If you have changed the user account password from default, then put in the password value here. (Note: this could be a security worry for some people, but I don’t have a good workaround for this, sorry
  • WLAN_PI_IP: this is the IP address of the WLANPi itself. The IP address is shown on the display of the WLANPi. By default this will be a 169.254.x.x address unless you have previously assigned a static address to the WLANPi Ethernet adapter 
  • WIRESHARK.EXE: this is the full directory path to the Wireshark executable on your laptop - it must also include the Wireshark executable filename. Hopefully you made a note of this during installation.If not, you will need to find it using a tool such as Windows File Explorer 
  • PLINK: this is the full directory path to the Plink executable on your laptop - it must also include the Plink executable filename. Hopefully you made a note of this during the installation of Putty - it will be in the same directory as Putty. If not, you will need to find it using a tool such as Windows file Explorer 
  • WLAN_PI_IFACE: this is the name of the wireless LAN adapter interface on the WLANPi device. By default, if there is only one WLAN USB NIC attached, it will usually be “wlan0”. If you need to check this, simply SSH to your WLANPi and (with the WLAN adapter plugged in), run the command “sudo iwconfig” and inspect the output for the name of the WLAN interface: 


Assuming you have followed the instructions above, you should be good to go for a test to capture some frames over the air via your WLANPi and display them in Wireshark on your Windows laptop.

The required steps are:
  1. Open a command shell on your Windows laptop (i.e. Start > Cmd) 
  2. Type the following command at the command prompt: WLANPiShark.bat -c 1 
  3. Following a few status messages at the Windows command prompt, you should now see Wireshark open on your laptop and frames being captured on channel 1 (Note: the first time you do this, you may be prompted to accept a key at the Windows command prompt - accept this by hitting “y”. You will only prompted to do this once.
  4. When you have captured enough frames, use the usual Wireshark controls to stop your capture and perhaps save them off if you want to keep them

Here are a couple of screenshots showing typical output in the Windows command shell and the Wireshark capture window itself:

(want to know where all those crazy colours came from in the wireshark capture? See this article:

Caveats & Limitations

As useful as this approach is, it has a few foibles and limitations of which you should be aware:

  • You should only use the latest WLANPi image from Don’t update the packages using “apt-get upgrade” as it will likely break the drivers supplied for the CF-912AC and break the capture capability.
  • Capture restrictions: 
    • Although the CF-912AC can capture 802.11ac frames, it can only capture 1 and 2 spatial stream fames. Data frames for 3 spatial stream devices will not be captured 
    • Capture is only possible for 20Mhz and 40Mhz width channels - this is a limitation of the ‘iw’ command in Linux (unless anyone has a clever work-around?) 
  • When installing Putty, remember that it is the Plink executable path you need to configure in the batch file, not Putty.exe 
  • This solution is bit clunky compared to native capture with an on-board adapter (though it is still quite powerful): 
    • It would probably be best written in another scripting language, but this adds another step of software to install to support that scripting language 
    • As ths is a Windows batch file, the CLI syntax checking is minimal. Check and double check the syntax you have used if you get strange results. It is easy to get Wireshark to fire up even though the entered CLI parameters are garbage. 
    • The batch file executes a number of remote commands on the WLANPi prior to firing up Wireshark. This means that there is a delay of a couple of seconds before Wireshark actually fires up. This could be possibly improved by adding a shell script on to the WLANPi itself, but I wanted to keep this as easy as possible to get going - hence I wrapped everything in to one file that runs on the Windows laptop 
  • Each time you need to do a capture, you have to run the batch file again - Wireshark does not run continually. You cannot just hit the stop/start button in Wireshark (sorry) 
  • In this article, I have shown how to run the capture using a direct Ethernet connection between the laptop and WLANPi. Obviously, by configuring IP addresses correctly, the laptop and WLANPi could be remote from each other. If you decide to try this approach, consider the bandwidth available between the laptop and the WLANPi and impact on other network infrastructure. Consider using the slicing option to keep the capture size down. 
  • Anything else you need is likely covered on the following GitHub page (inc full syntax and option details):


Sunday, 1 April 2018

Wireshark Capture Filters for 802.11

Generally, when performing over the air captures of WLAN traffic with Wireshark, the workflow adopted is as follows:

  • pick a specific channel where target traffic resides
  • switch the capture adapter to that channel
  • capture all 802.11 traffic over the air on that channel
Once a sample of traffic has been captured, the capture is stopped and analysis of the traffic using Wireshark's built-in display filters can begin.

In most situations, this is the best workflow to adopt. It ensures that all required frames are captured. Filtering wireless traffic while capturing frames is very problematic due to the complexity of 802.11 frame exchanges. It is very easy to miss parts of interactions between stations if you filter traffic as it is being captured.

However, there are a few edge cases where it may be useful to filter over-the-air frames at the point of capture. This will mean that only the filtered frames are available to display in Wireshark - all other frames are lost - but in some rare cases, this may be what you want.

Capture filters are added prior to commencing an over the air capture with Wireshark, as shown in the screen-shot below (see green highlighted text):

(Note that if the capture filter text is highlighted in red (rather than the green shown above), then there is an issue with your filter that needs fixing. You can access the screen display shown above via the Wireshark menu items: Capture > Options

The filter language used for capture filters is different from the built-in filter language with which most people are familiar. Capture filters in Wireshark use Berkeley Packet Filter (BPF) syntax. You can find out more about the syntax here:

I thought it might be useful to provide some examples of capture filters for 802.11 (Wi-Fi) traffic, as I didn't find many examples when Googling around.

Here are a few example filters:
  • wlan type mgt - capture only management frames
  • wlan type ctl - capture only control frames
  • wlan type data  - capture only data frames
  • wlan type mgt subtype beacon - capture only beacon frames
  • wlan type mgt subtype deauth - capture only deauth frames
  • wlan type mgt subtype prob-req - capture only probe requests
  • not wlan mgt - do not capture management frame (i.e. capture data & control frames)
  • not wlan mgt subtype beacon - capture all frames except beacon frames
  • wlan type mgt and (subtype beacon or subtype prob-req) - capture only beacon  and probe request frames 
  • wlan type mgt and (subtype deauth or subtype disassoc) - capture on deauthentication and disassocation frames
  • (wlan type data) or (wlan type ctl and (subtype rts or subtype cts)) - capture only data frames and RTS/CTS control frames

By studying the examples above,you will likely be able to craft your own capture filters. However, you will need to understand the various types of 802.11 frame available and their roles to be able to construct valid filters (maybe take a look at the CWNA or CWAP certification programs if you are not familiar with these)

The following extract from the PCAP filter manpage provides all of the filter options available to you:

type wlan_type subtype wlan_subtype
True if the IEEE 802.11 frame type matches the specified wlan_type and frame subtype matches the specified wlan_subtype.
If the specified wlan_type is mgt, then valid wlan_subtypes are: assoc-reqassoc-respreassoc-reqreassoc-respprobe-reqprobe-respbeaconatimdisassocauth and deauth.
If the specified wlan_type is ctl, then valid wlan_subtypes are: ps-pollrtsctsackcf-end and cf-end-ack.

If the specified wlan_type is data, then valid wlan_subtypes are: datadata-cf-ackdata-cf-polldata-cf-ack-pollnullcf-ackcf-pollcf-ack-pollqos-dataqos-data-cf-ackqos-data-cf-pollqos-data-cf-ack-pollqosqos-cf-poll and qos-cf-ack-poll.

Again, it is worth stressing that most of the time, capture filters are not what you want. It is very easy to miss some important interactions unless you capture all frames over the air (e.g. it is no good capturing just data frames and not seeing deauth frames that are kicking your client off the network).

Monday, 15 May 2017

Wireshark Custom Columns For Wireless Captures

In previous articles, I’ve covered a few aspects of wireless frame capture using Wireshark, looking at subjects such as frame colourization and radio tap headers. In this article, I look at another way of improving the visualization of wireless frame captures by adding columns to our Wireshark frame summary, including customised columns that use 802.11 frame field values.


By default, a typical 802.11 capture in Wireshark looks something like the screen-shot presented below (assuming you added the colourization rules I previously blogged about):

Although we get a nice summary of the frame types that are whizzing by, it would be useful if we could get a little more summarized information, before we dive into the detail of each frame. In a wireless environment, there are many more considerations compared to the wired world when we’re looking at frame captures. In addition to the information around frame timings, addressing, types etc. I’m always interested to know wireless-specific information such as:

  • What signal strength was this frame seen at?
  • What PHY types are being used on this network?
  • Are the QoS data frames being correctly marked in the 802.11 frame headers?
  • What physical speeds are being used on this network?

By applying some customisation to Wireshark, we can summarise these pieces of information in our frame summary through the addition of new columns.

Pre-defined Column Headers

So, how do we perform this magic and improve our frame capture summary?

First, let’s add a couple of pre-defined column headers that are already easily available without too much effort within Wireshark.

To customize the columns displayed, right click on column bar and select “Column Preferences”, or use the Wireshark menu-bar option: Edit > Preferences > Columns. Once selected, the panel below will be displayed:

We’d like to add new columns to show the RSSI (Received Signal Strength Indicator) and transmission rate of each frame. Follow these steps to add the two new columns:

  • Hit the “+” button
  • A new entry will appear displaying the following information: Title: New Column, type: Number.
  • Double click on the “New Column” field and enter the name of “RSSI”
  • Double click on the “Number” field and change the type to “IEEE 802.11 RSSI” using the drop-down that appears
  • Hit “+” again. Another new entry will appear
  • Repeat the process, but add a title of “TX rate” and a type of “IEEE 802.11 Tx rate” from the drop-down options.
  • Finally, drag the two new column definitions so that that appear above the “Info” field in the column listing, as shown below:

Finally, how hit the “OK” button and see the new columns appear in your Wireshark display:

Custom Column Headers

There are a couple more columns I’d like to add to the frame summary, but they aren’t available as pre-defined column values within Wireshark. Luckily, Wireshark has a superb feature that allows us to select any field value within our capture and turn it into a custom column. We’ll use this to create two additional columns to show us the PHY type of each frame and the QoS setting of our data frames.

For this operation, we need to initially select a QoS Data frame in our frame summary, then perform the following operations (see figure below):

  • In the decode panel, snap open the “802.11 radio information” section of the decode
  • Select the “PHY type” field
  • Right click and select “Apply as Column” using the pop-up panel that appears

  • Snap open the “IEEE 802.11” section of the decode panel
  • Snap open the “QoS Control” section
  • Right click on the “Priority” field and add this as a column:

Our Wireshark display should now look like this, showing our new 2 columns:

If we now go back to our column preferences, we can see our new column definitions and re-order and rename them if desired. (Edit > Preferences > Columns):

One caveat to the information process presented in this article is that the fields that are available may vary slightly depending on your capture environment. For instance, you should see all the fields relating to 802.11 frame headers and content, but the 802.11 Radio and Radio Tap header information is specific to the capabilities of your capture setup and the additional frame information it can (or cannot) provide.

Obviously, the custom column feature can be used to provide a wealth of additional summarized information. By selecting any field within a frame capture, it’s possible to add columns to make the frame review process more informative. I’ll leave it up to the reader to experiment with this feature, but other valuable fields in a wireless environment include: retry bit, channel width and channel number. Enjoy!


Final Columns View


Thanks to Eddie Forero for telling me about this...I don't really know much about Wireshark, but guys like him make me look smarter by sharing their knowledge! :)

Monday, 17 February 2014

WLAN Packet Capture - Wi-Fi Filter Categories in Wireshark

Wireshark has an expression builder to help build filter expressions to filter out the frames that perhaps you don't want to see, or to allow you to select the frames would like to view.

At first glance, the categories are pretty overwhelming due to the fantastic array of protocols that Wireshark can decode for us. I certainly had to dig around a little the first time I looked through the list before I found the WiFi related categories.

I thought it might be useful to list the categories (that I have found so far!) that relate to WiFi traffic.  Here is the list, together with a brief description of each one:
  • 802.11MGT - IEEE 802.11 Wireless LAN management frame
  • 802.11MGT - Radiotap - IEEE 802.11 Radiotap Capture Header
  • IEEE 802.11 - IEEE 802.11 wireless LAN
  • IEEE 802.11 Aggregate Data - IEEE 802.11 wireless LAN aggregate frames
  • Wi-Fi P2P - Wi-Fi Peer-to-Peer

WLAN Packet Capture - Displaying Only 802.11 Decodes in the Frames Summary

I quite like to be able to see the frame type, sequence numbers and flags field when looking at a summary of an 802.11 capture in Wireshark. 

However, Wireshark can be too helpful when decoding frames and  will display a summary of the frame which shows the detail of hight layer protocols (thus hiding the 802.11 summary info). This generally happens when decoding a capture of a WiFi network that has a guest network that is not using over the air encryption.

Here is an example. Some data frames in the trace summary below are shown as 'https' or 'Application Data' frames, rather than layer 2 data frames:

To prevent this behaviour, simply go to the "Analyze > Enabled Protocol" menu option in Wireshark and de-select 'LLC':

This will restore the standard 802.11 frame summary so that 802.11 frame types, flags etc. are available:

One thing to bear in mind with this approach is that some exchanges you would normally decoded (e.g. EAP exchanges and 4 way handshake) will suddenly become just data frames - so use with care.

Sunday, 16 February 2014

WLAN Packet Capture - Frame Colorization in Wireshark

Generally, when capturing and decoding frames in a wired network, there isn't a huge amount of interest going on at layer 2 of the OSI stack. There is pretty much one type of frame at the data link layer (i.e. an Ethernet frame), with all of the real 'interesting' stuff going on in layer 3 and above.

However, when looking at 802.11 wireless packet capture and decoding, there are a whole host of different frames types at layer 2 that we might see. (As a side note, layer 3 and above are often inaccessible to us in wireless captures as the payload of our layer 2 frames may be encrypted, rendering upper layers impossible to view.)

There are actually 3 types of frames we might see at layer 2 when performing a wireless capture:
  • Management frames - these frames are used by wireless stations to join and leave a wireless network
  • Control frames - these are used to assist with the delivery of data frames
  • Data frames - these contain the actual higher-layer data that we want to get across our wireless network (i.e. layer 3 and above of the OSI stack )
In addition, each of these frame types has a multitude of sub-types that we may well see during the course of our wireless analysis. For instance, management frames may be beacons, association requests, authentication frames or perhaps probe requests. Control frames may includes Acks, RTS or perhaps CTS frames. Hopefully, you get the idea that there are quite a few different frame types you may see.

  As you learn more about 802.11 frame types and sequences, you will become familiar with the various frame types and their function. However, when viewing a summary of an 802.11 capture in Wireshark, the line after line of  black text on a white background that Wireshark presents by default is quite difficult to study and understand.

Luckily, Wireshark allows us to employ some very useful colorization rules that allow us to color the frames shown in our summary screen to give us a few clues about what is going on.
As an example, have a look at the capture summary shown below:

If you look at this summary carefully, you can see that we have probe requests & probe responses ('management' frames), Acknowledgement (Ack) and CTS frames ('control' frames), together with QoS data frames (obviously, 'data' frames). However, it is quite tricky to see the different frame types unless you understand which group each frame sub-type belongs to.

However, if we employ some fancy rules using the Wireshark colorization feature, we can colour each frame type and sub-type to give us some really useful visual cues about the frame types we are looking at, which in turn may help us to understand what is going on.

To access the colorization rules, you will need to go along to the Wireshark menu item: View > Coloring Rules

On the left side of the Coloring Rules panel, you will see a button labelled 'Import'. Using this, we can import a text file containing colorization rules for each type and subtype of 802.11 frame. You can download a colorization file from here: link

Once you download this file (which is a simple text file) and import it, you will then see each frame type and sub-type displayed in a variety of colors in your Wireshark capture summary. If we re-visit our previous example, it now looks like this:

To give the colors displayed a little more context, here is how the colorization has been configured:
  • Management frames are colored using varying shades of purple
  • Control frames are colored with varying shades of orange/brown
  • Data frames are colored with various shades of blue
Each sub-type will have a unique shade of colorization within its frame type, however the main point of interest is the instant visual clue you get about whether a frame is a management, control or data frame type. You also start to get a feel for how many of each type of frame you are actually looking at. I found it quite surprising at first just how many management frames are actually flying back and forth in each capture when I first started to use colorization for my capture file analysis.

  I'd like to claim that it was in fact myself who had been smart enough to figure out this superb colorization scheme for 802.11 frames - but, I'm not that smart :) This colorization scheme was put together by (and is used with permission from) Trent Culter (@FireMyWires on Twitter). He actually put this colorization scheme together during his time at Metageek. It reflects the colorization scheme used within Metageek's EyePa analysis product (which I strongly recommend that you check out). I have found the colorization incredibly useful when looking at wireless captures within Wireshark - it gives you some great visual cues about what is going on when looking at a capture summary. Hopefully, if you find it as useful as I have, you might drop Trent a note of thanks for his efforts in putting this together.

Useful Link:

Wireshark colourization file download


Sunday, 19 January 2014

WLAN Packet Capture - Filtering Out Bad FCS Frames

Often when looking through a wireless capture file, there may be a number of frames which have been corrupted, but Wireshark has attempted to decode it as best it can.

When a frame is corrupted, the frame check sequence of the frame will fail, indicating that some part (or parts) of the frame have errored during transit.

When reviewing a trace, it can be very easy to miss the fact that the FCS is wrong and that you are essentially looking at a corrupt frame. This will often manifest itself bizarre frame types and field values which can lead you completely astray in your diagnosis efforts.

There are a couple of ways to get around this.

Firstly, you can add a display filter to remove all of the frames with a bad FCS (wlan.fcs_bad == 1), but use this option with care (see note below):

The drawback to this approach is that just because some frames fail the FCS, the actual frame that arrived at the destination station may have been OK. It depends on where your analyser is physically compared to the target stations and what local RF factors may impact its wireless reception (e.g. local interference). 

Secondly, you can add a colouration rule to indicate which frame  have a bad FCS and should be ignored (View > Coloring Rules) :

This approach is slightly more useful, as even if your analyser detects a frame as having a bad FCS, you can still the frame which may have been received uncorrupted by the target station.

I've chosen to use a bright-red colouration, but you can choose any colours you feel appropriate. In the screenshot below, you can see at at glance the frames which are corrupt(i.e. have a bad FCS):

Both of these approaches have their uses, but be mindful of the caveats I have included in the descriptions above.

Saturday, 30 November 2013

What are RadioTap Headers?

I've been doing some study for my CWAP (wireless analysis) exam recently, so I've been spending quite some time staring at Wirehsark traces trying to figure out precisely what all of those 802.11 fields actually mean.

One thing I noticed whilst pouring over a few capture files is that some of them seemed to have some additional fields included in the trace, which seem to have nothing to do with fields defined in 802.11 frames at all. They are in a section of the packet decode called 'RadioTap Headers'. I wasn't too sure what they were and why they are available in some captures, whilst in others they were missing.

After a little bit of research, I found out a bit more information and thought it might be worth sharing in a quick blog post.

In summary, radiotap headers provide additional information that is added to each 802.11 frame when capturing frames with an analysis application. Just to be clear, these are not part of the standard 802.11 frame format, but are additional information added at the time of capture to provide supplementary data about the frames captured. For instance, in a standard 802.11 traffic capture, there is no information regarding the receive signal level for the frame at the time of capture, which could be very useful. As another example, there is no information about which channel is being used by a station that has generated the frame, which again could be very useful.

Radiotap headers provide additional information to supplement the raw frame capture data that can be derived by analyzing the 802.11 frames.

The next logical question is: "how to I get radiotap headers in my captures?". The headers are added by the wireless adapter (or its driver) that is being used to perform the frame capture. If the adapter does not inject the additional information as it captures frames, then no radiotap headers will be added. 

I guess the best way to verify this is simply to perform a capture and see if they appear in your capture using Wireshark. In my own particular case, I was performing a capture with an AirPcap NX card, which provides radiotap information. However, I also performed captures with the internal WLAN NIC of my laptop, which does not provide radiotap data.

Here are a couple of examples so that you can see the difference between captures with and without radiotap headers:

Fig 1 - Beacon frame, no radiotap data

The capture above shows a standard capture of a beacon frame with no radio tap headers (taken with my laptop WLAN NIC card). Next, we see a beacon frame again, but this time with radiotap information included (taken with the AirPcap card):

Fig 2 - Beacon frame, with radiotap data

You can see the additional radiotap section in the frame decode highlighted with a red circle above.

Next, we'll snap open the radio tap headers and take a look at the information available:

Fig 3 - Radiotap headers detail

Right away, you can see fields which give us great supplementary information about the RF environment that the capture was taken in. Looking at the trace above, we can see that this frame was captured on channel 6 on the 2.4GHz band and that it was received by the wireless NIC capturing the frame at a level of -44dBm.

You can see that there are also additional snap-open sections to view even more information (i.e. Present flags, Flags and Channel type), so we'll take a brief look at each of those too.

Present Flags

Fig 4 - Radiotap 'Present Flags' section

The 'Present flags' section is a matrix of the information that is available in subsequent sections of the radiotap headers. The flags will vary depending on the information that can be provided by the NIC card that is performing the capture. (To see a comprehensive list of all possible fields and their meaning, take a look at the following page: )

For each field that is marked as 'true', there will be information for that section appearing in the radiotap headers that follow the 'Present Flags' matrix. For instance, in the matrix shown above we see that the flags for 'Channel' and 'dBm Antenna Signal' are true. We've already seen in a previous screen-shot that these field are included in the headers shown in the frame decode.


Fig 5 - Radiotap 'Flags' section

The flags section provides us even more information about the captured frame itself, giving details about preamble type, whether a short guard interval was used and whether the frame has a valid frame checksum.

Channel Type

Fig 6 - Radiotap 'Channel Type' section

In the 'Channel Type' section, we gain even more information about characteristics of the channel itself, such as which band is in use, the modulation type used and channel width information.

More Information

The examples shown here represent a subset of the fields that may be included in radiotap headers. To view all possible fields, and to understand their meaning, take a look at the following page:

To find out more about radiotap headers, take a look at which has comprehensive information on all apsects of radiotap headers.

Tuesday, 24 April 2012

Decoding Cisco CAPWAP With Wireshark

Here's an interesting little gotcha I wasted a few hours on recently...

I have been looking at QOS on a Cisco WLC and was looking at DSCP markings in CAPWAP packets between a Cisco WLC and access point. I did this by spanning the switch port that the AP is connected to and then using a copy of Wireshark on another switch port to capture the traffic so that I could have a look through it.

However, when I looked at the CAPWAP frames, Wireshark was reporting most of the CAPWAP packets as being "Association Requests" and that they were "[Malformed Packets]".

After testing this in quite a number of versions of Wireshark (assuming a Wireshark decode bug), I finally gave up and reported a bug to the guys at Wireshark. They were incredibly quick to respond and diagnosed the issue very quickly!

It turns out that Cisco have not implemented the final draft of CAPWAP (according the guys at Wireshark), and that there is an option in Wireshark for Cisco CAPWAP support. You can it in the find the options panel at : Edit > Preferences > Protocols in the Wireshark GUI.

Select the CAPWAP protocol and check the 'Cisco Wireless Controller Support' check-box and everything decodes as you would expect :)