[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/06/13 22:19, Gordon Henderson wrote: > On Thu, 13 Jun 2013, Mark Evans wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 13/06/13 09:23, Gordon Henderson wrote: >>> >>> But you're right - there are no standard for captive portals, >>> but in all the ones I've used, I've only seen 2 ways it's >>> accomplished - one uses DNS to direct all web requests to an >>> internal page and the other force re-directs web traffic. >>> >>> The force redirect is more efective in my experience - and I've >>> designed systems that use both. >> >> It's likely to depend if the port 80 redirect operates at the IP >> level or if it operates at the HTTP level. > > You do it at the IP level. You use Linux firewalling to do it. > >> The former (along with the DNS method) will most likely enable a >> browser with a proxy exception to communicate with your portal. > > The browser doesn't have a choice. It sends out a request for > i.p.address, port 80. The router picks this up and forwards the > request onto another server, re-writing the target IP address as > it goes. (this other server can be the same as the router) This is > a standard Linux firewall rune. Not everyone setting up such a system will be using Linux or doing things purely as a TCP port 80 MitM. >> Since so far as the browser is concerned it is using a URL it is >> able to access directly. Using an HTTP redirect is likely to fail >> since it's unlikely that the resulting URL will match any proxy >> exceptions in the browser. > > It doesn't have to match: Router says: Do I know this IP (of the > client device)? Yes, let it through, no, send it a redirect. The target URL needs to be one where the browser will attempt to make a connection to TCP port 80, through the wireless interface. If it's going to try and send this, to a proxy, using a different TCP port then it will be unable to do so. Similarly if the machine was trying to route the connection via a VPN interface. >> Note that the IE "Bypass Proxy Server for Local Addresses" option >> dosn't do anything like comparing the IP address of the target >> URL against the IP address(es) and netmask(s) of the machine. >> Which would probably be very useful in this context. >> >> Of course you are still going to be entirely stuffed with a >> device which dosn't have a web browser. E.g. a Wi-Fi SIP phone >> or one where the "web browser" actually runs in a data centre >> somewhere else. > > Yes you are (stuffed). This has been considered acceptible in the > systems I've deployed - beause the rules have been: Give us your > email address and we give you free Internet. In the situation of a hotel there are alternative channels for giving "them" an email address. If the booking process has involved email they even have reason to consider this a "valid" email address. Otherwise someone may as well claim to be "dave@xxxxxxxxxxxxxxx" or similar. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlG6uxEACgkQsoRLMhsZpFeKLACfcJMU7ph3mB0Tn3DHAB6xrScb 3goAn0XUziS1puOhXouic96kPzc2BN2b =YMSf -----END PGP SIGNATURE----- -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq