MR Firmware 26.2 Available

[NolanHerring]

New

• Initial stable firmware for MR45/MR55
• Improved efficiency & reliability of Auto Channel CSA process
• RADIUS Proxy support for client 802.1x authentication on MR LAN ports (MR30H/MR52/MR53/MR84)

Bug fixes

• Additional clients unable to associate to APs with 40+ active clients (MR26/MR32/MR34MR72)
• Clients unable to EAP reauthenticate after EAP session timeout (MR26/MR32/MR34/MR72)
• RADIUS authentication would not failover to secondary RADIUS server when used in conjunction with VPN Teleworker or Layer 3 Roaming with Concentrator (All MRs)
• AP not failing over to secondary RADIUS server quickly enough to prevent some clients from disassociating and restarting failover timer (All MRs)
• Corner case where AP would not properly load radios upon boot (MR26/MR32/MR34/MR72)
• Prevent BPDU frames from being sent over VPN tunnels in Teleworker VPN configurations (All MRs)
• Comma delimiter in RADIUS accounting fields caused unexpected behavior with Windows Network Policy Servers; replaced with forward slash (All MRs)
• Local Status Page showing incorrect values for client max bitrate (All MRs)
• Corner case where beacon interval may become misconfigured for 200ms instead of 100ms (MR42/MR42E/MR52/MR53/MR53E/MR84)
• Corner case causing APs to reboot (MR42/MR42E/MR52/MR53/MR53E/MR84)
• Client isolation used in conjunction with upstream HSRP configuration resulted in client being unable to ARP for their default gateway (All MRs)

Known issues

• Issue under investigation where DHCP intermittently fails for bridge mode SSIDs (MR32)
• Mesh instability (MR18, MR20, MR33, MR34, MR42, MR52, MR53, MR53E, MR70, MR74, MR84)
• Sporadic packet loss & instability on Layer 3 roaming & Teleworker VPN SSID’s (All MR’s)

Other

• New Features
• Bug Fixes
• Known Issues

[BrechtSchamp]

New APs coming! Anyone seen details on them yet?

[PhilipDAth]

You'll probably enjoy April the 29th.

[BrechtSchamp]

Aha I see. Pinned in the calendar!

[Roska]

Got a partner update in this week for EMEA. Good stuff.

[rhbirkelund]

My local Meraki man: https://www.instagram.com/p/BvAKe_tBOxzAiGpfY7FzKvmxgC/ 😉

[NolanHerring]

Will be neat to see how things perform on this version of code.

[BrechtSchamp]

I guess the news is out then :P. I thought it was supposed to be a secret until April 29th...

[pjc]

Any news on when this v26.2 goes to Stable Release Candidate or Stable status ?  It's been in beta for 3 months, I would of thought by now there would be enough confidence to move it along to at least SRC

Thanks

[randhall]

We encountered the MR32 DHCP issue that's known in 26.2 when we tried it last week. It was very debilitating. Given the number of MR32s in the field I might expect it to never make it to RC.

[NolanHerring]

---

@randhall wrote:

We encountered the MR32 DHCP issue that's known in 26.2 when we tried it last week. It was very debilitating. Given the number of MR32s in the field I might expect it to never make it to RC.

---

Unless you have a very specific reason to go 26.X for any model, but especially older models like the MR32, I would stay on 25.13 as long as you can. I believe a 25.14 or later should be coming out in the near future as well.

[pjc]

I see that 26.3 was released yesterday, but still listed under investigation in the release notes:

"Issue under investigation where DHCP intermittently fails for bridge mode SSIDs (MR32)"

That's a show stopper for us, as over half our estate is MR32's. 

We'll hang back on 25.13 for now

[thomasthomsen]

Any news on these "MESH Instability" Issues ? - Right now my MR70 are acting like this : 

MR70

And to make things "worse" they just go "straight" to UNII-1 channels - Im located in Denmark, where we are actually allowed to use UNII-1 outside, but in general ETSI devices are not (as far as I know).

Just wondering 🙂

[NolanHerring]

The MESHING and DFS are two different things.

I am hoping they fix the MESHING stability issues when 26.3 comes out, since I know they are fully aware of it.

In the interim, I would re-enable MESHING (if you have it disabled), until they fix it. What you want is stability, and re-enabling it will give you that at the cost (very minor cost) of some overhead of beacon frames being sent at lowest data rate/max power.

I'm not aware of any DFS issues though, so that is new to me.

[thomasthomsen]

Bascially all our outdoor MR70s and MR72 have this DFS problem. They just detect radar on all channels. And on the outdoor APs is the only place we run MESH networks, they should "MESH" on 5Ghz .. and when the AP detects radar on channel 100 to 140 .... thats a problem. And this is in the ETSI domain where we cannot set non-dfs channels for outdoor APs (even though its allowed here in Denmark).

For fun, I just booted up a MR70 here inside next to me in a building that have around 20-30 MR32 and MR33s, around 30 secs after it completed the boot, the first DFS event was detected and it changed channel. All the other APs in the building have maybe had 1 or 2 events for the whole day (and they are running on dfs required channels).