MR 30.1 - Unable to configure WPA3 w/ 802.11r

[RyGuy]

Has anyone been able to configure WPA3 & 802.11r on the new MR 30.1 beta firmware?

I have an MR46 & MR36H in a network running MR 30.1.

Dashboard continuously rejects the config, saying "The current WPA encryption mode does not support dot11r."

I've tried WPA3 Personal and Transition on an SSID, and no matter how closely I follow the KB I got the message above.

I tried enabling WPA3-Personal with 802.11r on an old SSID config and the error I get is a bit different

• dot11w (802.11w) cannot be 'required' when dot11r (802.11r) is enabled or adaptive.

WPA3 requires 802.11w, and dashboard automatically sets it as such (which is why it's greyed out).

Seems to be a config validation issue on dashboard. 

@Rodrigo_ - Is this a known issue?

[alemabrahao]

Há you opened a support case?

[RyGuy]

Just submitted one, very curious how such a basic issue was not noticed during QA. Does Meraki now just commit feature additions without verifying the feature can actually be configured on existing networks? The most basic of basic QA would have caught this.

QA Step 1: Upgrade existing network to MR 30.1

QA Step 2: SSID-A (Existing WPA2 Config): Attempt to configure WPA3 and 802.11r

QA Step 3: SSID-B (Existing WPA3 Config): Attempt to configure 802.11r.

[BlakeRichardson]

I get your frustration but how does any vendor release software updates and have bug. There are just so many variables that it would be impossible to test for everything. 

One example is why does Microsoft keep breaking its Windows VPN client with almost every update. 

[RyGuy]

@BlakeRichardson 

I mean, sure, there's a lot of moving pieces. But unlike windows client VPN which has

• A near infinite combination of configuration variables (both on the windows side and 3rd party VPN side...)
  • on top of 1000's of different NIC driver combination 
    • in a software package that itself has a million different moving parts
      • owned by 100s of different teams....

This is more one-sided,

• Meraki owns the process from start to finish.
  • The Software, hardware and management plane are owned by Meraki
  • There are only two dev teams that would have a stake in this feature. MR and Dash.
  • A KB that dictates exactly how to set this up results in an error

So while yes, it's impossible to test for every bug, this bug in particular showcases a glaring flaw/breakdown in internal communication and QA. MR-PM released a feature yet didn't properly test the one page in which the feature would be configured.

The most basic QA would have been to test an SSID in it's default state. No Encryption w/ Meraki NAT. Even moving from that to WPA3 w/ 802.11r fails.

@BlakeRichardson Have you found any config permutation that would allow the feature to be set?

[BlakeRichardson]

No I but I haven't tried, if its not working I would open a support case. As for quality control if you are not happy I would talk to your account manager. 

[WB]

Not great QA but it is only in Beta so always a risk...

[AlexanderN]

Hi folks, this is just a UI issue, and it should be addressed this week.

[AlexanderN]

We made the changes and tested them but did not get a chance to push them to the production Meraki dashboard, This will happen early next week.

[AlexanderN · Accepted solution]

This is resolved.