802.11 Client Device Interoperability

New Contributor

802.11a High-order channel roaming issues

We have been having problems with mobile wireless thin clients dropping connections intermittently. Tracing the roaming history I noticed that the Atheros dual-band card on the thin client is having trouble attaching to AP's that are TXing at the higher-order "a" channels (149-165). Since clients drive the roaming handoff, I assumed it was this particular wireless adaptor that was the problem. Further testing with a Cisco/Linksys Dual-band adaptor, and with a MacBook Pro Airport card, I observed the same behavior. Now I'm not sure what I'm dealing with.. Anyone experience this issue before? This is my first experience with Aruba and we have a OAW-6000 with Sup 2, running version
Guru Elite

Re: 802.11a High-order channel roaming issues

That version of code is very old. I would start by updating to or the latest for your platform and take it from there.

*Answers and views expressed by me on this forum are my own and not necessarily the position of Aruba Networks or Hewlett Packard Enterprise.*
ArubaOS 8.5 User Guide
InstantOS 8.5 User Guide
Airheads Knowledgebase
Airheads Video Knowledge Base
Remote Access Point Solution Guide
ArubaOS Consolidated Release Notes
ArubaOS 8 ViA VPN Solution Guide
New Contributor

Re: 802.11a High-order channel roaming issues

Thanks for the reply. I agree, it is old. We tried upgrading twice but for other reasons had to back out. Went to an Aruba class recently and wanted to test a theory regarding this. We had 6.0 code on the 620 controller. My Laptop was connected with 802.11a as that is preferred. I created a new Regulatory domain with the higher-order "a" channels only and as soon as I assigned it to the AP Group, my laptop switched to 802.11g to retain connection. Put back the default with the full regulatory domain and it switched back to "a". I have seen similar behavior with 4 different adapters and 3 different platform OS..
Occasional Contributor II

Re: 802.11a High-order channel roaming issues

Dennis, two questions:

1) Are you using your 802.11A channels with APs in A/N mode (specifically 40MHz) or just traditional .11a in 20MHz mode?

2) When you have your high-order regulatory domain profile in place, have you tried running a packet capture session from that specific AP to see if you're getting probe requests from the specific client device? This would help narrow down whether your client device even considers it a valid channel to try to use.

For instance, I noticed that channel 165 was included in the 'default' regulatory domain profile under 3.x as a .11a channel (20MHz), but when using Network Monitor on a Win7 laptop (Intel Centrino 5300 chipset) it doesn't allow channel 165 as a valid channel for scanning. This is just one example case, YMMV depending on chipset, but you may run into similar findings. I'd give the packet capture noted above a try with your various devices and see if they ever try looking on your suspect channels.

Please let us know what you find, Aruba code version aside, supported channels on the client-side devices seems to still be a mixed bag.
New Contributor

Re: 802.11a High-order channel roaming issues

Good input, tks Jason..

Ref 1. Not sure. I need to get my hands on a Spectrum Analyzer. I can say that the 40 MHZ channel usage is checked under the High-Throughput Profiles, but no channel pairs are identified under the Regulatory Domain Profiles. Aren't the two related? Under our only "n" capable AP's (AP-105), the AP monitoring shows HT-20MHZ under "b/g" and HT-40MHZ under "a", but I'm not sure that is dictating real HT mode or what it is capable of.

Ref 2. I have not run a trace yet. Wasn't sure what I would be looking for. Your feedback is helpful, as although our lower-order channels (36 - 64) are checked, AP's are just using 36,40,44 and 48...

Time allowing, I will try the trace and let you know how it goes.

Thanks again
Occasional Contributor II

Re: 802.11a High-order channel roaming issues


#1) Correct, you'd need to have channel pairs defined in your regulatory domain profile in order for the APs to start using them.

