Calibrating a Wireless LAN Survey Plan

One of the most important steps in completing a WiFi network survey using  a professional survey tool is to ensure that you have a correctly calibrated the floor plans used to conduct the survey. Without this step, your survey may be inaccurate or, at worst, worthless. In this article we look at why this is important, together with the right (and wrong) way to do it. Background When performing any type of  WiFi network survey using a tool such as Ekahau’s Site Survey or Fluke’s AirMagnet, one of the first tasks performed is the creation of a survey project. During the creation of the survey project, a number of configuration tasks must be performed. One of mandatory tasks is to import an electronic copy of the floor plan of the area to be surveyed. The floor plan is generally an image file (jpg, png, bmp etc.format) that has been created from an architect’s blueprint of each floor of a building. Professional survey tools also often allow the import of AutoCad (DWG) f

Cisco WLC: Per-client Packet Capture

Sometimes, you just want to capture the packets associated with a particular wireless client and see what the heck is going on with that client. Often, it may not be practical to do an over-the-air packet capture, as perhaps the client is at a remote location or just just don't have access to a wireless capture card. I recently had an issue trying to understand why an Android device that I was trying to 'on-board' using Cisco's ISE wouldn't access the Google Play store. I desperately wanted to capture the over-the-air frames from the client to have a look at what the client was doing. After a quick 'Google' around, I found an intriguing set of Cisco WLC CLI commands that allow a packet capture of traffic for a wireless client. This can all be done without having to change the AP mode, or reboot the AP etc. In summary, the feature allows packets to be captured for a specified wireless client that is sending/receiving traffic to/from an AP. T

Cisco Access Points: Which Power Levels Does My AP Support?

Cisco APs support a number of discrete transmit power levels which are 3dB apart. They are usually numbered levels 1 (highest) down to 7 or 6 (lowest). The numbers of levels and the transmit power values assigned vary between models and regions. The quickest way to determine the levels supported by your AP is to logon to your WLC and execute the following CLI command: show ap config 802.11b <ap-name> This will list out a whole lot of information, including a section which starts with the title: "TX Power". This contains the levels and corresponding dBm levels supported. Here is a sample: Tx Power       Num Of Supported Power Levels ............. 6       Tx Power Level 1 .......................... 16 dBm       Tx Power Level 2 .......................... 13 dBm       Tx Power Level 3 .......................... 10 dBm       Tx Power Level 4 .......................... 7 dBm       Tx Power Level 5 .......................... 4 dBm       Tx Power Level 6 .....

WiFi Free Space Loss Calculator

I often like to do a quick FSPL calculation to understand how far a WiFi signal might travel and usually have to search around to find an FSPL calculator. So, I put my own together so save me the search next time. To understand what a signal level might be over a particular distance, simply select the channel you are interested in, enter the EIRP of your AP and the distance involved. Then hit the 'Calc' button: Enter Frequency (Ghz): -- choose freq -- Ch1 - 2.412Ghz Ch2 - 2.417Ghz Ch3 - 2.422Ghz Ch4 - 2.427Ghz Ch5 - 2.432Ghz Ch6 - 2.437Ghz Ch7 - 2.442Ghz Ch8 - 2.447Ghz Ch9 - 2.452Ghz Ch10 - 2.457Ghz Ch11 - 2.462Ghz Ch12 - 2.467Ghz Ch13 - 2.472Ghz Ch14 - 2.484Ghz Ch36 - 5.180Ghz Ch40 - 5.200Ghz Ch44 - 5.220Ghz Ch48 - 5.240Ghz Ch52 - 5.260Ghz Ch56 - 5.280Ghz Ch60 - 5.300Ghz Ch64 - 5.320Ghz Ch100 -

802.11ac & 5GHz: The Emperors New Clothes? - Part 3

After previously looking at the challenges we may face with 802.11ac due to the restrictions of the 5GHz band (see part 1 and part 2 of this series), in this final installment, I suggest how we may mitigate the challenges we may face, together with a possible (but no doubt controversial) solution. The Solution? I'm not aware of any "magic bullet" to solve all of the challenges outlined in this series of articles (sorry). More spectrum will certainly help things. But, time-scales for the allocation and adoption of new spectrum are not clear at this point in time, though many agencies around the world are considering ways to free up more spectrum to improve WiFi capacity. Though spectrum may become available in relatively short time-frames, there will still, no doubt, be a significant time-lag before this permeates through in to the world of vendor and consumer WiFi products (remember the issues raised around UNII-2e support?)  The best way to mitigate th

802.11ac & 5GHz: The Emperors New Clothes? - Part 2

In part one of this series looking at 802.11ac challenges, we looked at the issues that the use of the 5GHz band brings, particularly around DFS. In this second installment, we look at further challenges to designing and deploying 802.11ac networks. Extended Channel (UNII-2e) Device Support Although we may be located well away from any obvious sources of radar interference, there may be other obstacles to the 5GHz nirvana outlined in the 802.11ac marketing briefs. One ugly fact affecting WiFi networks on the 5GHz band is that not all devices that use the 5GHz band support all of the unlicensed channels available in our region.  For instance, I recently purchased a Nexus 7 tablet and was extremely disappointed to find that it only supports channels 36 to 64 (for the UK). The remaining available channels, 100 - 140 are not supported at all. I think that this variation in support for channels was originally rooted in a lack of support for devices in the UNII-2e channels (c