WifiNigel

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 analyse

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 ad

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 form

I was recently reading through the most recent edition the finest WiFi text book in the world (in my opinion): the CWNA study guide . I read the previous versions a couple of times when I took my original CWNA exam and subsequent renewals. Looking through the latest book, I've picked up a a few nuggets which I either missed, or weren't included in the previous versions that I read. I had one "light bulb" moment when reading about antenna radiation patterns.  If you've ever looked at datasheets for antennas or access points, you may well have come across diagrams (like those shown below) that show the radiation pattern of an antenna. Fig1 - Antenna Azimuth Chart Fig2 - Antenna Elevation Chart There are generally two types of radiation pattern shown for each antenna: Azimuth (i.e. the RF radiation pattern when viewed from above the antenna) Elevation (i.e. a side-on view of the antenna RF radiation pattern) These are useful to unders

Occasionally you may come across an instance where you need to reset a Cisco 'lightweight' AP to it's default configuration. However, if the AP is not associated to a controller and you do not know the local username/password of the AP, then this can be something of a challenge. In summary, here are the steps to default the AP when you cannot get in to the AP via the 'usual' methods: Put a console cable in to the AP and fire up your terminal emulation program Power up the AP with the reset button pressed at the same time Release the reset button after 15 - 20 secs On the console, you should now be dropped in to a ' ap: ' prompt. Type in the following command to see the files on the AP: ' dir flash:' One of the files listed should be 'private-multiple-fs' Enter the following command to remove the configuration: delete flash:private-multiple-fs Reboot the AP - you will be able to login to the AP using the usual defaults (i.e. enable

In the WiFi industry, there are fewer characters who are more polarizing than Devin Akin ( @DevinAkin ). I guess he is the 'Marmite' of the WiFi industry: you will generally be a huge fan, or maybe not so much :) I personally have always been a huge fan of the work he did when he was part of the CWNP organization - I would not be in the position I am now without the fantastic work that Devin and the guys over at CWNP have done in providing vendor-neutral WiFi certifications. However, back at the beginning of 2012, Devin had moved to Aerohive and was presenting at the WiFi Symposium, which was part of the Wireless Field Day 2 event. I watched all of the videos from that event and learned some very valuable information. However, Devin's presentation about Aerohive's architecture (which you can see at the bottom of this article), and his belief that in the future other vendors must move in a similar direction, was a 'light-bulb' moment for me. I had only been

There are a number of methods of directing an Aerohive AP to find its instance of HiveManager, including using a DHCP option. In this quick tip, I share how to set up a Cisco switch or router DHCP server range to provide the correct  DHCP option to direct an Aerohive AP to a local instance of HiveManager. This is useful if you have a copy of HM running on your own appliance or virtual server. APs may be passed the IP address of HM via DHCP option 226. In the example below, APs are assigned addresses in the range 192.168.20.0/24. The Hive Manager server may be found at 192.168.50.7 in this example. The default router and DNS server options will need to be set to match your own environment. ! ! DHCP range for Aerohoive APs ! (HM address passed to AP using option 226) ! 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 226 ip 192.168.50.7 Hopefully, this is all fairly self-explanatory if you are famil