I haven't been able to find a way to disable 802.11a clients from connecting to the 5 GHz radio on an 802.11n AP. Regardless of Greenfield not yet supported, it would be desirable to ensure 802.11a clients can not connect to the 5 GHz radio. As the majority of 802.11a clients are 802.11a/b/g clients, these clients would instead connect to the 2.4 GHz radio. 802.11a-only clients obviously could not connect at all, but very few of these exist in the enterprise these days.
All discussion regarding band steering from Cisco and other vendors indicates that not only will 802.11n clients be steered to the 5 GHz band but 802.11a clients will also. Hence, a way to disable 802.11a support on the autonomous and lightweight APs would be nice. At least one 802.11a rate must be selected and I can see no other way of disabling support. Suggestions?
The alternative I am looking at currently is a script to detect whether the client is 802.11n capable and push them to the 5 GHz SSID. Else, they will get the 2.4 GHz SSID. If this script is based on chipsets instead of some O/S info that indicates chipset support, it will obviously mean that is requires maintenance to stay current with new chipsets, which is a pain.
Having worked with the IEEE Standards Association on the development of .11n I would say that writing a script is not very practical. There are way too many chipsets out there and a whole lot more being developed. As with all 802.11 protocols a part of the standard requires reverse compatibility. On 802.11a devices you would need to go to the advanced client driver settings and manually steer your clients to a 2.4ghz network. The standard, just like 802.11g, requires backwards compatibility. Band select is a feature that is rapidly gaining momentum for the next version of code to be working correctly. Just this week I had a customer advertising an SSID with both spectrums enabled. Needless to say this caused major issues with persistent client connectivity. I simply control my SSIDs for internal client connectivity. The real problem is when a guest comes in and has his laptop set for auto band selection. As he scans the available networks he forces the .11n network backwards. Not a lot I can do about that other than to steer him to the guest network by broadcasting the guest (2.4ghz) network and disabling the broadcast of my 5ghz networks in the hope that he associates quickly to the 2.4 network and doesn't hit his scan threshold. It's not pretty but it works.
Thanks for the reply Dennis.
I probably should have given more details but the environment I am concerned with is an enterprise comprising hundreds of sites / tens of thousands of machines. Obviously any driver setting changes are not scalable across (pretty much any) enterprise environment. I would expect that scripting such changes would be a nightmare even on a single chipset, let alone many of them.
I have a list of the almost 100 chipsets detected in our environment and so was planning to use this as the basis a script (not more than 10 of those chipsets would be 802.11n however). Of this 100, not more than 20 would be relevant to sites where this deployment it to take place. The script I am referring to would not change the band select of the driver (many drivers don't even seem to support it) but would detect the chipset and place the computer object in the correct OU, hence getting the relevant GPO and therefore SSID. I can't see a better solution than this at this point in time. Yes maintaining this would be a pain, but for the time being I see it as the best option.
As you say, band steering is a very important feature but I can't see it steering 802.11a/g clients into the "preferred" band anytime soon but would love to hear otherwise. Preferred in this case, in most deployments where capacity is a major factor, is the 2.4 GHz band.
Like you have mentioned, I have tested clients with a single SSID and the results were not pretty.
My preferred solution is to prevent 802.11a clients on the 5 GHz radio by disabling all 802.11a rates. This obviously works to prevent 802.11b clients from connecting in 2.4 GHz so the same support would be nice at 5 GHz. I could then advertise the 2 x SSIDs in a GPO and the clients (should) connect correctly, with any luck. I have done this previously and it works with the 802.11n and 802.11g clients... just not the 802.11a clients.
Disable 802.11a data rates in the 5GHz spectrum and just enablle the
higher 802.11n data rates , I think that would work
At this point, I think the only choice you have is to disable everything but the highest 802.11a speed and hope that only a few clients can actually connect at that speed. However, not having actually done it myself, I would be concerned that a few clients might become confused and get stuck trying to connect and failing.
I tried that a few weeks ago with 54 Mbps the only 802.11a speed. I had a few issues at the time and added back those lower rates although from memory there was actually another issue.
However in the past I have seen some clients have problems connecting when lower rates are removed. The other issue is that with this new deployment, the majority of clients will be able to acheive a 54 Mbps connection. I think I will just wait for Cisco to start supporting Greenfield and see how I go with that.
any updates on this?
I'm asking because I have several linux clients which don't realize that the 5GHz channel is set to 40MHz and thus fail to connect. This issue is with several distributions, but so far all with Intel WiFi adapters.
Which client devices are you using? I know Intel, but which chipset? The 1x1's dont support channel bonding fully. There appears to be a driver issue. Make sure that all devices support channel bonding or I don't use it.
Let me put it like this, the users use their own devices
So they have from the 2200bg everything until the latest 6xxx chipset. Luckily we don't have many linux users. They often have a 3945, 4965, 5100 or 5300 chipset. The problem gets even worse with the 4xxx and later chipset, as the driver also has problems to use 802.11n.
I actually advise those users to completely disable 802.11n in the module, otherwise they have similar problems.