MR 25.11 Latest Stable

[MerakiDave]

Hi Crew, just a quick heads up that MR 25.11 was promoted from SRC to the latest stable firmware.

Change log notes: 

New

• HSRP support for Bridge Mode Layer 2 client isolation

Bug fixes

• AP spoofs not being detected. (MR52/72)
• A corner case where AP broadcast on W52 channel when in site survey mode (MR84)
• A corner case where AP would stop broadcasting SSID (MR30H/33/42/53/53/74/84)
• A corner case causes AP to reboot (MR18)
• A corner case causes AP to stop responding to clients (MR32)
• A corner case causes APs lose connectivity to dashboard until reboot in certain cases (MR33/74)

Known issues

• Condition under investigation that causes VoIP RTP packet loss (MR42/MR52/MR53)
• Condition under investigation causes 2.4GHz radios to become unresponsive (MR32/MR72)
• Condition under investigation causes radios to become unresponsive for 5 seconds in high density networks (MR34/MR32/MR72/MR26)
• Condition under investigation causes lower than expected throughput on the 2.4GHz radio (MR26/MR34)

Other

• General performance and stability improvements.

[PhilipDAth]

What exactly is this HSRP support?

[MRCUR]

@PhilipDAth There is a new "25.11" section here: https://documentation.meraki.com/MR/Firewall_and_Traffic_Shaping/Wireless_Client_Isolation

[Adam]

Thanks, this helps me keep up on the updates. 

[dmo]

Hi MerakiDave

   Since the update (25.11) I'm experiencing frequent channel changes with both 2.4 and 5 on models MR 42 and MR66.  Any help on this as clients are dropped for about 45 to 60 seconds when this happens.

Thanks for your help

David

[MRCUR]

@dmo What does Wireless Health show? Have you made any recent config changes? 

I'd recommend starting a new thread instead of adding to this one. 

[dmo]

Thanks for responding.  Started a new thread;

MR42 Frequent Channel changes with Firmware MR 25.11

Appreciated the help!

[Asavoy]

• Condition under investigation causes lower than expected throughput on the 2.4GHz radio (MR26/MR34)

That's almost the understatement of the year!

Please note that this ALSO applies to the 5Ghz radio on the MR34.

The PR-speak "lower than expected" should be updated to reflect reality- "almost unusable" is more approriate.

[NetAdmin]

This is a big issue. May have to roll our entire school district back to 23. Causing lots of issues with state testing. Please come up with a fix soon.

[Asavoy]

@NetAdmin

I've been helping them test a beta firmware for the 2.4Ghz bandwidth issue (3Mb/s... really) and can confirm that they have fixed that issue in that firmware.

However, they broke the Staff SSID (password protected, relays to a Windows DHCP) where an access point will randomly not allow a client to get a valid IP address.  They can switch the the Public SSID (open, Meraki DHCP) and function except for critical internal network functions.  They can go to another room and connect fine on the Staff SSID.  The only cure is a reboot of the affected AP.  There is no rhyme or reason. 

I think they were able to gather enough info due to my troubleshooting efforts.  It wasn't until last Thursday that I was able to get them on the phone while it happened after school hours here.  Hopefully this issue gets fixed very soon.  So far this week I've been proactively rebooting every AP first thing in the morning and it seems to have helped.  It's a PITA to reboot 50 WAPs though!

[NetAdmin]

If the reboots can get us to the next release I am willing to give it a try. But as you said rebooting all those APs is a PITA

[Asavoy]

You'll may have to contact support as I am not sure it's in the Beta channel yet. I can tell you that this seems to be the only issue I've seen with performance, so far. This is at a site that ONLY has MR34 devices.

(FWIW- I tested MR42 and MR52 throughput at same site and the MR42 was the fastest on 2.4Ghz band. Go figure)

[mmmmmmark]

---

@Asavoy wrote:

So far this week I've been proactively rebooting every AP first thing in the morning and it seems to have helped.  It's a PITA to reboot 50 WAPs though!

---

Here's a thread on some ideas to reboot WAPs: https://community.meraki.com/t5/Solutions-APIs/API-Call-to-Reboot-AP/td-p/5863