I have several routers running with hotspot but I noticed that only some devices are displaying to the user the message about the "Sign-in to WiFi network" and then opening the browser so my question is: can I force all devices to show this message doing something on the router side?
I guess that Android devices are making some kind of request to verify if the sign in is required or not, do you know what kind of request or check is doing? so I can block it to force the message?
Android does this:To determine Internet connectivity and captive portal status when a client first connects to a network, Windows performs a series of network tests. The destination site of these tests is msftncsi.com, which is a reserved domain that is used exclusively for connectivity testing. When a captive portal is detected, these tests are periodically repeated until the captive portal is released.
To avoid false positive or false negative test results, your captive portal should not do the following:
• Allow access to http://www.msftncsi.com when the user does not have access to the Internet.
• Change the captive portal behavior that is displayed to clients. For example, do not redirect some requests and drop other requests; you should continue to redirect all requests until authentication succeeds.
That's the behavior of the Hotspot already, unless you have *.google.com in your walled garden to avoid SSL certificate errors scaring your customers. You could probably make a rule in walled garden that overrides *.google.com, for example walled garden IP list, add dst-host clients3.google.com action=reject.Excellent information!!
Is it possible to block http://clients3.google.com/generate_204 or http://www.google.com/blank.html requests in the router until the user is validated by the hotspot? I guess is possible with some script, no? To block those urls until user get 'active' in the hotspot? Can anyone help me with such script?
If you could force a device to run an application and for that application to perform a specific task, just by sending/manipulating network packets... there's a word for that: security exploit.
Yes, I do have *.google.com in my walled garden list.You could probably make a rule in walled garden that overrides *.google.com, for example walled garden IP list, add dst-host clients3.google.com action=reject.
That should be correct.Yes, I do have *.google.com in my walled garden list.You could probably make a rule in walled garden that overrides *.google.com, for example walled garden IP list, add dst-host clients3.google.com action=reject.
So, I just need to create this rule to reject clients3.google.com and set it before the one of *.google.com, right? In that case I will reject only that host and the rest of *.google.com will pass.... correct?
If memory serves, these hostname walled garden rules function by creating dynamic entries in the firewall rules whenever they get matched. If clients3 is already in the table due to previously being matched by *.google, then perhaps it is still being allowed because of this.I have all these routers installed on remote locations... I still don't see Hits on this deny rule so I'm not sure is working...
probabily depends on https site..Anyone ever got this to work? im facing the same exact issue. the captive portal wont load and the gstatic connectivity returns net::ERR_CONNECTION_RESET