|
Account ♦ Password ♦ Mailsetup ♦ Info Services ♦ Workstations ♣ Linux ♣ MacOS ♦ Chat ♦ Files ♦ Backups ♦ Printers ♦ Network ♦ Statistics ♦ Downloads ♦ Links News ♦ Newsletter ♦ Submit ♦ Search Readme Hacks ♦ Linux Tools Contact About |
from the coffee-at-work dept. dept. Some time ago I noticed that it was possible to have free wireless Internet at Starbucks. As a heavy coffee consumer and Internet-addicted twerp, I decided to check it out instantly. But it turned out to be not that easy... This article describes what to do to gain permanent Internet access with Linux at Starbucks Coffeehouse. I set up VPN using the open sourced implementation of the cisco vpn client as described in this fantastic readme (note that debian sarge comes with a vpnc package so it's not needed to compile from source anymore). I ran a dhcp client, I ran vpnc-connect and YES! I had Internet, coffee and the wonderful Starbucks ambiance all at the same time. But wait... after two minutes there was no Internet anymore. Now what happened? I realized that the dhcp lease time was 90 seconds (1.5 minutes). This means that my dhcp client had to renew the lease all 1.5 minutes. The router at starbucks drops everything coming from an IP without valid dhcp lease. I had a glance at my routing table and realized that something went wrong there. This is the output of dhclient (from Starbucks at Stauffacher in Zurich):
DHCPREQUEST on ath0 to 255.255.255.255 port 67
DHCPACK from 10.4.55.1 I took a butcher's at RFC 2131 to understand how dhcp works. I read that the dhcp client first tries to connect the dhcp server several times with unicast and then sends out an udp broadcast to ask for a new lease. The server sends the following server-identifier: 10.0.0.2. And guess what? The netmask of the local interface is 255.255.255.0! vpnc adds a default route through the tunnel-device. This means that the request is being routed to the ETH instead of the local network. And it looks like exactly the same happens with broadcasts. I hacked the following line into my vpnc-connect script (at the bottom of the file just before the routing cache is being flushed): ip route add 255.255.255.255/32 via $(cat "$defr") It routes broadcasts to the local net. That one worked quite well (stable connection for more than one hour), but it was not 100% reliable. I added one more route to route the unicast requests: ip route add 10.0.0.2 via 10.4.55.1 dev ath0 The downside of the route is that it requires some voodoo to place it into the vpnc-connect script. (but it's perfectly possible, see (*)) As far as I can see the vpn runs stable now and the unicast requests reach the server:
Aug 25 20:08:49 ina dhclient: DHCPACK from 10.0.0.2 I hope this helps some students and staff members to cash in on the marvellous synthesis of coffee and Internet.
(*): It should be possible to hack something like
ip route add $(tac /var/lib/dhcp/dhclient.leases |grep -am1 dhcp-server-identifier| awk '{print $3}'|sed -e 's/;//') via $(cat "$defr")
into the vpn-connect script, I didn't test it though. (awk-only solutions are welcome) < | >
|
|
|||||||||||
|
|||||||||||||