Monday, 19 November 2012

Wireless Field Day 3 Wrap-Up & Pen-Testing

Update: After today's events, I feel I have to state that Cisco did not promise nor did they provide me with US$1.2B in exchange for positive words about meraki!

Recently (well recent when I started this post 8 weeks back!) I returned from Wireless Field Day (WFD) 3, based out of San Jose, California. Firstly a quick re-cap for those not familiar. Wireless Field Day is an event unlike any other in the wireless community. It brings together wireless vendors, social media-savvy folk (delegates) and the wider wireless community. Wireless Field Day, under the umbrella of Tech Field Day, is organized by Steven Foskett with the wireless spin-off originally conceived by Jennifer Huber.

Of the vendors that presented at WFD3, I have worked with Cisco, Metageek and Omnipeek. From a hands-on perspective, the other vendors were new to me. Consequently blog posts concerning these other vendors will come once I have had a chance to take a deep dive into their doco and play with their hardware, for those vendors that supplied it. If you want to check out the vendor presentation videos and the other delegates’ thoughts on the event take a look at the Wireless Field Day 3 page.

In the meantime, I thought I would throw up a review of some vendor SWAG… Specifically, the pens!


First up we have the Ruckus-provided orange number. This style of pen is fairly standard when it comes to vendor SWAG. Whilst this pen does the job when it comes to putting ink-to-paper, there is nothing particularly special about it. If you look closely you can see inflictions present in the ‘R’, ‘u’, ‘k’ and ‘s’ – these take away from the impact that ‘Ruckus’ may otherwise have on the page. I suspect this comes down to a low grade of ball-bearing used in the pen.

Next up, we have the WildPackets pen. This little number features all of your standard pen features – the ability to be held, the ability to inpart ink onto the page and finally the ability to actually hold a reservoir of ink. Whilst also being made from a semi-opaque plastic, this pen features a rubber ‘comfort grip’.  This feature aids in your ‘comfort’ whilst ‘gripping’ the pen – truly revolutionary stuff and second only to Gillette adding the totally-not-needed fifth blade to oneof their razors! The pen also outputs blue ink. Now I really want to make this clear – I am not penist in any way however I do favour blue ink over black. It just looks nicer on the page. That and the comfort grip put it ahead of the Ruckus number.

Last up we have the meraki pen. This handsome looking pen sports an outer casing made from some sort of metallic material – quite possibly metal. Enough with the pens external aesthetics – how does it look when the pen hits the paper. Pretty damn great! In addition to the fantastic text-formation, it has the smoothest writing motion of all the pens – a clear winner! I have over-looked the ink colour due to the superb performance.

Whilst the meraki pen is undoubtedly the winner of the three it does not trump my existing pen, although comes in a close second.  Whilst meraki did provide the notepad for the pen-test, I have no reason to believe that this improved the pens performance. Many in the pen-testing community have suggested a special coating may exist on the paper to account for the fantastic performance – this is pure speculation with absolutely nothing to back the claim up.

The meraki will work nicely for me, providing pen-redundancy in case of primary-pen failure… unless the WAN link is down ;). Oh yes, I went there! At this stage, I believe this isn’t a hitless fail-over and would involve me tossing my primary pen in the bin and reaching into my bag to grab the meraki. I am considering taping the two pens together to provide true HA!

As for future vendor SWAG, I would like to see a quill and ink provided, just for something a little different – back to the old school!

Some have suggested that declaring meraki the pen performance winner when it was only compared with two other vendors’ pens is unfair… and they’re probably right. But hey, if it works for Juniper ;).

If you’ve made it this far, you probably want the last 5 minutes of your life back! Unfortunately I can’t help you with that; I can however offer up some thoughts on Wildpackets Omnipeek in my next post!

Tuesday, 30 October 2012

5 GHz: The band that never was

