Chromebooks using Advanced Protection will not trigger splash page

[MariposaJon]

This is something similar to https://community.meraki.com/t5/Wireless-LAN/Splash-page-not-showing-automatically/m-p/29247, which had a a lot of good info I was not aware of.

I do part time IT work for a small library, that is part of a regional system which uses Meraki.  Recently Chromebooks will not connect if the account has advanced protection.  There is a workaround: log out and use guest mode.  The splash screen comes up, the lease is assigned to the MAC,and when you log back in the WiFi is fully connected.

What I have subsequently discovered is the "neverssl" trick where you go to neverssl.com, and it can be used to trigger the splash page.  So for example on my Ubuntu box, the normal hotspot login is NOT a true web browser (it is a Webkit app, which I would call a pseudo-browser), but what I do is not accept the T&Cs on that splash screen and just close it.  Then I open Chrome, type http://neverssl.com and the splash is triggered.

However that does not work on the Chromebook with Advanced Protection.

BUT!!  Here is an interesting factoid: I have my own WiFi router (OpenWRT thing) and I can put a captive portal on it.  If I go to that and do the neverssl trick, then I reconnect to the library Meraki and do the neverssl trick the splash page does come up!  It is as if there is some type of DNS caching involved.

Is there no way a Meraki router can be configured to do this right?

I am not in charge, some central IT people are, but it would be nice to have an answer rather than just hurling political complaints at them.  My Chromebook works fine generating the splash page with my OpenWRT device, so I know that fundamentally there is not a technical reason a Meraki can't be "corrected".

[MariposaJon]

I should mention that the guest mode workaround is not always an option, especially for school kids with managed devices.  This literally then excludes thousands of students, and I think students should be getting better attention on this problem, wherever the issue lies.

[TBHPTL]

Its not DNS caching its the fact the neverSSL is HTTP based and thus the traffic can be HIJACKED/CAPTURED and redirected.  Redirecting HTTPS traffic is viewed as bad actor/attack. Redirecting HTTPS traffic is a no no.  Each OS flavor handles how it deals with and detects if a  captive portal is present.  See this link from WBA for a complete and thorough breakdown:

https://captivebehavior.wballiance.com/

[MariposaJon]

The link is great in general, thanks.  It appears to be a little outdated in terms of specifics, but still very useful.

[PhilipDAth]

What kinda of authentication are you using at the moment for the WiFi network?

[MariposaJon]

It uses no password, the user just needs to accept the T&C's.