AKM Suite Count: 2 – Benefit and Downside of an 802.1X & PSK Hybrid SSID


In this blogpost, I’d like to show you how a single SSID with both 802.1X & PSK enabled looks like, what the use-cases for this constellation are, and what could go wrong when you decide to implement it.

Warning in advance: Use this option with caution – there are some pitfalls!

RSN Information Element

Since the introduction of IEEE 802.11i and the Wi-Fi Alliance certification “WPA2”, the proper way to establish an 802.11 connection between a Client STA and an Access Point looks something like this:


After Open System Authentication and Association, the 3rd step initiates the WPA2 authentication process, based on the authentitation configured (PSK or 802.1X).

Hint: When there is no security enabled (“None“), which is fairly common in guest networks, no further authentication takes place (maybe a captive portal, but this is no “real” authentication).

When you enable PSK or 802.1X authentication on an SSID, the Beacons and Probe Response Frames include the RSN Information Element, which amongst other things defines the type of encryption and authentication:


RSN Information Element with 802.1X Authentication

In an 802.1X-Protected WiFi, inside the RSN Information Element, the AKM Suite Count ist set to 1 (this indicates that only 1 type of authentication is allowed) and the AKM Suite is set to 00-0f-ac:1 (the 1 indicates that the Suite type is 802.1X):


RSN Information Element with PSK Authentication

In a PSK-Protected WiFi, inside the RSN Information Element, the AKM Suite Count is set to 1, too, but the AKM Suite is set to 00-0f-ac:2 (the 2 indicates that the Suite type is PSK):


RSN Information Element with 802.1X & PSK Hybrid Authentication

The 802.11-2016 Standard states (subclause – “AKM suites”), that you are allowed to enable both 802.1X & PSK simultaneously, which allows you to operate an SSID with two different types of authentication methods:


NOTE—Selector values 00-0F-AC:1 and 00-0F-AC:2 can simultaneously be enabled by an Authenticator.


If both 802.1X and PSK authentication are enabled in an SSID, inside the RSN Information Element, the AKM Suite Count is now set to 2 (as there are now 2 allowed types of authentication), and below, both 00-0f-ac:1 and 00-0f-ac:2 are listed as valid AKM Suites:


Use Case for 802.1X & PSK Hybrid Authentication

I personally can see 2 valid reasons to use both 802.1X and PSK within the same SSID:

  • Migrate a WiFi from PSK to 802.1X:

To avoid adding a new/different SSID to your environment when you want to migrate your existing SSID from PSK to 802.1X, you can enable both authentication methods on the same SSID. The hybrid-situation would only be temporary, until every client is reconfigured (either via GPOs or manually). After the migration, you can disable PSK, and it would run as a “pure” 802.1X.

  • Onboarding MDM/BYOD-Devices

We were interested in using this as an option to onboard MDM/BYOD-Devices. Users could then connect their devices to the WiFi by entering a PSK, and their device would end up in a VLAN with restricted access to only our MDM/BYOD-Solution, where they could onboard themselves. During onboarding, they would get a user-certificate and the WiFi-Profile would get overridden to 802.1X. After disabling and enabling the WiFi, the device would reauthenticate, but this time via EAP-TLS, and thanks to Dynamic VLAN Assignment, they would end up in the appropriate VLAN.

Problems with 802.1X & PSK Hybrid Authentication

In the example of MDM/BYOD-Onboardung, there are some fundamental problems:

By enabling both 802.1X & PSK on the same SSID, you give every Client STA 2 options to connect to the WiFi. Well, this doesn’t sound so bad, right? But the problem lies underneath that… The coder of every operating system wants to make everything as simple as possible for end users. So when you click on a new SSID, you don’t have to decide wether you would like to connect to a “WPA Personal”, “WPA2 Personal”, “WPA Enterprise” or “WPA2 Enterprise” network – you automatically get the appropriate prompt to enter your Passphrase or Username/Password. This all happens based on the content in the RSN Information Element from within the Beacon or Probe Response Frames.

But now there are 2 different options in this element – which means that depending on the decision the Client STA makes, you either get a PSK-Prompt or a Username/Password-Prompt.

The workaround for this would be to instruct the users to not click on the WiFi, but rather manually create a new WiFi-Profile on their device on their own with the appropriate settings, which is very complicated for the people that are not really tech-savvy.


The 2nd problem is, that even once the WiFi-Profile was properly configured on the Client STA, some of them were not able to connect to the WiFi. Some of them sent out a Probe Request, but ignored the respective Probe Responses (probably because they thought that it was an AKM Suite mismatch), while others started the PSK 4-Way-Handshake, but after the 2nd Message decided to start an 802.1X Authentication, which of course eventually failed:


After all the tests I did, I have to say, that I would not recommend to enable both 802.1X and PSK on the same SSID in a live-environment – simply because you do not really have control over the end-systems and their behaviour.

Cheers Renzo

How A Hidden SSID Can Impact Your Roaming Experience


While there is the IEEE Standard 802.11 that defines the Wireless LAN technology, there are some settings (let’s call them tweaks) the AP-Manufacturers let you implement that are supported by the vast majority of the client devices, but are not part of the 802.11 Standard itself.
Arguably two of the most popular ones amongst them are:
– Hidden SSID
– Don’t Answer Broadcast Probes

I myself was fond of these settings for a long time, but had to reconsider them after I stumbled across a problem a couple of months ago.

Hidden SSID

Hiding your SSID will remove (null) the SSID Element in the Beacon Frames and Probe Response Frames.

Despite the fact that (on first glance) this looks like a good way to secure your WiFi, it should NOT be considered a security feature: Every person that is a little technophile is able to get his/her hands on your SSID, even if you hide it, because an SSID cannot be removed from Association Request and Reassociation Request Frames.
But hiding the SSID can still be considered a handy feature: if you have a guest WiFi and an internal WiFi, you can prevent guests from accidentally trying to access the internal WiFi by hiding it, and therefore protect your helpdesk from  unnecessary phonecalls.

Don’t Answer Broadcast Probes

As an addition of listening to Beacon Frames (Passive Scanning), a client can send out Probe Request Frames (Active Scanning) to get an overview of the available Wireless LANs in earshot.
Beside the possibility to send a Direct Probe Request to one of its known SSIDs (“Hey “HomeSSID”, are you there?”), there is the option to send Broadcast Probe Requests, where no SSID is specified (“Hey, is somebody here”), upon which every WiFi that hears this request has to answer with a Probe Response Frame.

Because in our case, every client that was allowed to connect to the internal WiFi got the internal WLAN profile manually configured and therefore “knew” its SSID, we decided that the internal SSID should not answer to Broadcast Probe Requests to reduce the amount of unnecessary Management Frames.

How These Settings Can Impact Roaming

Roaming is such a big topic itself that it deserves its own book, so I am not going to open this whole can in this blogpost.
Fact is, that the roaming decision is made by the client – normally when it hits a certain threshold (based on signal strength, SNR, error-rate, etc.). This threshold is different from manufacturer to manufacturer, from driver version to driver version, and they never disclose them, so there is only a guesstimation we can make to say at what point a client is going to roam.
When a client hits this custom threshold, it starts to look for new APs within the same ESS it can roam to – so besides only listening to the Beacon Frames, it starts to send out Probe Requests.
These Probe Requests are usually Direct Probe Request, because the client wants to connected to an AP within the same ESS, and not to a different or new SSID.
But I discovered a client that was new, but had a really cheap 802.11g NIC built in, and unfortunately sent out Broadcast Probe Requests when it wanted to start roaming.

The consequence of this behavior  (in combination with the 2 settings described above)  was, that the client desperately tried to find a new AP it could roam to, but never got an answer, and consequently stayed on its AP until it lost its connection. Ironically, after the disconnection, the client sent out a Direct Probe Request and was able to reconnect to the WiFi again.
But because the client was not able to properly roam and had to disconnect and reconnect every time, there was always a downtime of ~30-60 sec.


I hope this post is helpful for some of you out there facing a similiar problem.

Cheers, Renzo

Violation of 802.11 Standard? – Intel Wireless Cards send “40MHz Intolerant”-Bit in 5GHz


Some of our customers have their offices in multistory buildings with other neighboring companies and residents. As most of you are familiar with, in situations like these, the 2.4GHz frequency band looks like the Wild West – often, people choose a random channel between 1 and 11, and sometimes, they even think that using 40MHz channels in the 2.4GHz frequency band will improve their performance, because “the higher the data-rate, the better”…
To at least get rid of the latter, I thought about setting the “40MHz intolerant”-bit on our managed clients – and did some lab tests with interesting results.

20MHz- vs. 40MHz-Channels – Quick and Dirty

