Added ability to disable 802.11r r0 key timeout given some client incompatibilities with the default 3600 second timeout. Please contact support. (802.11n/ac/ac Wave 2 MRs)
General
Numerous stability patches implemented for MR26, MR32, MR34, MR72
Numerous single & multi-client performance improvements implemented for 802.11ac Wave 2 MRs
Stability improvements for MR45, MR55
Bug fixes
Unexpected beacon behavior after channel changes with 11ax mode disabled (MR45/MR55)
Mesh stability fixes (MR18 / 802.11ac Wave 2 MRs)
Upon losing default gateway connectivity, and regaining connectivity, the MR would not broadcast it’s SSIDs as expected (802.11ac Wave 2 MRs)
The MR26 (2.4 / 5 GHz radio) & MR34 (2.4 GHz radio) would broadcast corrupted beacons when minimum bitrates differ across SSIDs. This has been addressed by ensuring that all client SSIDs (as well as the mesh SSID) for these radios are configured to use the same minimum bitrate by selecting the lowest common denominator across the enabled client SSIDs. (MR26/MR34)
Potentially exhaust memory of MR30H when sending traffic at high rates between two wired LAN clients connected to the same MR (MR30H)
MR still broadcasts mesh beacons when meshing is disabled (802.11ac Wave 2 MRs)
Mesh beacons sent at maximum transmit power if 2.4 GHz radio disabled (MR45/MR55)
Gateway IP was being spoofed by certain types of clients resulting in incorrect gateway IP information being propagated to other clients (All MRs)
Invalid Implicit Beamforming operations from certain clients leading to MR reboot (802.11ac Wave 2 MRs)
Meraki Proxy ARP interoperability issue with radio vendor implementation leading to MR reboot (802.11ac Wave 2 MRs)
Fragmented packets dropped by gateway MRs when destined to clients behind a wired mesh repeater (All MRs)
Clients unable to pass traffic on Open SSIDs (MR26/MR32/MR34/MR72)
TPC report element missing from beacons & probe responses (MR45 / MR55)
Prevent gateway MRs from forwarding BPDUs received from wireless clients (All MRs)
Disable 802.11k Client Beacon Measurement due to client interoperability issues (802.11ac Wave 2 / 802.11ax MRs)
Inconsistent formatting of User-Name and Calling-Station-ID attributes when using MAC-Authentication with Cisco Identity Services Engine (ISE) Authentication Splash (All MRs)
Clients able to associate & send traffic prior to MR receiving Access-Accept from RADIUS server when using MAC-Authentication (All MRs)
Some MRs were unable to download configuration due to required internal parameters not being properly stored in flash memory (802.11n/ac/ac Wave 2 MRs)
Control frames sent at OFDM rates to non-OFDM clients (802.11ac Wave 2 MRs)
Power Constraint IE missing from beacon/probe response frames for non-DFS channels (802.11ac Wave 2 MRs)
Windows clients unable to reauthenticate after Change-of-Authorization (All MRs)
Group policy not applying to clients immediately after MR boot (802.11n/ac/ac Wave 2 MRs)
Known issues
Downstream VOIP RTP Packet Loss (MR42/MR42E/MR52/MR53/MR53E/MR84)
Issue under investigation where DHCP intermittently fails for bridge mode SSIDs (MR32)
Sporadic packet loss & instability on Layer 3 roaming & Teleworker VPN SSID’s
Reduced aggregate upload throughput on 2.4GHz radio for Windows clients (MR45/MR55)
When upgrading from MR25.x firmware to MR26.x firmware, mesh repeater MRs may be slow to upgrade (802.11ac Wave 2 MRs)
Stable release. I was asked to upgrade the MRs to build 26, but my MRs say that they are up-to-date. That build is 25.13. Is the 26 build a Beta release?
@WarrenForNOLA Yes Build 26 is a Beta release. Meraki beta releases are usually very good though plus the beauty with Meraki is you can rollback the firmware if you run into problems.
MR52 are having issues with 25.X code. I have a site with them and running 26.X code on them because of it, and seems to be working well. That might be why you were prompted to do so.
Added ability to disable 802.11r r0 key timeout given some client incompatibilities with the default 3600 second timeout. Please contact support. (802.11n/ac/ac Wave 2 MRs)
General
Numerous stability patches implemented for MR26, MR32, MR34, MR72
Numerous single & multi-client performance improvements implemented for 802.11ac Wave 2 MRs
Stability improvements for MR45, MR55
Bug fixes
Unexpected beacon behavior after channel changes with 11ax mode disabled (MR45/MR55)
Mesh stability fixes (MR18 / 802.11ac Wave 2 MRs)
Upon losing default gateway connectivity, and regaining connectivity, the MR would not broadcast it’s SSIDs as expected (802.11ac Wave 2 MRs)
The MR26 (2.4 / 5 GHz radio) & MR34 (2.4 GHz radio) would broadcast corrupted beacons when minimum bitrates differ across SSIDs. This has been addressed by ensuring that all client SSIDs (as well as the mesh SSID) for these radios are configured to use the same minimum bitrate by selecting the lowest common denominator across the enabled client SSIDs. (MR26/MR34)
Potentially exhaust memory of MR30H when sending traffic at high rates between two wired LAN clients connected to the same MR (MR30H)
MR still broadcasts mesh beacons when meshing is disabled (802.11ac Wave 2 MRs)
Mesh beacons sent at maximum transmit power if 2.4 GHz radio disabled (MR45/MR55)
Gateway IP was being spoofed by certain types of clients resulting in incorrect gateway IP information being propagated to other clients (All MRs)
Invalid Implicit Beamforming operations from certain clients leading to MR reboot (802.11ac Wave 2 MRs)
Meraki Proxy ARP interoperability issue with radio vendor implementation leading to MR reboot (802.11ac Wave 2 MRs)
Fragmented packets dropped by gateway MRs when destined to clients behind a wired mesh repeater (All MRs)
Clients unable to pass traffic on Open SSIDs (MR26/MR32/MR34/MR72)
TPC report element missing from beacons & probe responses (MR45 / MR55)
Prevent gateway MRs from forwarding BPDUs received from wireless clients (All MRs)
Disable 802.11k Client Beacon Measurement due to client interoperability issues (802.11ac Wave 2 / 802.11ax MRs)
Inconsistent formatting of User-Name and Calling-Station-ID attributes when using MAC-Authentication with Cisco Identity Services Engine (ISE) Authentication Splash (All MRs)
Clients able to associate & send traffic prior to MR receiving Access-Accept from RADIUS server when using MAC-Authentication (All MRs)
Some MRs were unable to download configuration due to required internal parameters not being properly stored in flash memory (802.11n/ac/ac Wave 2 MRs)
Control frames sent at OFDM rates to non-OFDM clients (802.11ac Wave 2 MRs)
Power Constraint IE missing from beacon/probe response frames for non-DFS channels (802.11ac Wave 2 MRs)
Windows clients unable to reauthenticate after Change-of-Authorization (All MRs)
Group policy not applying to clients immediately after MR boot (802.11n/ac/ac Wave 2 MRs)
Known issues
Downstream VOIP RTP Packet Loss (MR42/MR42E/MR52/MR53/MR53E/MR84)
Issue under investigation where DHCP intermittently fails for bridge mode SSIDs (MR32)
Sporadic packet loss & instability on Layer 3 roaming & Teleworker VPN SSID’s
Reduced aggregate upload throughput on 2.4GHz radio for Windows clients (MR45/MR55)
When upgrading from MR25.x firmware to MR26.x firmware, mesh repeater MRs may be slow to upgrade (802.11ac Wave 2 MRs)
@NolanHerring - Do you have any 2.4ghz devices running on the MR52s? I had run into an issue with 26.3 and devices like wireless printers dropping and not reconnecting. No issues like that with my MR34s.
At this specific location that has the MR52's, its in a downtown area of a busy city. 2.4GHz is basically un-usable because of all the neighboring networks, so my SSID's are 5GHz only.