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: 192.168.20.0/24
  • WLC address: 192.168.50.12  

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 confusing...trust 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 = 192.168.50.12
!
ip dhcp pool APs
   network 192.168.20.0 255.255.255.0
   default-router 192.168.20.254
   dns-server 8.8.4.4
   option 43 hex 2b0d.3139.322e.3136.382e.3530.2e31.32

Notes:

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 "."
...etc.

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: http://www.radiotap.org/fields/defined )

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.

Flags

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: http://www.radiotap.org/fields/defined

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