Wireless MR 27.1 released

[rhbirkelund]

Release notes

Important notice

• This version, and subsequent MR 27.x versions, are only supported on the 802.11ac Wave 2 and 802.11ax MR product portfolio. 802.11ac Wave 1 and older products will not upgrade, should they be in networks configured for MR 27.x versions, and thus the new features will not be available and the bug fixes listed will not apply.

New

• WPA3 Support https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/WPA3_Encryption_and_Configuration...
• Meraki Health wireless performance metrics and client timeline https://documentation.meraki.com/zGeneral_Administration/Cross-Platform_Content/Meraki_Health
• Firmware Upgrade Strategy https://documentation.meraki.com/MR/Other_Topics/Access_Point_Firmware_Upgrade_Strategy
• Network-based Application Recognition “NBAR” https://documentation.meraki.com/MR/Firewall_and_Traffic_Shaping/Network-Based_Application_Recogniti... (802.11ax MRs)
• iPSK without RADIUS https://documentation.meraki.com/MR/Encryption_and_Authentication/IPSK_Authentication_Without_RADIUS NOTE: Careful consideration must be made if the network is downgraded to a previous MR26.x release. The SSID using iPSK without RADIUS should be reconfigured to use an appropriate SSID configuration supported on MR26.x. Otherwise, the SSID will remain enabled as an “Open” SSID.
• Meraki Local Auth https://documentation.meraki.com/MR/Encryption_and_Authentication/Meraki_Local_Authentication_-_MR_8...
• Adaptive Policy https://documentation.meraki.com/zGeneral_Administration/Cross-Platform_Content/Adaptive_Policy/Adap... NOTE: Careful consideration must be made if the network is downgraded to a previous MR26.x release. The switch interfaces must have tagging disabled for the access points to establish cloud reachability post downgrade.

Bug fixes

• General performance, stability, and security improvements.
• MR sent management frames as well as broadcast & multicast frames at the incorrect bit rate after a channel change.
• Wireless Health latency stats were not being reported for the MR45 & MR55. (MR45/55)
• Modification of RADIUS Accounting Start delay timer enabled by Meraki Support was not taking effect (MR45/MR55)
• MR would not send traffic to a client that did not first send a packet after receiving an IP address (802.11ac Wave 2/MR45/MR55)
• MR would not forward EAP-TLS Server Hello packets from Authentication Server to Supplicant if configured for minimum bit rates less than 12mbps
• MR in CE regulatory domain does not send EAPOL Key 3 message to 802.11b/g clients on PSK SSIDs (MR45/55)
• Successful client authentications on a MAC-auth SSID resulted in authentication failures reported in Wireless Health
• Traffic between multiple wired clients connected to an MR30H LAN port would exhaust the memory on the MR, leading to instability (MR30H)
• MR could become unstable while taking packet captures from Dashboard and reboot (802.11ax MRs)
• MR was intermittently logging 802.1x authentication failures as PSK authentication failures
• VLAN tag received via RADIUS response was not being properly ignored for MAC authentication SSIDs when configured to do so
• High latency could be encountered on mesh link (802.11ax MRs)

Known issues

• Wired clients connected to MR30H LAN ports are unable to pass unicast traffic (MR30H)
• Some client roaming scenarios may result in periods of inaccurate data in the client connectivity bar and client history
• Downstream VOIP RTP Packet Loss (MR42/MR42E/MR52/MR53/MR53E/MR84)
• Sporadic packet loss & instability on Layer 3 roaming & Teleworker VPN SSID's
• Reduced aggregate upload throughput on 2.4 & 5GHz radio for Windows clients (MR45/MR55)

[PawelG]

Installed for test on small MR45 network.

Can confirm that problem with not reporting latency on MR45 is solved.

To be confirmed if thy solved the problem with hanging MR45 scanning radio (resulting in not shown Meraki peers in RF Spectrum and showing only foreigns on AP working channel)

Unfortunately the problem with Failed PSK / 802.1x authentications it stil there. 

Br, Pawel.

[NolanHerring]

Well, I'm in ZERO rush to upgrade to 27.1 😃 Someone else can storm that beach.

That being said, the Client and AP Performance Tabs are a nice update, as well as the iPSK without Radius

[CptnCrnch]

Storming that beach right now 😉

Thanks for the heads up!

P.S.: What a pity:

“Note: Currently, the NBAR integration on MR access points is not supported in Combined networks, nor is it supported in wireless-only networks using a mix of NBAR-compatible and non-NBAR-compatible MR devices. Additionally, networks bound to templates of any network type are not supported at the moment.“ 😕

[NolanHerring]

lol

I'm testing it on my lab setup cause i want to see the new features, but i'm still waiting for 26.8 to become the new stable code. I really don't know how 26.6.1 is still there, seen too many forum posts having issues with that thing. I'll wait until 27.6+ comes out before i start pushing production to it =P