In early 2009 I started working on a high density education deployment. I tried looking at every available option to wring the last piece of performance from the WLAN design. This was prior to the ratification of the 802.11n standard, which didn't come until September of that year. What was immediately apparent was how important the 5 GHz band was going to be to achieving this goal.
At the time the Wi-Fi alliance had been certifying 802.11n Draft 2.0 gear for around two years. Because no mandatory new features were added to the final ratified standard, all Draft 2.0 gear was able to successfully interoperate with gear that came about after the standard was finally ratified. This certification was a great move from the Wi-Fi Alliance because it meant that there was a reasonably large installed base of compatible clients to make use of the 802.11n APs upon ratification, at least in the laptop space. Essentially the clients had a two-year head start. This was doubly important due to the large delays with getting 802.11n over the line. By the time it arrived in late 2009, it was desperately needed in areas such as education where one laptop (or other device) per child was starting to become the norm.
The real key to making the most out of high-density deployments is 802.11n support in the 5 GHz band. This doesn't necessarily mean that all of your clients should be in the 5 GHz band as you may be missing out on available airtime in the 2.4 GHz band - just that if all (or more realistically, most) of your clients are dual-band capable then at least you have the 5 GHz option at your disposal!
In early 2009 it was hard to gauge how many clients would be released with dual-band support. At the time I thought that two-years post-ratification (late 2011) most clients released would support not only 802.11n but also the 5 GHz band. Two years later the majority of clients did support 802.11n however unfortunately this was not the case when it came to 5 GHz support. Not only that but early experiences with the 5 GHz band on many devices (though certainly not all) has been underwhelming largely due to poor implementations by client vendors.
The Laptops
Initially most laptop drivers I tested did not prefer the band and many would jump between bands during use of the client. In addition, Cisco didn’t offer a band steering option early on and when they did introduce one (Band Select) it was CLI-only and the release notes stated that it should NOT be used. In other words, it was buggy. Later it made its way to the GUI. With bugs ironed out in the Band Select code and with improved laptop drivers, laptops began to stick to the 5 GHz band.
Most of the new laptops that I was testing in 2009 offered dual-band support so when I started a new role in late 2010 I was very surprised that my corporate laptop provided only single-band support. Not only was it 2.4 GHz-only but it didn’t even provide MIMO or support Short Guard Interval – 65 Mbps was the top data rate! This came as a big surprise but since then I have seen plenty of ultra-lightweights’ and Ultrabooks that likewise only provide single-band support.
Then of course there is band and channel support within the 5 GHz band. With the 5 GHz band broken up into five separate bands (UNII-1, UNII-2, UNII-2e, UNII-3 and ISM) there are often incompatibility issues between what bands the infrastructure supports and what the client supports. Much of this comes down to what regulatory domain your infrastructure/client vendor intends your equipment to operate in and the issues this causes when their vision doesn’t fit with yours. These vendors and the original 802.11 standard seem to have forgotten about the realities of globalisation!

In my utopian-vision, world-peace would result in real universal standards. This would eliminate the 5 GHz incompatibilities we see amongst infrastructure equipment and clients :)

