Wireless Access

I enabled VHT on a set of AP-225s using AP specific configs, yet my 11ac clients are associated a-HT mode.  I verified that VHT is checked in the radio profile and in the HT SSID profile.  Here are the outputs to confirm the radio is running int VHT:

 

(controller) #show ap active | include AP01
AP01 XXXXXX X.X.X.190 0 AP:HT:6/12/21 8 AP:VHT:165/15/22 225 A2da 64d:11h:19m:50s N/A

 

(controller) #show ap bss-table | include AP01
6c:f3:7f:XX:XX:XX TEST-SSID N/A X.X.X.190 a-VHT ap 165/15/22 8 AP01 0 23d:6h:49m:24s 1500 - 2 T

 

I also did a packet captured and verified that the VHT field is not being advertised in the beacons.

 

I need a sanity check... what am I missing?

#AP225

I would try disconnecting a client and letting it attach back.

This has been over the course of a few days, so clients have disconnected/reconnected multiple times.  The fact that the VHT field is not being advertised in the beacons tells me VHT mode is not actually enabled.

When you do a show ap association, for the clients under test, what do you see?\

 

http://community.arubanetworks.com/t5/Mobility-Hero-Tutorials/ArubaOS-6-3-and-Above-802-11ac-Enable-VHT-even-if-you-are/ta-p/145689

 

Might have TAC take a look at firmware, config, and pcap to see why the VHT isn't advertising in the beacons.

What version of ArubaOS is this? There is a bug where that could happen.

Jay

is your AP deliberately being forced to ch165 for some reason (or has arm spazzed out) ? that is not part of the 80 Mhz plan, which is 149-161.. check for rogue ap-name and rf dot11a profile

regards

-jeff

Jeff,

Yes, I added 165 to the regulatory domain. We're using 20mhz channels.

I did have other APs on different channels not running in VHT.

Colin,

I can open a TAC case if you believe it's a bug.

ahhh.. duh.... my miswording - can you try changing it out of 165 ? the point I was more thinking (but not saying) was that 165 is not commonly used where "defaults and VHT are used" and it might be a glitch for non 40/80 mhz channel.

 

but, having said that, just to try it - forced 165 + ap205 + 7260 works ok (6.4.3)

ap205  ac:a3:1e:b7:df:30  5c:c5:d4:7c:a3:44  y     y      1    250    v1-7030-psk  1        0x1001b    a-VHT-20sgi-2ss  10s          1          WAB    0/0

 

strange one, if it starts working on channel change it will definitely be useful info for a ticket.

 

regards

-jeff

 

 

 

Colin,

 

6.4.2.8

 

Jeff,

 

Now this is interesting... I have two SSIDs on 5GHz.  One is advertising VHT in beacons, the other is not.  Both share the same HT SSID w/ VHT enabled.  I checked the AP on channel 165 and the VHT field is there for the 'secondary' SSID.

 

This seems like a bug to me.

TAC case open.  Sanity check cleared. :)  The engineer is trying to reproduce the issue in his lab.

Thecompnerd,

 

The bug is if dot11a-radio-profile VHT is disabled and ht-ssid-profile is enabled, it does not enable VHT.  Try checking to see if both the dot11a-radio-profile and ht-ssid-profile are both enabled.

 

They are.

In summary, the bug is disabling, then enabling VHT in the 802.11a radio profile does not re-enable VHT.  Please let us know what TAC says.

Based on your response, I decided to fool with it this evening after all the users left and got VHT working for all SSIDs.  Here's what I did:

 

1. Disabled VHT under HT SSID profile.  Saved settings
2. Waited and confirmed a-HT mode on APs.
3. Enabled VHT under HT SSID profile.  Saved settings.

I setup a remote capture and confirmed the VHT field is now advertised in beacons for all the APs' BSSIDs.  Also, checked ap associations and verified I have VHT clients connected.

 

This is reproducable.  I disabled VHT in the HT SSID profile and radio profile and saved changes.  Verified APs were back to a-HT mode.  Then, I enabled VHT under both profiles and confirmed VHT was only advertised by one SSID.  Disabled/enabled VHT mode under HT SSID profile and verified BOTH SSIDs advertised VHT.

 

Does this describe the bug you're aware of?

TAC was able to reproduce with version 6.4.2.8, but indicated the issue is resolved in 6.4.2.12.