Showing posts with label Packet_Capture. Show all posts
Showing posts with label Packet_Capture. Show all posts

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.