I think similar questions have already been asked over and over, but my question is slightly different. I understand I can't redirect HTTPS traffic to the Captive Portal landing page without causing SSL errors in the browser. I understand why. I agree, because that's just the way things are and I'm happy SSL is with us.

However I can tell a sligtly better solution than giving up on this does exist, because I used it a few days ago in a school. At first I hadn't realized my (Debian 8) notebook had automatically connected to their open wifi network, and I typed some search terms in the Chrome address bar. My default search engine is Google, which serves only HTTPS pages. The page where I expected to obtain the Google results showed a connection error instead (unavoidable), but Chrome automatically opened a new tab showing the Captive Portal landing page, with the login form.

That's is what I'd like to implement using whatever Linux distro it takes and whatever hardware, but let alone the distro and the hardware for the time being and let's stick to the principle: how does that new tab trick works? At what protocol level is it implemented? How?

1 Answer 1



Chrome attempts to fetch http://clients3.google.com/generate_204 and determines it's hitting a captive portal if that URL returns something other than a 204.

Apple's operating systems do this as well via http://www.apple.com/library/test/success.html.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .