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.

Wednesday, 8 January 2014

DHCP Option 43 for Meru APs (using a Cisco Router/Switch DHCP Server)

Meru access points, like many other controller-based APs, can use DHCP option 43 to acquire the address of the wireless LAN controller that they need to join.

In brief, controller-based APs need to find their way back to a controller to obtain their operating code and parameters. Out-of-the-box, they don't know the IP address of the controller they should be talking to. When they are hooked to a wired network, they will request an IP address via DHCP. The DHCP process can also be used to pass them the address of the wireless LAN controller they should be speaking with (in addition to the usual parameters such as IP address, mask, default gateway etc.).

DHCP option 43 is used to pass the WLC IP address information to the AP. However,  figuring out the format of the information that should be put in to the option 43 field can be something of a challenge, depending on the DHCP server you are using.

I recently had to set up a DHCP server on a Cisco switch to provide IP addressing and DHCP option 43 to some Meru APs. I thought it would be worth sharing this information, as it wasn't immediately obvious.

My setup:
  • AP Network:
  • WLC address:  

The option 43 string that is passed to the AP has to be constructed in the following format:
  • byte 1: '43' in hex (2b) - this is to tell the AP that we are actually using 'Vendor option 43' within the standard DHCP option 43 (I know, it's me, it's always 43)
  • byte 2: '13' in hex (0d) - this is the length of the vendor option payload (in bytes) that follows - this will need to vary depending on the length of the WLC IP address
  • byte 3 onwards: the remainder of the bytes are the WLC IP address string ascii characters (including '.' characters)
Putting all of this together, here is the final DHCP configuration applied to the Cisco switch which will provide an example of how to put this together:

! Cisco DHCP Configuration - vWLC address =
ip dhcp pool APs
   option 43 hex 2b0d.3139.322e.3136.382e.3530.2e31.32


Option 43 break-down:

2b = Vendor option 43
0d = length of vendor option payload in bytes (13 bytes/characters in this case)
31 - ascii "1"
39 - ascii "9"
32 - ascii "2"
2e - ascii "."