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.