Hi,
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?
Thanks!!
maybe is related with using or not Google DNS? if I use them then the “Sign-in to WiFi network” won’t be displayed in the hotspot? (just a theory)
That’s pretty much going to depend on the OS of the device in question.
I know Apple devices do it also.
Windows apparently sends checks too, but I’ve never had a browser window pop up with a login screen.
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. 
If the device doesn’t do it, then you just have to post signs / tent cards / stickers / train clerks to tell people / etc.
For iOS, the requirements are:
To implement a Wi-Fi popup login page:
1.DNS request for > http://www.apple.com > must not fail
2.HTTP request for > http://www.apple.com/library/test/success.html > with special user agent CaptiveNetworkSupport/1.0 wispr must not return Success.
Windows Phone 8 and 8.1 are WISP-r capable https://msdn.microsoft.com/en-us/library/windows/hardware/dn408679.aspx.
They also do 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.
Android does this:
Android’s captive portal detection, as of AOSP 4.0.1, tries to contact > http://clients3.google.com/generate_204 > or > http://www.google.com/blank.html> .
TonyJr
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?
Thanks!!
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.
That would keep the bulk of google.com working with SSL walled garden, but causing the detection URL to get redirected to the login screen, which is how the device knows there’s a captive portal.
When I was child (years ago), I was trying to do that, but fail 
My best way is to tell your customer to open browser - as I do
Yes, I do have *.google.com in my walled garden list.
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? 
That should be correct.
Capture.JPG
even if I create the deny for clients3.google.com before the allow of *.google.com, it always goes after it… do you think it will work anyway? or it works like firewall rules where the order matters?
If you have access to the site, try opening it in a browser.
If you see your hotspot page, there’s your answer, right?
I would think that the most specific match should win in this case, but haven’t ever tested such a thing.
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… 
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.
Try disable / re-enable these two rules and watch what happens in the IP firewall rules while you do it.
I tried disable/enable these two rules and it didn’t work (also tried restarting the routers). I did several tests with different routers having both rules and the results are not good… only a few of the times the domain was really blocked and I got the popup
Maybe I can do some script to block this domain until the user is authenticated in the hotspot? do you think is possible?
put clients3.google.com in the IP walled garden.
The IP walled garden will create dynamic rules in the hs-unauth chain by performing DNS lookup on the hostname(s) you specify. This should do what you want using automatic, always-running features in the Mikrotik.
Great idea, I will do that!
Thanks!!
Hello.
Am I right that to force the captive portal notification I need to block clients3.google.com?
I want to make captive portal without internet. I did a DNS record like .* = ROUTER_IP
And popup of login page works in Windows and iOS but not in Android.
So what is the workaround to make the notification appear in Android if there is no internet access in the router?
Thanks.
my solution was tu remove *.google.com from the Walled Garden list…
Nothing to do..
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