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. |
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.
Conclusion
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.
