GNOME captive portal helper (was Re: F23 System Wide Change: Default Local DNS Resolver)

[Michael Catanzaro]

On Sat, 2015-06-13 at 15:54 -0400, Paul Wouters wrote:
> If the captive portal uses the system's DNS, and the system has 
> cached
> www.gnome.org from when you were on a previous network, your captive
> portal check might use a cached DNS resolve and try to use an HTTP
> connection to a blocked IP address, because the local forged DNS 
> answer
> to the local hotspot IP never got triggered.

Thanks. I am still trying to understand this fully. I assumed the
portal would hijack TCP connections, but if the portal uses DNS
hijacking only and does not hijack TCP connections to the real www.gnome.org, and we attempt to open a TCP session to the real 
www.gnome.org, 
and the portal is only expecting us to visit a different host due to
its DNS hijacking, then I understand that we're out of luck and the
portal's login page will never show. OK, I've followed that far.

There is one thing I don't understand. Surely the above is exactly what
will happen if you were to get stuck behind a captive portal with
Firefox or any normal browser? But portals still work reliably for
users. So either the browsers are doing a connectivity test similar to
what you described (to a host with a DNS TTL of 0) and we have to do it
too, or the portals are prepared to hijack TCP connections and not just
DNS and we have no problem, or the portals just don't work reliably for
browsers and portal-helper is an opportunity to fix that. Right...?

Anyway, once I understand this properly, I will file a bug upstream (or
if you have a GNOME Bugzilla account, it would be better if you do so,
to be CCed on responses). Thanks for catching this issue.

Michael