Change of Authorization with RADIUS (CoA) on MR Access Points

[KarstenI]

I did some tests with CoA and 802.11r and came to a different conclusion compared to what is stated in the documentation *and* on the dashboard.

In my network (MR 31.1.5.1), I have an SSID that is configured with 802.1X and both CoA and 802.11r.

The dashboard states that 802.11r would be disabled:

And the documentation states that 802.11r gets disabled:

But in reality, 802.11r is still announced:

And Roaming is done based on 802.11r:

In the RADIUS capture, I only see the initial communication but no further exchange when roaming.

CoA is indeed not working as it should:

• It works when the Client is connected to the AP that made the initial connection (also after a roam back).
• It doesn't work on other APs. When the client is connected to a different AP, the original AP gets the CoA request and answers with CoA-NAK, "Session-Context-Not-Found".

The misleading statements in the dashboard and the documentation should be corrected. Or even better, CoA should be implemented in a way that it works. 😉

[GreenMan]

If you haven't already, you should raise a Support case and present this evidence.   I'd ensure you're on the latest GA firmware before doing so.

[KarstenI]

MR 31.1.5.1

Support would send me a link to the document that I quoted and ask me if I still need help ...

Or do you say that no one from Meraki who is responsible for documentation is reading this sub-forum? I really expected that this is the right place to address this.

[RaphaelL]

You can't have 802.11r and CoA both working at the same time. That's why Meraki tried to implement a warning ( which was done by my request via a case 12-16 months ago ). 

However you can still enable both and endup with the same behavior that you are experiencing. 

[RaphaelL]

If you disable 802.11r first and then enable CoA , you can't enable 802.11r back. That's what they tried to do

However there is still a trick to enable both. You disable CoA. Enable 802.11r and re-enable CoA.

(Which is not disabled as mentionned by KarstenI )

[RaphaelL]

Case opened in 2022-12-08 and closed in 2024-01-26 :

Hi Raphael,

Yes the behavior you are describing has been confirmed by our internal teams (and they've mentioned that this is how this change has been implemented). After they made the change any new networks will not be able to have both CoA and the 802.11r selected. 

Any networks that existed with the CoA and 802.11r enabled (before the change was pushed by our internal reams), will still show the option as being available. If you had CoA and 11r enabled even if you turned toggled them it would still let you keep them both on (for old networks). 

I will confirm if there is a way to disable 802.11r in old networks that have both 802.11r and CoA selected

##### A second note later :

Hi Raphael,

I've checked the changes for the 'redacted' network with our development. 

Just to clarify all of this a bit more, for and old networks, the validation check will not stop you from enabling 802.11r and then CoA, since it checks past config pushes and see that this was a valid config. This is not an issue for new networks (they will be greyed out and blocked). 

What this means is that the actual config will still not get pushed on old networks, when you try enabling CoA, after 802.11r has been enabled (this might not be reflected there visually on old networks but config wise enabling CoA will disable 802.11r).

[GreenMan]

I'm afraid it really isn't, particularly as it's likely the Dashboard behaviour that is unexpected (being able to enable both simultaneously), rather than the documentation being inaccurate.   If CoA can't actually enforce appropriate behaviour on the AP with which the client is currently associated, that's a pretty serious issue.

[GreenMan]

If you have issues with Support not taking a case raised against this seriously, PM me the case ref and I'll take it up with them.