For example, back in early 2009 I looked into why Cisco didn’t offer their APs in a SKU for the Australian market. Although legally we’re able to use the UNII-2e band, we get thrown into the lowest common denominator –N regulatory domain when purchasing Cisco APs. Of course we could purchase the US –A APs but then you have the issue of client support. There is no point in allowing your APs to use the UNII-2e band if few of your clients support it. Whilst many clients may be unable to use the UNII-2e band in Australia currently, I hope to see this change once 802.11ac and its larger channel widths take hold. As far as I can see the only reason an Australian SKU doesn’t exist is that Cisco doesn’t see Australia as a large enough market and no one has put pressure on them to support it. Whilst it would have been nice to have UNII-2e support here for 802.11n when using 40 MHz channels in high density environments, it is all the more important with the 80 MHz channels offered by 802.11ac, assuming you have a use case for such wide channels (I'm ignoring 160 MHz channels just like I ignored 40 MHz channels at 2.4 GHz!). Things are looking up though - the new Cisco 2600 series APs are available in a –Z SKU for the Australian / New Zealand market and hopefully this SKU will also be offered for forth-coming 802.11ac APs where it will really matter!
Besides this Australian/Cisco-centric issue, there are plenty of other issues when it comes down to individual 5 GHz band support from clients not supporting the UNII-2e band to clients not supporting individual channels (the Cisco 7925G’s lack of support for channel 165).
The Smartphones
It was quite some time before even a small percentage of available phones started to support the 5 GHz band. Within your average corporate or home network, this wasn’t a big deal – within a high-density environment such as a stadium deployment it certainly is! Whilst it is great to see phones supporting the 5 GHz band, mere support isn’t enough. If you’re going to offer dual-band support you’d better do it right! Let's examine what was one of the most popular Android-based phones - the Samsung Galaxy S II. Dual-band support? – yes! Very poor RSSI at 5 GHz – yes; favouring 2.4 GHz over 5 GHz despite band steering being enabled – yes; poor support for individual 5 GHz bands – yes. With all of these issues, I consider the 5 GHz support useless on this phone. By comparison, the Samsung Galaxy S III appears to have solved most of these issues.
Then there is of course the iPhone 5, which now offers dual-band support – hopefully more inline with the Galaxy S III than the Galaxy S II.
In my mind, in 2013 we will start to see smartphones really make use of the 5 GHz band with recent client improvements and support for the band alongside an increase in stadium/BYOD/hotspot deployments. We might even start to see some 802.11ac phones - Galaxy S IV / iPhone 6 anyone!
The Tablets
Tablets have been a mixed bag when it comes to comes to 5 GHz support. There are certainly more dual-band capable tablets out there than smartphones but particularly on the Android side of the fence, it isn’t overwhelming.
In contrast to the their smart-phones, Apple has offered dual-band support from the beginning - the iPad 1, 2, 3 and now mini all support it. Dual-band android tablet support is not so great with a mixture of dual and single band tablets out there. The issues on the Samsung Galaxy S II phone also seem to exist on Samsung’s tablets. Apple’s 5 GHz tablet support seems much more solid.
5 GHz – The band that never was
So far, many 5 GHz client implementations have been underwhelming. The issue has not been with the five to six billion oscillations per second – that is, there are no significant issues with using Wi-Fi in this band.
The issue has been with both the quality and quantity of dual-band implementations from client vendors. Looking back 3+ years, I thought we’d be in a very different place by now. Things are looking up however! From improved laptop chipset drivers to improved smartphone implementations to an overall increased quantity of dual-band capable clients. With ratified enterprise-grade 802.11ac hardware on the way hopefully the lessons that client vendors have learnt from their 802.11n 5 GHz implementations pay off and we see some of the first 802.11ac clients perform solidly on the 5 GHz band. It would have been nice if the IEEE had never supported 802.11n in the 2.4 GHz band to begin with but considering work started on it almost 10 years ago, I imagine it wasn't a realistic option back then.
In addition to the issues with client vendor implementations (or lack thereof), there is so much more that needs to be taken into account when designing for the 5 GHz band. Hopefully the knowledge gained from the v1.0 5 GHz implementations of 802.11n pays of when it comes to the v2.0 designs and implementations of 802.11ac. What about 802.11a, you may ask. That was a merely a beta!

Sunday, 15 July 2012

Wireless Field Day 3

Recently I was invited to join a star-studded, able-bodied talented crew of Wi-Fi social media folk at Wireless Field Day 3. Happy, eager, enthusiastic, thrilled, and animated – they’re all words. Specifically, according to Microsoft Word, they’re synonyms for how I felt when I received the invite – (ridiculously) excited!

By now most of you are probably familiar with the Tech Field Day events but if you’re not, let me fill you in. The Tech Field Day’s are a series of independent events that allow vendors to present their wares and nifty technology to a group of social media folk who are active in that particular field. In turn, these bloggers and tweeters provide their own thoughts and analysis based on the vendor presentations. One of the aspects of the Tech Field Days that really surprised me was how professionally the events are filmed. Check out the video’s from Wireless Field Day 1 and Wireless Field Day 2 to see what I mean!

As most of my experience has been focused on Cisco, I look forward to checking out some of the competition and offering some insight into what they can offer. So far Meraki, Ruckus Wireless and WildPackets have been confirmed, with more to come.

Due to the relative dearth of engineers specializing in Wi-Fi, I felt like I was on a virtual Wi-Fi island in Australia. Whilst I have worked with a number of excellent engineers in other areas of networks and been able to throw ideas back and forth with them, when it came to Wi-Fi, I have had to turn to Twitter in the last year to continue the Wi-Fi conversation that was previously confined to my own head! Below are some of the folk who have helped end my Wi-Fi insanity with a few new names throw in – all of whom I look forward to meeting come September. The delegates for Wireless Field Day 3 are:

Ryan Adzima A Boring Look @radzima
Tom Carpenter CWNP @carpentertom
Sam Clements SC-WiFi @samuel_clements
Daniel Cybulskie Simply WiFi @SimplyWiFi
Rocky Gregory Intensified @bionicrocky
Jennifer Huber I ♥ WiFi @JenniferLucille
Blake Krone Digital Lifestyle
NSA Show
Chris Lyttle WiFi Kiwi’s Blog @wifikiwi
Sean Rynearson WiFiGeeks @Srynearson
Scott Stapleton Phased Coexistence @scottpstapleton
George Stefanick my802.11 @wirelesssguru
Gregor Vučajnk Not your fathers WiFi @gregorvucajn

Now I just need to stock up on kangaroo-themed tea towels, Crocodile Dundee themed merchandise from the 80s and any other clichéd Australian cr quality goods that I can find!

Thursday, 7 June 2012

WLAN Site Survey Toolkit

What Wi-Fi blog would be complete without a post dedicated to one’s site survey kit! I have compiled my own set of tools as I am somewhat particular about having all of the right tools for the job and having a Pelican case sitting there ready to go allows for a much smoother survey. I use my tools alongside a few tools from work - I can’t quite justify spending $3k on a certain piece of site survey software prone to BSODs... not mentioning any names of course ;)

