One of tweaks I looked at was disabling 802.11a support. Disabling 802.11b support is well understood and an easy way to reclaim a large portion of 'lost' 2.4 GHz bandwidth. Disabling 802.11a support, on Cisco infrastructure at least, is not nearly as easy. Trying to disable all 802.11a data rates does not work on a Cisco WLAN controller as works when disabling 802.11b rate support. Attempting it results in the following:
|The error even comes complete with a missing whack of the space bar. Wait... should there be a space between space and bar?!?|
Perhaps Cisco will allow the disabling of 802.11a rates when they finally support the 802.11n Greenfield protection mechanism. A few posts on the Cisco forum suggest that a newer chipset is required, though these posts are from around 2009. Fair enough, but there has been plenty of 802.11n APs since the Cisco 1250 series APs but alas... still no support. Certainly, there would be very few environments were Greenfield could be enabled at 2.4 GHz currently due to the massive installed base of legacy 802.11g clients. 5 GHz is a different story however. Due to the remoteness and low population density of much of Western Australia, I can think of many WLANs where it could be enabled with few concerns for the 'bad neighbour' issues that enabling it can apparently present. To be fair, there seem to be few, if any, enterprise vendors that support Greenfield.
So, Greenfield - not an option. I next looked at disabling all 802.11a data rates apart from 54 Mbps. The logic was that I may at least be able to limit 802.11a client associations to only those that could achieve a 54 Mbps data rate. You have to be careful when disabling data rates as it can cause some clients to break... and that was exactly the result. A particular a/b/g client could authenticate (802.11 authentication) and associate but broke somewhere during the 802.1X authentication.
The Final Solution
This is a workable solution in a very small WLAN deployment. This particular deployment was designed for roll-out to between 100 to 200 sites covering several 10s of thousands of machines - manually disabling 802.11a support in the driver would not scale.
The solution? I got a list of NIC chipsets from the software deployment / device inventory tool. I culled the non-WLAN chipsets from the list and then pulled out all of the a/b/g chipsets from the list. There were no 802.11a-only chipsets as is to be expected in the vast majority of enterprise environments. Clients with a/b/g chipsets made up around 10% of the total number of WLAN clients - this was a high enough percentage to make this worth the effort. From this list, I pulled out the chipsets that accounted for the majority of a/b/g clients. Around 90% of the clients contained either a particular Atheros a/b/g or one of two Intel a/b/g chipsets.
For each of the three chipsets, I then found the registry key that contained all of the settings that the advanced driver tab modifies. I found a machine with each of these chipsets, RDP'ed into the machine and opened the registry key. I changed the setting under the advanced tab of the driver from the default of a/b/g to b/g, refreshed the registry key and noted the new value. 802.11b support was disabled on the WLAN controller so b/g instead of just 'g' was not an issue.
With these registry values in hand, I had a startup script written to detect the client chipset and if one of these three chipsets were detected, modify the registry value in order to disable 802.11a support. This worked very well and resulted in the vast majority of clients on the 5 GHz band being 802.11n clients. Not a 100% perfect solution but pretty close without needing to spend time disabling the small number of a/b/g chipsets that didn't contain one of these three chipsets.