With the 802.11n-2009 Amendement, the possibility to bond two 20MHz-channels together to a single 40MHz-channel was introduced. This feature alone improves the data-rate by 108/52 (by factor ~2.077 – as the number of data-subcarriers increases from 52 to 108).
But this enhancement comes at a cost: when using 40MHz-channels, the number of non-interfering channels decreases. This is not a big problem in the 5GHz frequency band as there are still 9 available 40MHz-channels in Switzerland:

In contrast to the 5GHz frequency band, in the 2.4GHz frequency band, the available spectrum is very limited, and it allows only one 40MHz-channel, which will cause at least CCI, and at worst ACI, as soon as there is a second AP within earshot.

The “40MHz Intolerant”-Bit

Because of the inevitable problems that would occur in the 2.4GHz band when 40MHz-channels are used, the “40MHz intolerant”-bit was introduced as a failsafe-function in the 802.11n-2009 Amendement.

The 40MHz intolerant bit is set in the “HT Capabilities Element” => “HT Capabilities Info Field”, which is a part from the following management frames:
– Beacon
– Probe Request
– Probe Response
– Association Request
– Association Response
– Reassociation Request
– Reassociation Response
This allows either an AP or a client STA to indicate that they do not allow 40MHz-channels in the 2.4GHz frequency band by setting the “40MHz intolerant”-bit to 1, and the neighboring STAs have to adjust to this. Or to put it in simpler terms:

“If you do not have any close neighbors, you can use either 20MHz- or 40MHz-channels – whatever floats you boat. But if there is someone else within earshot that wants to use the 2.4GHz frequency band, you have to adjust your fat channel if he wants you to”

As described in the 802.11-216 subclause 11.16.11 (“Signaling 40 MHz intolerance”), the “40MHz intolerant”-bit is defined to be a feature only for the 2.4GHz frequency band and that it has to be set to 0 in the 5GHz frequency Band:

An HT STA 2G4 shall set the Forty MHz Intolerant field to 1 in transmitted HT Capabilities elements if dot11FortyMHzIntolerant is true; otherwise, the field shall be set to 0.

A STA 2G4 shall set the Forty MHz Intolerant field to 1 in transmitted 20/40 BSS Coexistence fields if dot11FortyMHzIntolerant is true; otherwise, the field shall be set to 0. A STA 2G4 that is not an HT STA 2G4 shall include a 20/40 BSS Coexistence element in Management frames in which the element may be present if dot11FortyMHzIntolerant is present and dot11FortyMHzIntolerant is true.

A STA 5G shall set the Forty MHz Intolerant field to 0 in transmitted HT Capabilities elements and 20/40 BSS Coexistence fields.

Lab Testing

So far so good.

First, I got myself some test notebooks:

Dell Latitude E7440 with Intel Dual Band Wireless-AC 7620 (Driver

Dell Latitude E6440 with Intel Centrino Ultimate-N 6300 AGN (Driver

They both had the setting “Fat Channel Intolerant” available, so I did some research on the Intel website:


It says that it is only available for certain adapters. None of the 2 mentioned above are included, but still, the option is available for both of them in the advanced adapter settings, so I decided to give it a shot anyways.

After I changed the setting on my Intel Centrino Ultimate-N 6300 AGN, I wanted to check the result and did some packet capturing in the 2.4GHz band:

As you can see, the “40MHz intolerant”-bit is set to 1, which is exactly what I wanted.

So the client was connected to the 5GHz band, and was sending its Probe Requests in the 2.4GHz band with the flag set.
But then, I started to see some strange behaviors on the 5GHz-SSID I was connected to – it looked like the SSID was only sending with a 20MHz wide channel instead of the configured 40MHz:

Even a different client that was connected to the same SSID was suddenly only using a 20MHz-channel:

So I started capturing some packets in the 5GHz band and was shocked to see that the STA with the “Fat Channel Intolerant” setting set to “Enabled” was sending the “40MHz intolerant”-bit in the 5GHz band aswell:

To make sure that this is not only a malfunction on one adapter, I did the same tests with the Intel Dual Band Wireless-AC 7260 and got the same results…

I can’t say if this occurs with the adapters listed as “supported” on the Intel website aswell, because I don’t have them available at my place,.

As far as I am concerned (based on my interpretation of the 802.11-2016 subclause 11.16.11), the 2 tested Intel wireless cards do not follow the standard and you should not use the setting “Fat Channel Intolerant”, as it impacts your 5GHz aswell!

I welcome you to give me an explanation about this issue  if you have any- am I right with my statement, or am I off the track?
If you have any questions or feedbacks, please don’t hesitate to write a comment or contact me (but please be kind, as this is my first ever blog post ;-))

Cheers, Renzo