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:

Marriott finally finds out what it's like to pay exorbitant fees for WiFi (updated)

Recently, the FCC fined Marriott for "jamming" My-Fi devices. Marriott will pay a $600,000 fine for using de-auth attacks on WiFi client devices attempting to connect to visitor owned My-Fi devices on unmanaged SSIDs.

Marriott claims that it was doing so to reduce interference with the operation of their network and to reduce security threats to the users of its network.

The FCC's decision is that there is no credible and specific threat to the Marriott network and that WiFi devices are not allowed to interfere with prevent the normal operation of other devices under the applicable FCC regulation (Subsection 33, Section 47 of the US Code).

I understand what the Marriott was trying to do. I get what the FCC is trying to accomplish. I don't think either side is handling the situation the right way. Here are some of my objections questions:

Inherently, WiFi devices cause interference with each other. Bringing third-party unmanaged devices into a facility with a managed airspace causes unwanted and unpredictable interference within that managed airspace. So, technically, under the same regulation that the FCC is using to fine Marriott, can Marriott now file FCC complaints against its customers who bring in devices that interfere with the Marriott's networks?

Interference is not the same as blocking/jamming/preventing the proper operation of.

In facilities where connections to the outside world need to be managed, monitored, and secured, including those where retail transactions occur, where credit card transactions are stored, where PCI-DSS certification is required by law, don't facilities need to be able to deter these foreign, unmonitored connections by whatever means necessary? In a world where these exist, don't the owners of businesses have the right to protect their internal networks and airspaces? If I had penetrated Marriott's network and wanted to exfiltrate credit card info or client purchase records, I would prefer not to ship that data out of Marriott's heavily secured perimeter, trying to circumvent any compliance monitors they may have running on outbound traffic. If I was able to get penetration hardware like a pineapple onto an internal network, I could also easily connect said device to a My-Fi device for exfil. Being able to controls these rogue AP's is actually essential to network security. This is exactly why there are WIPS that perform this type of function.

Generalized disabling of devices just because they're a potential threat is not permissible, particularly in the unlicensed spectrum. Only if there is documented action on a vulnerability can there be corrective action, especially when considering the wording of the Consent Decree. Other methods of mitigating the vulnerabilities must be utilized.

The FCC's interpretation of the situation is that any behavior that interrupts the intended function of the hardware is considered "jamming". But I don't think they got this right. Jamming would render the entire channel useless to all users, regardless of the protocol or SSID. Marriott was not jamming the unlicensed frequencies. It was not rendering all WiFi services useless or preventing usage of the frequency for anyone. It was preventing the use of unauthorized devices that were causing co-channel interference on its existing managed network, not by abusing the radios or the frequencies, but by utilizing the normal function of the protocols.

Reading the language of the applicable FCC regulation, it's the content that can't be interfered with because it exists within the regulated medium. 

As for Marriott, sure, movie theaters and stadiums usually won't let customers bring in outside food. But in those industries, those are the main sources of profit for the venues. Theaters make almost nothing on ticket sales, but that $18 tub of popcorn cost them $0.85. It's how they keep the lights on. That's the entire business model. The hotel/convention hospitality industry has profit centers in almost every aspect of the business. The margins vary, but charging between $250 and $1000 for internet access is flat out price gouging. Services like local phone access, cable tv, and wireless internet access are utility and should be treated as such. In an ever growing industry, hotels will eventually realize they will lose customers, conferences, and conventions when charging rates like this. I know. I've been a customer. We specifically chose a non-Marriott venue for an upcoming event due to Marriott's tendency to drastically overcharge for services and equipment rentals.