Thankfully, no need to find a spectrum analyzer to verify what channels/channel pairs are being used. If you log onto the controller via CLI, run the command "show ap active" to display the APs and their currently used channels. Once you define 40-MHz channel pairs in your reg-domain profile, you should start to see your 105's using the wide channels, indicated with a "+" or "-" next to the standard channel number, like the following:


New Contributor

Similiar issue with Symbol / Motorola devices

We are also having a similiar issue with four of our very large scale warehouse deployments (200+ AP's):

Description of issue:

Symbol/Motorola clients are experiencing severe intermittent roaming delay while roaming through the warehouse. These delays times can be as long as 5-7 seconds. The application is thin-client and Wavelink telnet based. The delay is measured by pressing the enter key rapidly (about once every second) at a login screen while walking thru the warehouse. Delays are detected when the device does not receive the echo from the server.

Traces have been taken (with encryption on only) and multiple reauthentication requests were detected during delay times.


  • The wired network has been tested thoroughly and is under 24/7 monitoring.

  • A Laptop with an Intel 5100 chipset running the same test does NOT have this issue while roaming side by side with a Motorola device that actually experiences severe delay.

  • 802.11A coverage in warehouse is excellent with Airmagnet heat map conducted with minimum 25 SNR, NO holes. The Motorola devices are only allowed to use 802.11A .

  • Although the current encryption-type is WPA-2 AES, testing has been conducted with encryption DISABLED and has NO effect on the issue.

  • Testing with fast roaming enabled or disabled has NO effect on the issue.

  • Testing with high-throughput enabled or disabled has NO effect on the issue.


  • Dual Aruba 6000 controllers (standardized on

  • AP70's at two locations and AP 124/125 at two locations

  • HP2610 Switches at Distribution Layer

Clients and driver builds:

  • Motorola / Symbol VC5090 (latest Fusion .23B)
  • Motorola / Symbol MC9090 (latest Fusion .23B)
  • Motorola / Symbol MC9500 (tested both Jedi .08R and hotfix .20R)

Channel Configuration:

ap regulatory-domain-profile "default"
country-code US
valid-11g-channel 1
valid-11g-channel 6
valid-11g-channel 11
valid-11a-channel 36
valid-11a-channel 40
valid-11a-channel 44
valid-11a-channel 48
valid-11a-channel 149
valid-11a-channel 153
valid-11a-channel 157
valid-11a-channel 161
valid-11a-channel 165
valid-11g-40mhz-channel-pair 1+
valid-11g-40mhz-channel-pair 5-
valid-11g-40mhz-channel-pair 7+
valid-11g-40mhz-channel-pair 11-
valid-11a-40mhz-channel-pair 36+
valid-11a-40mhz-channel-pair 40-
valid-11a-40mhz-channel-pair 44+
valid-11a-40mhz-channel-pair 48-
valid-11a-40mhz-channel-pair 149+
valid-11a-40mhz-channel-pair 153-
valid-11a-40mhz-channel-pair 157+
valid-11a-40mhz-channel-pair 161-

Any thoughts?
New Contributor

Re: 802.11a High-order channel roaming issues

I wish I had words of comfort. I did find out that the HP thin clients we are using "do not support roaming." These were recommended by our VAR for mobile carts :--( They will connect to different AP's (low-order channnels) but the handoff is slow....and if we stand directly under an AP running high-order channels, it will connect after about two-minutes of indecision.

I tested last week with a Wyse thin client (dual-band wireless adapter) and the roaming hand-off is smooth as silk, even with the AP's txing on higher order "a" channels so the wireless environment seems to be exonerated. Why the HP thin client, Linksys dual-band USB card, and MAC Airport I tested with don't like those frequencies is still a mystery. I need to check some traces as Justin recommended and see what is happening behind the scenes.

You might check with Motorola but I didn't get any helpful responses with Alcatel or HP. Just some "try this" scenarios which didn't work....

I have changed our regulatory domain to all 802.11a "low-order" channels until we can get these thin clients changed out...