[Roger_Beurskens]

I'm going to update to 27.1 at my home "lab" tonight fingers crossed tomorrow because a 100% uptime is expected at home 😉

Using 3 MR33 and 1 MR32 ap's I expect the mr32 to be unavailable after the upgrade.

Time for a mr46 upgrade in the living room so AX testing can also be done 😄

[NolanHerring]

Your MR32 won't stop working (or shouldn't), it will just stay on the firmware version it has already (pre-27.x)

[Roger_Beurskens]

Ok, but mixing firmware inside the same network doesn't work? or does it?

[NolanHerring]

It does, however it's probably not a good idea as far as best practices goes. But I've upgraded single AP's before to test things (bug issues etc.) before pushing out to the rest (via supports assistance). Usually this is within the same firmware train, so going from 26 to 27 is a big jump possibly, so i would avoid it personally (in a production environment that is), but I think you'll be fine at home =P

[Roger_Beurskens]

Don't expect real problems than.
The 3 mr33's are inside the house..
The mr32 is in the seperate garage..

Only possible roaming issues in the garden it is than 😉

[cmr]

I liked the look of the new features, especially NBAR.  However, being able to enable it only if all APs are 802.11ax and if the network is wireless only (not combined) is %$^%&"£*(

I upgraded my home MR55 and four work sites where all APs are 802.11ac wave2 or newer but won't be able to see the feature as all are combined networks.  The only wirelsss only networks I have have some older APs in them 👿

[thomasthomsen]

"Wired clients connected to MR30H LAN ports are unable to pass unicast traffic (MR30H)" <- This is pretty bad (and yes, it is there, just verified on two different MR30H). Personally I think its pretty bad to release a software with a bug so serious for an AP where that feature is pretty much its reason for existence.

Does anyone on the inside have any info on this bug ?

How far along are they to fix it ? Because support is no help on this at all.

Not that the previous version was much better.

Strange stuff was going on there.

https://youtu.be/vsCv0dKRC88

[CptnCrnch]

Two things I noted after upgrading:

• WPA3 is not showing up on my iPSK enabled SSID
• iPSK without RADIUS could be really nice, but there‘s one thing completely missing (from my point of view): something like a „catch all“ PSK. Using FreeRADIUS, you could have a PSK for every device not having a special treatment. Especially regarding the 50 PSK limit per SSID, this seems like an even better idea. Perhaps I‘m blind but I haven‘t found something like this (yet?)).

[NolanHerring]

I would imagine the 'catch-all' could just be the first iPSK you create? Use that as the 'primary' and then any others you create after that are for the unique per-device/device-type setups etc.

[CptnCrnch]

@NolanHerring: makes sense. Seems like I was stuck with my current setup where I have a „specific MAC to PSK“-binding. If you take out the MAC address out of that equation, it‘s getting logical. Thanks for the heads up!

@thomasthomsen: Oh shoot, yes. You reminded me about that discussion in an ISE call. Kudos to you too!

[thomasthomsen]

WPA3 and iPSK does not "mix". I think they are trying for a solution (at least on the Cisco Classic side with ISE), but because of the way you do the new authentication it might not be possible (as far as I remember).

Thats properly why there is no WPA3 option there (yet, hopefully).

[Roger_Beurskens]

intersting, forced the update ( with low client impact) and see the MR32.....

[cmr]

@Roger_Beurskens Does the MR32 show 27.1 on its own page as it somewhat confusingly shows an MR32 with 27.1 and that isn't supposed to happen...

[NolanHerring]

I think it just shows whatever that network is set to use, but its not actually using that version. I agree, confusing and I wish they would allow each AP to actually show the version the AP is running. Feels to me like the firmware version indicator was poorly implemented to only ever show what version the network is actually set to, which seems lazy.

[Roger_Beurskens]

@cmr It also shows 27.1 on it's own page.

[nscheffer]

Hi all,

Deployed for 5x MR52 and 1x MR84 with a successful WPA3 Personal test.

Why we cannot combine "Identity PSK without Radius" with WPA3 Personal ?

It makes sense to have the following :

- a single SSID with WPA3 in transition mode allowing WPA2 with PFM enabled

- by default devices are set to a guest vlan using Identity PSK without Radius with default password

- a different password for Identity PSK will apply another policy with a different Vlan for other users

- etc...

This currently what I am doing without WPA3 and Identity PSK where default setting map the user to a guest vlan and manually I apply a different group policy to map the user into another vlan...

[PawelG]

Small update about MR45 bug that causes scanning radio to become unoperational after some period of operation time. 

With this release problem become more severe for 5GHz band - the scanning radio stops operating few hours after reboot while the 2,4Ghz still being operable.

This bug causes AP not being able to show Meraki neighbours in local status page, broadcast neighbor information to clients and scan other AP on channels different than current operational channel.

Br, Pawel. 

[JohnD]

