MR 28 Private Beta Sign Up

[AlexanderN]

We are opening enrollment for MR 28 firmware private beta!

Please note that this is not a public MR 28.x beta but an early release program for a select number of customers prior to the public MR 28 beta release.

These are MR 28 features / bug fixes / known issues:

[New] IPv6 support on MR (including MR management over IPv6, IPv6 live tools, L3 IPv6 firewall rules, RADIUS/LDAP/AD over IPv6, SNMP/Syslog/Meraki Health over IPv6) (All MRs)

[New] RADIUS enhancements (e.g., NAS-ID configuration, Called-Station ID configuration, EAP timers, and more) (All MRs)

[New] Electronic Shelf Labels (ESL) support (with our partner SES-imagotag). This feature allows using the IoT (previously known as BLE) radio your MR access points to act as gateways for these tags as opposed to deploying separate ESL gateways (MR30/33/74, MR45/55, MR36/MR46/MR56, MR76/86).

[New] Support VLANs over wireless mesh links (All MRs)

[New] FIPS support on MR (Phase 1) (Wi-Fi 6 MRs)

[New] Meraki Health - Phase 3: Additional Meraki Health alerts and smart thresholds, visibility into client devices by leveraging Meraki full-stack (All MRs)

Note that some of the features (like ESL) are only supported on specific MR models and/or require additional backend configuration at this time.

[Bug Fixes] Downstream VOIP RTP Packet Loss (MR42/MR42E/MR52/MR53/MR53E/MR84)

[Bug Fixes] MR may reboot when configured with WPA2-Enterprise, Hotspot 2.0, and more than 42 MCC/MNCs. There is now a limit on 42 or fewer MCC/MNCs. (All MRs)

[Bug Fixes] TCP port 22 was accessible from the wireless LAN (All MRs)

[Bug Fixes] MR may reboot on certain configuration changes when NBAR is enabled (Wi-Fi 6 MRs)

[Bug Fixes] RADIUS Accounting Interim-Update packets contain 0 for Acct-Input / Acct-Output usage values (Wi-Fi 6 MRs)

[Bug Fixes] Wi-Fi 6 MR did not start RADIUS Accounting session after 802.11r FT (Wi-Fi 6 MRs)

[Bug Fixes] RADIUS CoA packets not sent across mesh links (All MRs)

[Bug Fixes] Enabled 40/80 MHz channel widths in Ecuador (MR20/MR30H/MR33/MR70/MR74)

[Bug Fixes] Local status page included “Provider Name” cellular information (All MRs)

[Bug Fixes] MR may transmit VHT frames on 2.4 GHz (MR20/MR30H/MR33/MR70/MR74)

[Bug Fixes] 802.11r association & re-association events were not generated in the event log (All MRs)

[Bug Fixes] LED did not change from green to blue when clients connected to MR (MR30H)

[Bug Fixes] SNMP ifInDiscards were being inaccurately reported (All MRs)

[Bug Fixes] Enabled RTS/CTS on 2.4 GHz (MR45/MR55)

[Bug Fixes] Class Attribute received from RADIUS Access-Accept packet was not forwarded in RADIUS Accounting-Request packet (All MRs)

[Bug Fixes] Client Balancing control plane packets continued to be transmitted by MRs via Ethernet even when disabled (All MRs)

[Bug Fixes] Channel utilization falsely reported spikes or sustained levels of utilization (Wi-Fi 5 MRs)

[Bug Fixes] Local status page included  latitude and longitude coordinates

[Bug Fixes] VPN teleworker tunnels were unable to establish if the SSID configured to do so was VAP #12 (out of 15) (All MRs)

[Known Issues] Wired clients connected to the MR30H LAN ports do not receive proper SGT

[Known Issues] Custom firewall rules are not enforced on SSIDs with applied Adaptive Policy Group

[Known Issues] Sporadic packet loss & instability on Layer 3 roaming & Teleworker VPN SSID's (All MRs)

We're looking for customers interested in working with the MR Product Management team to help make MR 28.x our best release to date. Reported issues and feedback will be directly fed to our engineering team who will be tackling these issues with top priority.

If you'd like to be a part of this group, please sign up here and we will be in touch.

Thanks!

[Greenberet]

Looking forward to it.

About the ESL support. Does that also mean, that the MT Sensors will be supported on MR33 with this firmware as they are also using the IOT radio?

How long will the closed beta be running? I will extend my network with Wi-Fi networks in a few months. So my network will be mixed then.

[MarcP]

---

@Greenberet wrote:

Looking forward to it.

About the ESL support. Does that also mean, that the MT Sensors will be supported on MR33 with this firmware as they are also using the IOT radio?

---

That would be great.

logged in to a network yesterday, where I got a message like, if I want to use MT sensors I need to update to FW 27.6 and there are MR33´s in.

In other networks with MR42/74 I did not get this message.

[AlexanderN]

But what's the problem here? MR33 supports 27.6 (while it does not support MT sensors, yes).

However, you can upgrade the network with MR33s to 27.6.

[cmr]

I'm looking forward to this bug fix that if I'm not mistaken we've been waiting a while for:

[Bug Fixes] Downstream VOIP RTP Packet Loss (MR42/MR42E/MR52/MR53/MR53E/MR84)

[AlexanderN]

Yes, it's exciting!

I mean, it's been rather a corner case that affected a very small number of APs, but still.

[Greenberet]

@AlexanderNthe problem here is that the MR33 doesn't support the MT sensors yet =D

[AlexanderN]

Yeah, MR 28 firmware cannot help with this particular thing. Sorry!

[AlexanderN]

Well, MT uses BLE as a communication protocol and ESL with SES is using a proprietary wireless protocol that operates in 2.4GHz but has nothing to do with 2.4GHz Wi-Fi or BLE. 

There is no connection here. I cannot comment whether or not that would be supported but feel free to ask MT folks 🙂

[burnz]

Would love to be Part of this beta

[AlexanderN]

We will absolutely add you!

[DHAnderson]

I was in the previous MR IPV6 beta (27.99).  I have since joined the MX beta and put the access point back in that network.  It reverted to 27.6.  

I would like to be in this beta so I can continue testing.

Thanks,

- Dave

[AlexanderN]

Absolutely!

[Greenberet]

