How do WiFi SSID Scanners Identify Channel Widths?

I've been having some trouble with various OSX devices being sticky and wanting to connect to an Aruba 225 when there's a closer 135 available. SNR difference between the two is over 10 dB in favor of the 135. The 135 also ends up with a lighter load because of the availability of the 225, so the controller attempts to load balance them back to the 135 (or at least off the 225), but because of the stickiness of the OSX stations, the forced roam fails. At least that's what it looks like to me.

• Update on the issue above: Turns out that OSX does not support Opportunistic Key Caching. If OKC is on, then Validate PMKID also needs to be enabled in order to avoid roaming issues with Macs. I'm not running a voice environment and could probably disable both without concern, but if the environment is mixed, then it seems best (and is recommended by Aruba) to make sure that both are on. Current Aruba defaults have it enabled, so Validate PMKID was accidentally disabled, or it was off in a previous version and was never updated in the upgrade path.

So, in an effort to make sure I'm not dealing with any other issues like CCI or other noise, I go into the controller and disable 40MHz and 80MHz channel usage in the High-throughput SSID Profile for all SSIDs that have it enabled. At this point, the APs are supposed to dial back all in-use channels to 20MHz and it's supposed to happen pretty quickly. Then, the next time the ARM cycle runs, it will redistribute assignments based on the newly available channels.

I disabled 40 and 80 MHz channels over a week ago and saw these results. I let it sit over spring break (little to no building occupancy, minuscule wifi usage) and tested again yesterday and today. On a MacBook Pro running OSX 10.10, using this list of utilities, I get somewhat inconsistent results:

• WiFi Signal 3.3 (7) - 40 MHz channel width
• WiFi Scanner 2.6.2 - 80 MHz channel width
  
• InSSIDer 1.3 (16) - 40 MHz channel Width
  

At this point I sent out a tweet asking who's lying to me, because someone's obviously incorrect here. Where's the truth?

At the request of Zaib Kaleem, @WLANBook, I did a frame cap this morning, and pulled a beacon frame from an Aruba 225. Here's the HT Capabilities section from the .11 management frame:

The highlighted row shows 20MHz only, and below that the HT Short GI for 40 MHz is disabled.

The VHT Capabilities section looks like this:

This shows Short GI for 80 and 160 MHz not supported. 

The only place where I can find that 40MHz may be supported is under VHT Operation:

I don't see anywhere else in the frame that would indicate channel width or any other frames that would have further information. If you know, please feel free to enlighten me, because I need to learn.

I used AirTool to do the pcap and Wireshark to look at the data.

Here's the pcap file. Looking at this, we filtered on wlan.bssid == 9c:1c:12:80:26:b0

If/when I figure out more and/or get schooled by the pros, I'll update this post with the followup details.

Update 1: On recommendation from @WiFivomFranMan, I did a cap with just 20, with 40 enabled, and with 40 and 80 enabled. In each cap, on a beacon frame from the same AP for the same SSID I see the following changes at "Management Frame > Tagged Parameters > VHT Operation > VHT Operation Info > Channel Width:

• 20 Only: 20 MHz or 40 MHz (20 MHz pcap on cloudshark)
• 40 Enabled: 20 MHz or 40 MHz (40 MHz pcap on cloudshark)
• 80 Enabled: 80 MHz (80MHZ pcap on cloudshark)

To be clear, I'm just disabling the 40 and 80 MHz channel widths but leaving HT and VHT enabled (separate settings).

Update 2: With info from Andrew von Nagy (@revolutionwifi),  @WiFivomFranMan, and Adrian Granados (@adriangranados)...

 I started looking at the 802.11 spec. HT Capabilities can be 0, indicating 20 only, or 1, indicating 20 or 40 MHz. When I'm set to 20MHz only, I see a 0 here, appropriately. Under VHT Capabilities, I also see a 0, but this indicates 20 OR 40.

If I enable 40MHz channels, I get a 1 under HT Cap. If I enable 80MHz channels, I get a 1 under HT Cap (20 or 40) and a 1 under VHT Cap, indicating 80, with a VHT Op showing 80.

Another note: With only 20MHz chan. width enabled, under HT Info Subset 1, I still see a secondary channel indicated as above the primary. Depending on the packet analyzer used, this can also show up as HT Operation.

Adrian Granados supplied me with this, which helps greatly:

So, based on this info, I really am operating at 20MHz channels only, the indication of that is just really complex, but I'm pretty sure I have it configured correctly.

What do you think?

Update 3: I got to thinking last night about the lingering indication of a secondary channel despite the 20MHz channel width. I'm wondering if it could be:

• A record that doesn't get cleared out of the ARM database when channel widths get dialed down.
• An AP config line that doesn't get removed when channel widths get dialed down.
• An actual requirement to be specified because HT and VHT are enabled even though 40 and 80 MHz channel widths are disabled.
• A specification coming from the code that enables HT and VHT instead of the part that implements channel widths.

On the controller I did show ap details ap-name Technology and I see this for Radio 0:

Under show ap config ap-name Technology I find this:

These two seem to conflict, but because VHT is enabled, the 80MHz channel group is still defined, regardless of fact that 40 and 80 MHZ channels are disabled.

I also went through show ap tech-support ap-name Technology, which is crazy long, but didn't find anything else new. Are there other places to look for this information?

Update 4: As requested by Zaib, here's what the CoreWLAN API is reporting:

It doesn't show here, but the MCS reports at 8.

The aruba config is still set to 20MHz and the controller is reporting that the client PHY is ac 20MHz.

Anyone know an Apple dev we could talk to?

I've posted this issue on the Apple Support Community to see if I can get any feedback there. Here's the link: https://discussions.apple.com/message/27853602#27853602

Update 5: Despite the misreporting of the channel width in the CoreWLAN API, the PHY is working correctly and running on 20 MHz channels, so the driver/firmware have it right. It just seems that the CoreWLAN API is making an incorrect assumption based on the presence of a secondary channel.

Because it seems like a lot of the problem is coming from the Apple side, I ran a quick scan using CommView for WiFi on the same hardware but booted into the Windows 10 bootcamp partition, and got the same results. CommView reports the channel width as 40 MHz. This may be because of the Apple bootcamp drivers installed using the same assumption as CoreWLAN, but I'm not sure.

Here's the screenshot of CommView: