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 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