Ideas for my kit came from fellow bloggers, books and my own experience. In particular, I borrowed ideas from Keith Parsons and a clever idea from Jennifer Huber. Keith has an excellent video detailing his WLAN kit, as of 2010. I also borrowed and modified a method of Jennifer’s for placing AP marker stickers on the ceiling (assuming the ceiling is within reach!). At the bottom of this post I have linked to some other site survey kit blog posts so that you can get a few alternative ideas.

The Kit
Essentially my surveying kit is comprised on two major components:
1)      The survey rig: The Caster Tray WiFi Surveyor
2)      The survey case: A large Pelican case that contains everything apart from the survey rig

The Survey Rig
We use the Caster Tray WiFi Surveyor for surveying. Whilst traditionally, site surveying has been done with home-brew rigs, I am very happy to have access to this piece of kit. It is essentially an all-in-one kit for mounting APs up to 4m in height and is comprised of a Pelican 1560 case and vinyl shoulder bag. The Pelican case houses a rolling tray, PoE battery holder and Terrawave PoE battery.  The vinyl bag houses the extendable pole that can extend up to 4m in height. I also use the vinyl bag to house a dowel rod that I use to place AP marker stickers on the ceiling. I find the Caster Tray rig makes the survey process much smoother and therefore quicker than the alternatives. It certainly isn’t cheap though!

The Survey Case
I use a Pelican 1560 case to house all of my surveying equipment. This is the same model of Pelican case that the Caster Tray WiFi Surveyor uses. So yes, it also means than I am carting around 2 x Pelican cases and the vinyl shoulder bag. I am fine with this as I would much rather have all of my tools on hand to ensure a smooth survey in exchange for the small inconvenience of having to wheel around a second Pelican case through the airport or a car park. The Survey case is home to the following equipment.

PowerDsine3001 Single-port PoE Injector
Used for the times where I need to reconfigure the AP whilst on-site. It is much smaller than the Cisco alternative – the PWR-INJ4.

Terrawave Site Survey Battery Pack
Whilst the WiFi Surveyor comes with one of these batteries it typically doesn’t last a full day, particularly if I am performing a dual-band active survey, which is usually the case. Previously I was switching the battery off between AP placements but now I just slot in the second battery when required and put the first on charge.

Double Adapters
I couldn’t find a small enough power board so these do the trick instead.

US to AU Power Adapters
Many adapters are bulky and the sockets are too loose causing the equipment being powered to easily fall out. These ones from Amazon don’t suffer from those issues. I use these to charge the Terrawave Battery Packs.

Spare Laptop Batteries
I take two to three spare batteries for the survey laptop. Due to the pain of swapping batteries whilst AirMagnet Survey is running, I try to find a free power outlet in between AP placements to provide a quick charge. I am in the process of trying to find a high capacity external battery for the laptop to take over the role of these batteries.

Second (Universal) Laptop Charger
There is quite simply only one reason I have this – I wasn’t going to drive home four hours after forgetting my charger on a recent survey. Woops! It may come in useful if I make the same mistake in the future.

Spare AA & AAA batteries
These spare rechargeable batteries are for my cordless mouse and laser measuring tool.

