We need to authenticate many users via an external captive portal, but without RADIUS/LDAP etc, so using Meraki Cloud Authentication:       Is there a limit, on how many devices we can have authenticate against a pre-configured Meraki guest user (configured in Network > Users like so). We have enabled the "Allow simultaneous logins" option, but nowhere is a limit mentioned.           We don't need to know, nor care about the user's username (we've already validated them during the captive portal phase), we're merely using this pre-configured username/password in order to authenticate them at the end of the captive portal journey and get them online. The network could have upwards of 10,000 users per day using this username/password. (The user never knows about this user/pass, its all done from our server side via the login_url as part of the normal external captive portal flow).   We can't use the splash with "click through" as we're authenticating the user from the server side API call (once they hit our external captive portal etc), not from the users browser by way of redirects, and click through relies on the p_splash_session cookie which the external server does not have access to as it's set on the nxx.network-auth.com URL initially.   Thanks ... View more

If you have 5000 networks, and you want to apply a custom group policy to some clients across your org, how can this be achieved without creating 5000 group policies (one per network) and mapping the client to each network's created group policy?   Basically, we are looking to assign some clients a particular policy across the estate.   Also, how many clients can be added to a group policy? We need potentially 100k+.   Thanks ... View more

Since 12/13 April we've seen an issue across our customer estate (both In Europe and Americas) where the Meraki Cloud RADIUS client has stopped sending us Accounting Interim and Stop packets. We do get the Start packet, however. This is for captive portal authentications (not WPA2-Enterprise)   This causes a problem because the Interim and Stop packets are needed to read the attributes that include how long the session length was, and how much download/upload usage for the session etc.   The Start packet looks like:   User-Name = "abc123" NAS-IP-Address = 209.206.50.44 NAS-Port = 0 Service-Type = Login-User Framed-IP-Address = 10.3.8.112 Called-Station-Id = "E4-55-A8-AA-BB-CC:ssid" Calling-Station-Id = "A6-96-DA-AA-BB-CC" NAS-Identifier = "Meraki Cloud Controller RADIUS client" NAS-Port-Type = Wireless-802.11 Acct-Status-Type = Start Acct-Delay-Time = 0 Acct-Session-Id = "825284631727869728" Event-Timestamp = "May 19 2023 20:33:37 UTC" NAS-Port-Id = "Wireless-802.11" Meraki-Device-Name = "AP-Name-Here" Authenticator-Field = 0x8c8d2982acee4ebbc1bd4c877dab3776   Normally, once the Start packet occurs, Interim updates are sent every five minutes until such a time when the session ends, then a Stop packet is sent. We're not receiving these packets at all, across hundreds of different customers. We're performed a raw packet capture on our RADIUS server(s) and the packet doesn't even reach us, so the Meraki Cloud is not sending them.   Anyone else seeing this behaviour?   Thanks,   James ... View more

I have three MR33's in an office and between them I'm seeing over 61,000 LLDP broadcasts in 40 seconds, all the same stuff. It's causing over 5MB/s on the switch ports they are connected to and because it's broadcast traffic this is going through all my switches/router. What are they doing? How can I disable LLDP on the AP's so they stop spamming?     Thanks! ... View more

We're testing out the following:   Association requirements: MAC-based access control  Splash page: Cisco Identity Services Engine (ISE) Authentication   We run a cloud RADIUS server which acts as the ISE in terms of the RADIUS handling.   So the flow currently works like this:   Client associates to SSID Local AP sends Access-Request to configured RADIUS cloud server IP Our RADIUS replies with an Access-Accept and a Cisco-AVPair redirect url Client is redirected to our splash page URL and registers etc   All good up until this point, but the problem is that to get the user online, we have to send a CoA request back to the local AP from our cloud RADIUS. Whilst we can open the firewall and perform a port forward to the AP, this only works if there is a single AP. More than one AP, and the solution falls over because you can't externally access all the different AP's using a single port forward.   Why can't Meraki allow the RADIUS proxy option to work with this setup? For true captive portal authentications we can send a CoA back to the Meraki cloud which in turn authenticates the user on the local AP. But for ISE, it disables the RADIUS proxy option.    Not everyone runs a local RADIUS server!   Does anyone know an alternative way of achieving MAC authentication AND external captive portal fall-back?   Thanks   J   ... View more

In the UI, you can select:   Association: MAC-based access control Splash page: Click through   It accepts this and all is okay (I know you can't use sign on with RADIUS and MAC-based access control together)   However, how does this work in practice?   I would expect, that is the RADIUS server replies with an Access-Reject, the end user will then be redirected to the configured click through  splash URL, and if Access-Accept, the end user will be straight online without any splash authentication required.   But, it seems to not work like this. If you do Access-Reject, it doesn't allow the device even to associate. If you do Access-Accept, the user is connected with no click through splash redirect and has full Internet. So, how do you actually get it to redirect someone to the splash page?   Thanks   J ... View more