MR 30.6 out and Being Pushed, lots of fixes

[Mloraditch]

It's still replicating on Shards but I just got a bunch of push notices, I'm going to guess the SSL update mentioned is a result of a CVE or similar and part of the reason for the rapid push.

Important note

• While Meraki APs have traditionally relied on UDP port 7351 for cloud communication, and TCP ports 80 and 443 for backup communications, with MR 28+ we are beginning the transition to using TCP port 443 as the primary means for cloud connectivity. In order to ensure proper connectivity to the Meraki cloud after this upgrade, please ensure that all “Meraki cloud communication” traffic specified in the "Help" > "Firewall Info" page is allowed through any firewalls or security devices that are deployed upstream of your Meraki APs. These requirements have been updated in November of 2022, so it is important that you review them. (Wi-Fi 6 and Wi-Fi 6E APs)
• WEP deprecation (https://documentation.meraki.com/MR/Encryption_and_Authentication/WEP_Deprecation_on_MRs)

Legacy product notice

• When configured for this version, MR12, MR16, MR18, MR24, MR26, MR32, MR34, MR62, MR66, and MR72 will run MR 26.8.3

Bug fixes

• General stability and performance improvements
• AP not returning to original channel after a DFS channel change event (MR45/55)
• Clients failing to get IPv6 address with high bcast/mcast traffic (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)
• Acct-Output-Gigawords in the accounting packets not increasing when they should (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)
• Multiple DHCP servers detected when clients use DHCP relay (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)
• Large mDNS packets can cause loss of wired connectivity (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)
• MA-INJ-6 provides 802.3at power, not 802.3bt when connected to switches that provide PoE, but are not MS390 (Wi-Fi 6E APs)
• User-Name and Calling-Station-Id in different format consuming additional license on ISE (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)
• Air Marshal syslog messages sent without detailed information (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)
• Fix channel width support for El Salvador (Wi-Fi 5 Wave 2 APs)
• Fix 6 GHz regulatory issue with Saint Martin (MF) (Wi-Fi 6E APs)
• UNII-3 channels not available in France (CW9166I-MR)
• Incorrect Country Code in 6 GHz Beacon/Probe Rsp in some EU countries (Wi-Fi 6E APs)
• Characters with diacritics truncated from SSID names in RADIUS accounting/access request packets (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)
• 'tcpdump' filters not working on wired interface when Adaptive Policy is enabled (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)
• UDN ID not properly assigned to clients for "iPSK w/ RADIUS" configuration (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)
• Incorrect IPSK-EAPOL VSA data for Easy PSK (Wi-Fi 5 Wave 2 APs)
• Exclude Beidu/GLONASS constellations from GNSS receiver when used for AFC location (Wi-Fi 6E APs)
• 6 GHz radio not turned off when AFC expires (CW9163E-MR)
• APs utilizing WPA3 are shown as "Open" in RF Spectrum > Interfering APs UI (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)
• Clients using 160 MHz channels reporting 20 MHz channel width use (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)
• Clients getting dropped before DHCP lease time expiry during L3 roam and disconnected for more than 30 sec (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)
• WiFi 6/6E failed to change channel
• High VoIP jitter during longevity tests

Enhancement

• Add 6 GHz support for regulatory domains with new 6 GHz approvals (Wi-Fi 6E APs)
• Keep 6 GHz radio off for outdoor APs when no configuration provided (CW9163E-MR)
• Upgrade CiscoSSL from 7.3 to 7.3a

Known issues

• Sporadic packet loss & instability on Layer 3 roaming & Teleworker VPN SSID's (Wi-Fi 5 Wave 2 and Wi-Fi 6 APs)
• In high capacity wireless networks, APs may experience instability when the “Client Balancing” feature is enabled (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)

[RaphaelL]

Faster than the firmwareBot 😉

Lotssss of fixes ! Interesting !

[cmr]

Definitely looking forward to the one where the radio wouldn't change channel being fixed, that's been a right pain!

[BHC_RESORTS]

---

Known issues

• Sporadic packet loss & instability on Layer 3 roaming & Teleworker VPN SSID's (Wi-Fi 5 Wave 2 and Wi-Fi 6 APs)

This has been a thorn in our side for quite some time now. I'd really like to see it fixed as it is a feature we used heavily on the MR30H, which despite being Wave 2 we never encountered this problem. Once we upgraded to the 36H, this has been super annoying.

[Paccers]

"WiFi 6/6E failed to change channel" would be nice if that was expanded a tad. Is this saying all Wi-Fi 6 and 6E APs are failing to change channels?

[Macguy]

Anyone try this firmware out yet? 

[cmr]

I'm running it on a network with CW9166 and CW9163 APs, it does work, but I had to reboot the CW9166 after the upgrade to get some of the SSIDs to accept connections.

Since then it has been stable.

It was an upgrade from 30.5.1

[cmr]

Another site with MR36s doesn't appear to have had any issues with the upgrade, also upgraded from 30.5.1

[cmr]

I actually had to reboot the CW9163 as well to get an IoT device properly connecting again...  Not good and not something that I have seen before with a Meraki firmware update.

[cmr]

I've had to roll back the site with the CW916x APs to 30.5.1, 30.6 breaks BG home IoT switches, they don't last more than about 12 hours...

[BHC_RESORTS]

Under Wireless > AP Neighbors, all of our APs show channel (0). Not very helpful. This is on all three bands.

[RaphaelL]

This bug was already present with 30.5. I don't know when it was introduced.

[BHC_RESORTS]

Interesting, hadn't noticed it before. We've had the issue where the auto channel refuses to update properly, APs adjacent to each other would get stuck on the same channel (specifically on 2.4) and was hoping to easily see if this fixed it.

[Paccers]

Has anyone else had Meraki try and schedule an upgrade to your Networks even though it's still RC!?

[cmr]

@Paccers, yes all of our networks were scheduled and have now been upgraded.  The only APs I've had any issues with are CW916x ones on one site.  I'm hoping to check them on a second site today, but they appear to be okay there when looking at the connected clients list.

[Paccers]

Not a huge fan of having an RC force pushed ahead of latest Stable myself, regardless of the documentation saying RC is 'Stable but not widely adopted yet', it'd be nice to be able to opt-out of that like you can with Beta's.

[Macguy]

Updated one of my elementary schools to 30.6 last night (mix of MR42 and MR56).  Using an Mac M2 Pro laptop.  I'm there twice a week so I'm familiar with expected wireless behavior.  I've had flakiness in the past with my Mac and random roaming.  Things were pretty stable with 30.5.  This morning my Mac had some weird roaming issues along with associations at 2.4Ghz which hasn't ever happened before.  Band steering and client balancing disabled.  Using 1x for authentication.  I'll be back Friday AM and test more, may roll back to 30.5. 

[Sonkist]

Can someone confirm if this fixes the issue with RADIUS Accounting having the mac-address as the username with 802.11r enabled on Apple devices?

[RaphaelL]

The changlog is way different from what the dashboard is recently displaying... I don't like that

[cmr]

Indeed, I think we might be experiencing the added known issue of:

• DNS test failure results in no connectivity (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)

We have a CW9166I and an MR44 that keep showing no connectivity, but remain serving clients without issue at one of the sites running 30.6.  The other site has now stabilised with it completely.

[Paccers]

24 listed bug fixes now down to 11 and 1 new known issue, definitely feels like this should have stayed in Beta territory for a while!

[cmr]

It is now listed as the stable release with the below fixes and issues:

Wireless firmware versions MR 30.6 changelog

Important note

• WEP deprecation (https://documentation.meraki.com/MR/Encryption_and_Authentication/WEP_Deprecation_on_MRs)

Bug fixes

• General stability and performance improvements
• AP not returning to original channel after a DFS channel change event occurred (MR45/55)
• Large mDNS packets can cause loss of wired connectivity (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)
• User-Name and Calling-Station-Id in different format consuming additional license on ISE (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)
• UDN ID not properly assigned to clients for "iPSK w/ RADIUS" configuration (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)
• Incorrect IPSK-EAPOL VSA data for Easy PSK (Wi-Fi 5 Wave 2 APs)
• Exclude Beidu/GLONASS constellations from GNSS receiver when used for AFC location (Wi-Fi 6E APs)
• 6 GHz radio not turned off when AFC expires (CW9163E-MR)
• APs utilizing WPA3 are shown as "Open" in RF Spectrum > Interfering APs UI (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)
• Clients getting dropped before DHCP lease time expiry during L3 roam and disconnected for more than 30 sec (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)
• AP failed to change channel (Wi-Fi 6 and Wi-Fi 6E APs)

Enhancement

• Add 6 GHz support for regulatory domains with new 6 GHz approvals (Wi-Fi 6E APs)
• Keep 6 GHz radio off for outdoor APs when no configuration provided (CW9163E-MR)
• Upgrade CiscoSSL from 7.3 to 7.3a

Known issues

• Sporadic packet loss & instability on Layer 3 roaming & Teleworker VPN SSID's (Wi-Fi 5 Wave 2 and Wi-Fi 6 APs)
• In high capacity wireless networks, APs may experience instability when the “Client Balancing” feature is enabled (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)
• DNS test failure results in no connectivity (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)

[cmr]

The below fixes are no longer listed as fixed:

• Clients failing to get IPv6 address with high bcast/mcast traffic (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)
• Acct-Output-Gigawords in the accounting packets not increasing when they should (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)
• Multiple DHCP servers detected when clients use DHCP relay (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)
• MA-INJ-6 provides 802.3at power, not 802.3bt when connected to switches that provide PoE, but are not MS390 (Wi-Fi 6E APs)
• Air Marshal syslog messages sent without detailed information (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)
• Fix channel width support for El Salvador (Wi-Fi 5 Wave 2 APs)
• Fix 6 GHz regulatory issue with Saint Martin (MF) (Wi-Fi 6E APs)
• UNII-3 channels not available in France (CW9166I-MR)
• Incorrect Country Code in 6 GHz Beacon/Probe Rsp in some EU countries (Wi-Fi 6E APs)
• Characters with diacritics truncated from SSID names in RADIUS accounting/access request packets (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)
• 'tcpdump' filters not working on wired interface when Adaptive Policy is enabled (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)
• Clients using 160 MHz channels reporting 20 MHz channel width use (Wi-Fi 5 Wave 2, Wi-Fi 6 and Wi-Fi 6E APs)
• High VoIP jitter during longevity tests

[RaphaelL]

"new" known issue : 

AMI not sending RADIUS traffic

[RodCushman1]

We have a public WIFI with WEP/Splash screen (I know - was not MY choice).  At our main sites we need to keep WEP enabled with the existing Splash screen until we are able to lobby for WPA2 with a public sign.  WILL WEP STILL WORK ON 30.6, even though Meraki is deprecating it???  I'll need to know BEFORE I upgrade from 30.5 -> 30.6; and postponing my MR upgrades until I know.