On 13 June 2015 at 17:10, Michael Catanzaro <mcatanzaro@xxxxxxxxx> wrote: > 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...? > Think of every way that someone has ever set up a GNOME desktop to do something that you didn't plan.. and now take the factorial of that number... and you will probably be close to the numbers of ways 'captive' portals have been set up in the real world. I have seen the following as ways captivity is setup: 1) A strange ipv4-to-ipv6 item. If you tried to go out native in ipv6 it was allowed.. but all ipv4 got converted to ipv6 and then back to ipv4 on the regular internet. 2) A weird satellite system that converted tcp2udp and udp and icmp were allowed out naked. 3) multiple systems all supposedly using some industry standard but not reacting in the same way. 4) systems which allowed everything but 25/80/443 until you dealt with the capture. 5) systems which allow for N packets on any port but after that number block everything until you have verified. 6) systems which put you on the capture vlan and all dns goes to some 10.0.0.1 ip until you are verified and then puts you through a Nat on Nat vlan to get the internet. Is the code on how ChromeOS or Android detects captivity part of the 'public' code? It seems to do a 'good' job in finding many captive portals so might be something to get an idea on how many weird ways things are out there. > 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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel > Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Stephen J Smoogen. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