Is there also a (private) beta for the MX with ipv6 support? I would love to test the ipv6 with the MR, but going passthrough on the MX on ipv6 is not a working way =(

[AlexanderN]

Let me DM you some details!

[LG]

I'd love to participate, just sent the form! thanks in advance!

[AlexanderN]

Sent the invite!

[PawelG]

Good news. I would be really happy to test this FW in my home lab - which currently is my "production" environment due to all pandemic curcumstances. Still nice place to test new things.

Br, Pawel. 

[AlexanderN]

Invite sent!

[Inderdeep]

I will try to check on my home environment. Send me the invite as well, Thanks 

[AlexanderN]

Sure! Please sign up here

[DHAnderson]

@AlexanderN 

How do I get the beta on my access points?

- Dave

[AlexanderN]

Hi Dave, since you already signed up we will be updating your network automatically. That should happen sometime next week. Keep an eye on the updates in our MR 28 Early Adopters Group. Thanks!

[redsector]

[New] Support VLANs over wireless mesh links (All MRs)

Waiting for this since years. 👍👍👍

[jamesw]

Hi Alexander

Might you be able to provide some more detail/documentation around this in particular:

[New] RADIUS enhancements (e.g., NAS-ID configuration, Called-Station ID configuration)

Thanks,

J

[AlexanderN]

Sure - https://documentation.meraki.com/MR/Access_Control/MR_Meraki_RADIUS_2.0

[AlexanderN · Accepted solution]

Thank you for your interest in the private MR 28 beta! 

MR 28.1 has been released yesterday and you can get on the Organization > Firmware upgrades page along with links to the relevant feature documentation. 

[jamesw]

Great - can you tell me, the new RADIUS options for Called-Station-Id and NAS-ID, what RADIUS requests do they affect?

Does it change all RADIUS traffic, even Captive portal RADIUS, or just 802.1x. Is MAC authentication also included?

At present, without setting any of the new options, captive portal RADIUS traffic uses the AP MAC address as the Called-Station-Id, but 802.1x and MAC authentication uses the BSSID MAC instead.

Thanks,

James

[Rodrigo_]

Hi James

Yes, the option should change the traffic for all authentications. 

The default behavior will not be modified unless you use the customizable attributes on radius advance page.

[jamesw]

Thanks Rodrigo

A couple of observations:

On our existing WPA2 enterprise SSID, after upgrading to MR28, it started using the new Called-Station-Id settings without me setting/changing anything on the Meraki dashboard. Also, when I created a new SSID and set it to MAC-based control only, and configured basic radius servers, it too automatically uses the new Called-Station-Id settings without me setting anything.

It seems the default setting for both Called-Station-Id and NAS-ID is "AP MAC address::SSID Name" / "AP MAC address::SSID Number" respectively - is this correct? (This is good for us, not complaining!)

Prior to MR28, when I connect to the SSID, it sent the following packet:

        User-Name = "112233445566"
        User-Password = ""
        NAS-IP-Address = 0.0.0.0
        Called-Station-Id = "0C-8D-DB-11-22-33:Free_WiFi"
        Calling-Station-Id = "99-88-77-66-55-44"
        NAS-Port-Type = Wireless-802.11
        Connect-Info = "CONNECT 11Mbps 802.11b"

and since MR28 we now see:

        User-Name = "112233445566"
        User-Password = ""
        NAS-IP-Address = 192.168.1.89
 ++     Service-Type = Call-Check
 >>     Called-Station-Id = "0C-8D-DB-11-22-33:Free_WiFi"
        Calling-Station-Id = "99-88-77-66-55-44"
 >>     NAS-Identifier = "0C-8D-DB-11-22-33:vap1"
        NAS-Port-Type = Wireless-802.11
        Connect-Info = "CONNECT 11Mbps 802.11b"
 ++     Meraki-Device-Name = "0c:8d:db:11:22:33"
 ++     Meraki-Network-Name = "Test - wireless"

The lines marked >> are the new, configurable ones and the ones with ++ are now being included as extra, which is great. Is this what is to be expected?

Does this mean that once a customer upgrades to MR28, it will automatically start sending the new extra attributes, and changes the Called-Station-Id and NAS-ID to the default format as per above (which is much better than sending the BSSID MAC)

Again, not a complaint (been waiting for this for years), just ensuring I have my facts correct.

Thanks,

James

[Rodrigo_]

Hi There

That is right, we consolidated all attributes to have consistency among authentication as for RADIUS attributes, so you should see the new ones, which will have no impact.

The change from BSSID to MAC address does now align with the rest of the industry, and it is a change when upgrading to r28.

It is hard to work with BSSIDs, and as for our data, this change should be for the better.

I am happy you like it

[jamesw]

Brilliant so what you are confirming is that in MR28, by default, without the customer logging in and making a change, it will now start sending the AP MAC address in the Called-Station-Id by default (unless configured otherwise), and now include the NAS-ID and the two extra Meraki vendor specific attributes? 😁

[Rodrigo_]

I will update our documentation in a moment for this default behavior. 🙂

You will be able to find it here:

https://documentation.meraki.com/MR/Access_Control/MR_Meraki_RADIUS_2.0

[jamesw]

Thanks! I'll await the update.

[Rodrigo_]

Updated, I am not mentioning all the new attributes that are sent since this would not be compliant with other documentation, however, they will not affect the behavior (most likely depending on your rules) on the RADIUS auth.

[jamesw]

Brilliant, thanks for that.

[jamesw]

Something I noticed... when you enable the RADIUS proxy option, the setting for the Called-Station-Id format disappears, but the NAS-ID format option is there.. this seems a little odd and I don't understand why you still can't set both?

Without proxy:

With proxy:

Bug, or something else?

Thanks

J

[Rodrigo_]

Hi James, that is interesting, i think we should be able to send both, but let me confirm and will get back to you, thank you for bringing this up!

[jamesw]

Thanks Rodrigo!

This is also a similar query - wondering if you might be able to answer?

https://community.meraki.com/t5/Wireless-LAN/Mac-based-authentication-with-ISE-cloud-RADIUS-server-a...

Thanks

James

[Rodrigo_]

I am trying to repro this, could you tell me which authentication are you using?

all the config is done on the new access control page, right?

[jamesw]

Hi Rodrigo

Correct, on the Access Control page. This is what I have set:

Association requirements: MAC-based access control 
Splash page: None or Click-through

Scroll down to the RADIUS options and set:

RADIUS CoA support: Unchecked
RADIUS proxy: Checked

You'll see when you enable the RADIUS proxy option, the new Called-Station-Id option disappears but the NAS-ID option is there!

Thanks

[Rodrigo_]

verified and add it to documentation.

We do not support a customize called-station-id with proxy, since we in fact use it. 

[jamesw]

What do you mean, you don't support it because you use it? 🙂

If a packet is being proxied from an AP, it should honour the same going through the proxy. If you can customise the NAS-ID when going through the proxy, what's the problem doing the same for Called-Station-Id?

This effectively means the proxy is useless as it can't be set to what it needs to be...

[Rodrigo_]

Well not useless right, we will honor the default called-station-id stated in documentation when using proxy. We are giving the ability to still customized NAS-ID, which can be used the same way in RADIUS for rules.

Admins would just have to change the attribute they are using.

But yes, customizing called-station-id with proxy radius is not supported. We are one of few if not the only that allow this 🙂

[jamesw]

I really don't understand this decision. Why introduce a feature to make it more flexible, then take it away? Is there a technical reason why Meraki can't allow a customised Called-Station-Id format? This means your systems do not match and have no parity.

This will mean customers are not able to use the proxy, because it still uses the BSSID as the Called-Station-Id which is not useful. In your previous reply, you state "The change from BSSID to MAC address does now align with the rest of the industry" - but not if using proxy 🤔

[jamesw]

Interested to know more on what you use the "Called-Station-Id" for when using the proxy, and why the format can't be changed? 🙂

Thanks

[Rodrigo_]

Hi James, Unfortunately, the information and use-case it is internal only.

We can use the feature with this limitation, 🙂

[Vdub909]

Will this Beta allow using client VPN through IPV6?

[AlexanderN]

Hmm, you are probably referring to the MX VPN functionality? This is MR beta 🙂