USB Wall Charger
This allows me to charge two USB devices via a standard power socket freeing up the laptop USB ports for the real work!

Measuring Tools
Leica DISTO D2 Laser Measure
This laser measuring tool can measure up to 60m (197 ft). It seems to have the edge over the equivalent Fluke tool and lives on my belt in its accompanying pouch.

These help locate the laser when using the laser tool outside in sunlight. I find that they help a little although they’re biggest advantage is that just make everything outside look awesome! On the down-side, they make you look like Bono (a douche-bag)!

Useful for measuring outdoors where the Leica often isn’t a feasible option.

Used for outdoor surveys where the laser measure or measuring tape may not always be great options. This is bulky and doesn't fit in the case, so is only taken when needed.

Wireless Adapters
I store all of my USB adapters in a pair of these cases - they are very good quality.

This hub is the perfect size and weight allowing it to be Velcroed to the back of the laptop screen in order to accommodate the required USB WLAN adapters / spectrum analysers. It is the same model hub that AirMagnet includes in a bundle with the Proxim Orinoco USB adapters that I also use, as detailed below. It is cheaper to buy the hub and Proxim adapters separately instead of through AirMagnet. Of course, this saving may be negligible compared with the several thousands of dollars you’re spending on AirMagnet’s survey software!

One of the few decent USB adapters that have external antenna connectors. It is useful for hooking up a patch antenna to locate rogue APs during the survey. It is also one of the most sensitive adapters available.

One of the few enterprise-grade 802.11n USB adapters. I use two of these for surveys with AirMagnet Survey Pro and the third for use with AirMagnet Wi-Fi Analyser for roaming analysis – though I am yet to have the opportunity to test all three with Wi-Fi analyser. One of them is also used with Tamos CommView for WiFi.

My preferred Spectrum Analysis hardware alongside the Metageek Chanalyzer Pro software. Unfortunately the dual-band DBx hardware doesn’t support concurrent dual-band operation, therefore I bought the Wi-Spy 2.4x to allow this functionality in Chanalyzer Pro. Why the 900 MHz-capable Wi-Spy 900x? I have performed survey’s where I had a suspected interferer in my sights but due to low signal and duty cycle, I couldn’t be sure if was operating at 2.4 GHz, 5 GHz or another band. The 900x allows me to eliminate such suspected interferers if that other band is the 900 MHz ISM band. On top of this, the forth-coming 802.11ah standard looks like it will use the 900 MHz band so I will be covered!

I also inter-change between Cisco SpectrumExpert and AirMagnet SpectrumXT spectrum analysers depending on what is available at work. My preference is to use the Metageek analysers though.

Hangs off my belt during the survey and looks fancy! Performs the usual multi-tool tasks. Sure, I don’t need a can opener whilst surveying today, but who knows what tomorrow might bring!

General tools
I keep various other tools in a small Pelican case (Pelican 1060) including a Swiss Army Knife, few small screw-drivers with inter-changeable bits, and a UTP punch-down tool.

I borrowed this idea from Jennifer Huber when it comes to AP placement markers (check out her blog post). I was initially using the same method with the ‘L’ shaped tape but lately I have just been balancing the sticker on the end of my dowel rod and then sticking it to the ceiling, saving a little time. On occasion I need to use the ‘L’ shaped tape if the sticker is to be placed on a wall instead of the ceiling or if placing it in front of an air-con duct. I did experiment with the tape on a Velcro loop on my belt but luckily I have moved on from that shameful display!

Various adhesive tapes
You name it – I’ve got it! Duct tape, double-sided tape, electrical tape, rubber tape and general office stationary tape.

Various other securing materials
Useful when something needs to be temporarily mounted – cable ties, Velcro and Blu-tack.

I like to carry around print-outs of the building floor plans during a survey rather than solely relying on the copy within the survey software. I was using a standard clip-board to carry these on however it didn’t fit into my Pelican case particularly well. I had a dream – a dream that someone else would have felt my clipboard pain and developed a foldable clipboard… and now look at me – the owner of an awesome foldable clipboard that folds in half and fits down the side of my Pelican case! This clipboard was developed for doctors to allow them to store it in their white-coats. Consequently, the clipboard lists of bunch of medical data on the back. As I have been surveying a number of hospitals lately, I feel this will come in handy. I can picture it now… I will be surveying in a patients room, a nurse will have an emergency on her hands and will require a doctor. I will say, “Worry not nurse – I have this handy foldable clipboard”. I will then flip it over and suggest that the patient is likely experiencing a Grade IV Cardiac Murmur based on it being loud with a palpable thrill! What could possibly go wrong?

