03-22-2015 08:29 AM
I'm posting this here because it may be helpful to some with dense deployments:
I've run across a problem recently where the channel widths were mis-reporting using various different wi-fi analysis tools. I'm running a 7210, Ver 18.104.22.168, with a mix of of 125's, 135's, and 225's. I was experiencing what turns out to be an unrelated problem, but in the process of troubleshooting, I turned the channel widths down to 20MHz for all SSIDs and radios. After I made the change, I spun up Wi-Fi Scanner on my Macbook Pro to verify. It was still showing 40 and 80 MHz channels. I tested with several other tools, including Tamosoft CommView for WiFi on windows and still saw the same reporting of 40 or 80 MHz channels. All the while, the dashboard on the controller is showing 20 MHz connections only.
After a lot of research and conversations with a number of people in the Wi-Fi community, we came to the conclusion that inside the beacon frames, under HT Info, a secondary channel was still being indicated even though 20 MHz only was listed under HT Capabilities. This one setting seemed to be causing all the fuss.
To be clear, this bug has no impact on operability of the network. Clients were working just fine and negotiating connections and talking just fine on 20 MHz channels as expected. I just couldn't verify that from the client side.
We checked with equipment from another vendor and found that when 40 and 80 MHz channels were disabled, the secondary channel was not indicated and channel widths reported correctly using the same tools on the same and similar hardware.
I did a full writeup of what we found here: http://goo.gl/Zu2PPS
The app developers I talked to said they will look at how their tools determine channel widths, but Aruba also need to fix the problem with reporting a secondary channel when none exists.