I’m actually seeing the same scanning radio behavior on MR56 — after a day or so of uptime all 5GHz neighbors disappear from the list. 

[PawelG]

Yep, I think its common problem on MR45/55/46/56 platforms.

Br, Pawel. 

[antonis_sp]

Testing it on my home lab for now...

At least false authentication errors "Client entered wrong password." seem to have been resolved.

[Roger_Beurskens]

Looks like the same over here.

[NolanHerring]

@antonis_sp  - is that a known problem with 26.X train? or is that specific to MR45/55

I'm seeing that quite a few times on a PSK SSID I have and the PSK on the client machines are accurate so its like...what gives lol.

[PawelG]

In my network the 27.1 did not solve the "bad password" problem. I'm still getting those on PSK network but also on 802.1x one as "authentication errors". (The same on 26.6.1, 26.7)

I've been with TAC on it for a long time without any clear solution.  They say those are not real authentication errors but rather interpretation of events by wireless health module.

Br, Pawel. 

[NolanHerring]

So does that mean its false positives? And to ignore them? And that the authentication failure showing 10% isn't actually 10% and its much much lower type of thing?

[PawelG]

That is what TAC says, but I'm not convinced. 

In my case those errors happen when clients roam (not on every single roam) - and when they happen I can see clients roaming much slower or with trouble. TAC says that the authentication errors is a outcome of bad roam not the cause.

I can see it only on iOS clients.

Br, Pawel. 

[antonis_sp]

 @NolanHerring I’ve seen it a lot on PSK SSIDs on MR33. Can’t remember since when, but after wireless health was released, I was trying to investigate the Authentication errors. 

Issue was seen on a lot of clients, even those who never changed their psk password. Obviously false positives, giving misinformation in the reports. 

@PawelG i don’t thing it is roaming. I’ve seen it on single AP networks with static clients. 

[PawelG]

@antonis_sp - yep, it might be disassociation/association process not roaming. 

In my case - sometimes devices really pop-up a window saying that the password is wrong (PSK and 802.1x). Entering the old one always work... so I don't think that all of them are false-positives or it is just more complicated scenario.

Br, Paw.

[GIdenJoe]

About the graphs:
They look great.  I do see spikes of latency up to 1000ms for silent clients.  So I believe latency is counted for sleeping clients that sporadically wake up to receive and send packets.

About the false positives:
Yes you have alot of 'incomplete roams' where you can see low SNR and an unsuccesful authentication.  Maybe they should just add a new kind of category for incomplete roams and have them optionally filtered out so it does not look so bad for a data oriented wireless network.  The system should detect the client immediately probes and associates to another AP.

They are going in the right direction and I'm hoping they'll reach anything close to the detail DNA Center offers.
There for example you have the timeline but not with errors but all the events.  So roaming (re-assoc), auth and 4way or less handshake and the total ms it took to do the actual roam together with the airtime, SNR, retransmit stats.

[bigben386]

So I assume this means there will be no way to have a single template with pre and post wave2 APs if we want to keep them on the latest 26.x and 27.x firmwares?

[Roger_Beurskens]

I expect you have to leave them in an other network..

AP's in the same network run the same firmware.

With some testing at my home lab, 3 MR33's AND my mr32 are on 27.1

Enabling iPSK on my primary SSID makes my MR32 unusable.

It does transmit the SSID but no authentication is possible.

[bigben386]

Networks aren't really my issue. Surprisingly I only have 1 network that has a mix of pre and post wave2 APs. I have a mix of pre and post wave2 branch networks which I just recently consolidated into a single combined template though. There seems to be no way to set different firmwares for templated networks. Not sure if Meraki will add a per network firmware override option for templated networks. It is a bit annoying as some of these devices still have 4+ years of support left.

[pjc]

So now that any Wave1 (MR32 etc) are firmware locked to v26.99 or below, how do Meraki plan to rollout updates, security fixes or new features to these ?  They (MR32) still have until July 2014 until end of support

The MR32 was still on sale just over 3 years ago, are Meraki saying that's it, 3 years development from end of sale, go buy some new AP's if you want new development for your networks ?

How can I apply new features to my networks that have a mix both Wave1 and Wave2 AP's ?

If I roll out new firmware that includes new features, how will I know in advance if those features will work on older models ?

Do Meraki plan to swap out the older Wave1 AP's free of charge for new Wave2 ones?

[cmr]

@pjc26.x will continue to get security and functional fixes, just not new major features.  Hence the support up to 26.99 when we are only on 26.8.1 at the moment.  I think that if you configure a network that has a mix of devices with 27.x then the newer devices will get 27.x and the older ones will get the latest 26.x.  Obviously you cannot use new functional features that rely on 27.x.

We have been doing a bit of rationalising and have been replacing the 802.11ac Wave 1 APs at sites with only a few with Wave 2 APs from sites where most are Wave 1, thereby allowing us to use the new features in the now all Wave 2 sites if required.