Cables & Adapters
I carry various cables that come in handy at times including a short extension cord, kettle cord, UTP and console cable. I also carry various UTP adapters (UTP joiner, cross-over, loop-back, PoE tester, etc).

Digital Camera
Mobile phone cameras are typically good enough for AP placement photo’s these days but I still carry a real digital camera for times when I need optical zoom.

Although usually I am placing APs in the corner of rooms, occasionally I need to place the survey rig in the middle of a door-way or corridor. A traffic cone or similar warning is therefore needed and this foldable traffic cone easily fits into my Pelican case once folded.

WLAN Hardware
Access Points
The AP I use for the survey is that of the model planned for deployment. Lately this has been one of the Cisco 3500 series of APs.

Wi-Fi Clients
Whilst I calibrate my survey to the poorest WLAN client in the customer’s network, I also like to carry around a Cisco 7925G VoWiFi phone in case testing is required during a voice survey.

If a particular model of antenna has already been proposed in a high-level design or predictive survey I will take it to survey with. In addition I use the Metageek Device Finder 2.4 GHz patch antenna. This hangs off the top of the laptop screen and helps to locate non-Wi-Fi interferers when connected to one of the Metageek USB spectrum analysers or Wi-Fi interferers when connected to the Ubiquiti SR71 USB WLAN adapter.

Cables & Adapters
I carry a few low loss coax cables with various connectors (I’ve had these for 10+ years lying around in a drawer so am unsure of the type but they would be similar to LMR-200). I also have a small Pelican case (Pelican 1010) with various coax adapters and pigtails.

Other People's Survey Kits
Below are a few posts detailing some other bloggers ideas when it comes to survey kits.

Tuesday, 27 March 2012

Spectrum Analysis... disable the WLAN client, right?

The traditional recommendation when running PC-based Spectrum Analysis (SpecAn) software is to disable the WLAN client on the machine you are surveying / trouble-shooting with. If you don't disable it you will see the activity from your WLAN client displayed on your SpecAn. Even if your WLAN client is not associated with an AP, you will typically see the probe requests sent by the client looking for WLANs to join. Due to the distance between your SpecAn antenna and your WLAN client antenna(s), this activity will be displayed with a very high signal strength across the band as the WLAN client sends out probe requests, on all default or configured channels.

Are these probes a problem though? The probes requests represent a relatively small amount of traffic (low duty cycle or channel utilisation) and therefore the measured duty cycle or utilisation of the non-Wi-Fi devices you are trying to find won't be affected to any significant degree. Although Metageek Chanalyzer Pro now reports utilisation instead of duty cycle and they are not exactly the same, I will be using the term utilisation throughout this post for the sake of simplicity. When I am surveying the only non-Wi-Fi interferers I care about are those with a moderate-to-high duty cycle. If a non-Wi-Fi interferer has very minimal impact, it just isn't worth addressing (e.g. - a single Bluetooth device). With that in mind, the low duty cycle probe requests being transmitted by a WLAN client will not make it anymore difficult to identify the moderate-to-high duty cycle non-Wi-Fi interferers that I actually care about.

Metageek Chanalyzer Pro showing probes in red. The other activity is from a few nearby rogues and a cordless phone or two.
TamoSoft CommView for WiFi showing some of the probe frames.
A high duty cycle non-Wi-Fi interferer.
The screenshots above show:
  1) The probe requests from the WLAN client as seen in a SpecAn;
  2) The probe requests from the WLAN client as seen in a packet sniffer;
  3) The introduction of a high duty cycle non-Wi-Fi interferer alongside the probe requests.
As can be seen in the screenshots, the probe requests have not made it anymore difficult to identify this non-Wi-Fi interferer. Whilst this interferer is very close making it easier to identify, even in a real-world scenario the probe requests make next to no difference as they represent such a small duty cycle. When I perform a spectrum analysis survey I spend the majority of my time looking at the spectral density and duty cycle displayed. I only start to look at the signal strength when I am trying to locate one of these moderate-to-high duty cycle non-Wi-Fi interferers. I feel the best practice of disabling the WLAN client made sense in the past. However Metageek has since bought about the ability to view spectral density making it easier to find the non-Wi-Fi interferers that I actually care about (AirMagnet has since implemented similar functionality) - you shouldn't just be relying on the signatures found in Cisco Spectrum Expert and AirMagnet SpectrumXT!

