This is a great hack, although it requires a lot of work. I have it installed on my server and my Mac, and surfing/e-mailing works fine.
I have been toying with the idea of having the client part ported to my iPhone, so I can use paywall wifi directly from a mobile device. This would require porting the Perl client code over to C.
Generally though wireless hotspots allow DNS traffic out (the DNS server isn't filtered) but not ICMP. In fact if anything is filtered it tends to be ICMP. I'm not really aware of any situations where ICMP tunnelling is useful. Anyone know of any?
I use <a href=code.kryo.se/iodine>iodine</a> as a wrapper for this, and I use it very frequently (as I fly internationally at least once every few weeks). It usually sits as a service on my home server. So far the only airport where I didn't make it to work was in Miami (where I connected though a socks tunnel though my iphone 3g anyways).
dns tunelling is slow, but handy for console/screen situations. I usually use it to download the newspaper before getting into the plane (a bunch of wgets) and refresh the rss feeds on newsbeuter.
Use Kismac to collect MAC addresses with significant packets in/out, clone a MAC, ssh -D9091 to my remote server, tunnel everything through my local SOCKS5 port 9091. Works well enough for me.
Just thinking off the top of my head, but wouldn't cloning the MAC cause conflicts with the existing MAC on the network?
I've done something similar with cloning my iPhone MAC to get free WiFi access on my laptop using the free AT&T WiFi provided to iPhones.
But if what you're saying actually works, this seems like a dead simple way of getting free access. I already have Kismac installed, so I'll definitely try it. Thanks!
I might be wrong, but wouldn't this not help the situation at airports where the AP resolves all DNS requests to a page that is like "pay for service!"?
I was under the impression that in those configurations the AP intercepts all the DNS packets and responds with a fixed IP.
It would be nice to get around port blocking filters though...
No, I think that's the firewall modifying the headers. I still encounter the portal page when I use a different DNS (although the portal hostname doesn't resolve). I'm not sure if they have even figured out how to do DNS authentication yet.
Not exactly. The general term for the system that captures your first page is "captive portal". The short version is they intercept your first Internet-bound web request and send you a HTTP redirect to their login site. Once you give the portal whatever it needs to authorize you the local firewall is configured to allow your traffic out.
Generally captive portals will leave your DNS alone. They don't really have a lot of choice about this: if they poison your name cache you won't be able to get to your home page. Windows used to (still may) hold on to names for a minimum period regardless of TTL. A fair number of laptops have custom DNS. Combine those two and you can almost always get correct recursive DNS and frequently UDP 53 out.
Not sure about this. I've tried to use OpenDNS behind a "buy my wireless for 24 hours" at an airport and I still got the page requesting me to buy a page.
Also, even when I pinged servers the IPs were resolving to their "purchase" page. Unfortunately, I didn't have an IP of a site on hand to see if I could request by IP out.
If the captive portal is rerouting every IP packet (apart from DNS lookups) from an unauthorized MAC to the same central server (so that it can spoof the HTTP redirect to the payment page), this is exactly what you'd expect to see.
It doesn't matter what DNS you're using - the DNS lookups should resolve to correct IPs otherwise your local DNS cache would be poisoned.
The captive portals I've seen don't tamper with HTTP headers at all, or were you referring to IP headers? As for DNS, I don't think there's any safe way to avoid providing unauthenticated hosts with working DNS.
I may be getting things confused here, but I usually see captive portals do HTTP redirection (looking from a sniffer). That would involve tampering with the headers, correct?
Just IP NAT on the dest address sending you to the portal server. So actually they do tamper with headers, but only IP headers. You don't actually get any traffic to the real site until after your machine has been exempted from the NAT rule (and presumably a drop rule for non-HTTP traffic). There's an open source captive portal called NoCat that you can poke at if you ever want to set one up yourself.
I've set this up and it's pretty slow. Cool hack though. Better off with 3G card or tethering bluetooth on a 2G network. Useful with international travel though where phones get sketchy...
There's some overhead in each packet -- maybe a 4x increase in the number of bytes -- and bouncing between DNS servers will give you an increase in latency -- maybe an extra 500kbps -- but it won't be so bad as to make this unusable. I imagine IP-over-DNS-over-neighbour's-wireless would be much faster than IP-over-phone-line in most cases.
I have been toying with the idea of having the client part ported to my iPhone, so I can use paywall wifi directly from a mobile device. This would require porting the Perl client code over to C.