In the past I would disable my WLAN client. The problem is that you lose Layer 2 visibility in your SpecAn software - essentially the software will no longer report the SSIDs that it hears which could have aided you in confirming that what you are seeing is in fact an AP. A number of times I have been performing a site survey with the WLAN client disabled and have seen what I suspected was an AP but due to a very low level of traffic it was hard to confirm this assumption. Often this was an AP with no associated clients and therefore the majority of traffic was from beacons being sent by the AP. Such an AP does not have a well defined signature making it harder to identify. Identification is made all the more difficult if the AP is not transmitting on a standard 2.4 GHz channel (1, 6 or 11).

Previous Sleuthing
I now leave my WLAN client enabled, benefit from the Layer 2 visibility and ignore the probes I see. I did however investigate other options. The (awesome!) CWDP book discusses this issue and suggests your WLAN client be put into a listen-only mode. I have never seen a WLAN client driver offer such an option however. After a little pondering, I realised that the key to this lies in RFMon (monitor) mode. RFMon mode is similar to the promiscuous mode that wired NICs are placed in when packet sniffing is performed. There are distinctions between RFMon and promiscuous mode but I won't delve into that here. Essentially, in RFMon mode, the WLAN client will be receiving frames but will not be transmitting them.

In order to utilise RFMon mode a specific driver must be used and in the case of wireless packet sniffers and site survey software, you most commonly see these drivers from the likes of OmniPeek, Fluke (AirMagnet) and TamoSoft, amongst others. I first tried looking at the advanced driver options of a Linksys AE1000 running a driver from OmniPeek for use with their wireless packet sniffing software.  This offers an enticing option which suggested it may put the driver into RFMon mode (unfortunately I don't have the driver installed anymore and can't remember the name of the option). After configuring this option my machine blue screened... yay! After a bit of a play, I managed to get Windows running successfully with the option set. A Spectrum Analysis soon followed but showed that when OmniPeek was not running, RFMon mode was not enabled despite the RFMon-capable driver being installed. Metageek Chanalyzer Pro still showed that the probe requests were being sent.

In hindsight this seems obvious. If the WLAN client with the OmniPeek driver installed was always running in RFMon mode you could never use it as a standard WLAN client and therefore could not use it to connect to any WLAN (not that an RFMon driver is recommended for standard WLAN use anyway).

I then moved on to AirMagnet SpectrumXT. To cut a long story short, I found an option in SpectrumXT that allows you to specify an AirMagnet-supported WLAN client for use when running SpectrumXT. AirMagnet has RFMon-capable drivers written for use in with their Survey and WiFi Analyser software. If you use either Survey or WiFi Analyser and also use SpectrumXT you can insert your supported WLAN client (Orinoco 8494 in my case) and configure SpectrumXT to make use of it. Essentially, you now have a Spectrum Analyser that is making use of a WLAN client that is running in RFMon mode. As an added bonus it also allows SpectrumXT to display other Layer 2 information that can aid in your survey / trouble-shooting.

Available under the 'Configure | Driver' menu. The 'driver' tab only appears when you have a supported adapter inserted.

As far as I can see, this is not possible when running Cisco Spectrum Expert or Metageek Chanalyzer Pro. This would require both of these SpecAn's to support particular WLAN clients and place them in RFMon mode. Whilst I felt this unlikely when I originally wrote the bulk of this blog post several months ago, Metageek has since released their own take on Layer 2 analysis in the form of Eye P.A. It now seems much more likely that Metageek may release some RFMon drivers or utilise the RFMon capabilities supported by Windows 7 for use in Eye P.A. which may allow their use in Chanalyzer Pro. Hopefully the former, as experience with RFMon in Windows 7 has shown it is quite bug-ridden.

Does it actually matter if Metageek (or Cisco for that matter) support RFMon-capable adapters in their SpecAn's? Based on my conclusion above, no, not really. I am happy to ignore this best practice whilst benefiting from the increased Layer 2 visibility and ignore the non-event that are the WLAN clients probes.