FON Hotspot on La Fonera

From DD-WRT Wiki

(Difference between revisions)
Jump to: navigation, search
Revision as of 03:44, 11 September 2010 (edit)
Magick777 (Talk | contribs)
(Running a FON Hotspot with DD-WRT on La Fonera)
← Previous diff
Revision as of 03:45, 11 September 2010 (edit) (undo)
Magick777 (Talk | contribs)
(Assumptions)
Next diff →
Line 7: Line 7:
= Assumptions = = Assumptions =
-Like most guides, this one makes a number of assumptions.+Like most guides, this one makes a number of assumptions. Specifically, the steps in this guide were carried out on a La Fonera rev. 2100A/B/C, which had been flashed with DD-WRT v24 pre SP2 build 14896. If you're using any other hardware, this guide should be taken as informative but not definitive, and should be read in conjunction with the [[FON Hotspot]] page.
-# We assume you're using an original La Fonera, not a La Fonera+ or a La Fonera 2. Specifically, the steps in this guide were carried out on a La Fonera rev. 2100A/B/C, which had been flashed with DD-WRT v24 pre SP2 build 14896. If you're using any other hardware, this guide should be taken as informative but not definitive, and should be read in conjunction with the [[FON Hotspot]] page.+# We assume you're using an original La Fonera, not a La Fonera+ or a La Fonera 2.
# We assume that the La Fonera you're using is already registered to your FON account. If not, there's more on registration on the [[FON Hotspot]] page. # We assume that the La Fonera you're using is already registered to your FON account. If not, there's more on registration on the [[FON Hotspot]] page.
-# We assume that your La Fonera has already been flashed with DD-WRT v24 pre SP2 build 14896 (or newer). If not, go see the [[LaFonera Software Flashing]] page, and good luck. The HTTP exploit worked nicely for me, though I had to go hunting for the CAMICIA kernel and stuff. That is outside the scope of this document.+# We assume that your La Fonera has already been flashed with DD-WRT v24 pre SP2 build 14896 (or newer). If not, go see the [[LaFonera Software Flashing]] page, and good luck.
# We assume you're already pretty familiar with DD-WRT, otherwise why would you be trying to do this? # We assume you're already pretty familiar with DD-WRT, otherwise why would you be trying to do this?

Revision as of 03:45, 11 September 2010

Contents

Running a FON Hotspot with DD-WRT on La Fonera

The existing FON Hotspot guide apparently doesn't apply to the original La Fonera; this page documents setting a La Fonera up as a FON Hotspot, using the latest DD-WRT firmware as of September 2010. Since that guide was written, there have been many updates to the DD-WRT firmware and, as well as being a specific guide for the original La Fonera, it may be useful reading for anyone proposing to implement FON on DD-WRT v24 pre SP2 or newer, including on other hardware.

Contrary to the information in the FON Hotspot guide, we now seem to be able to configure ChilliSpot from the GUI, we no longer have to work around a memory leak bug and generally a lot has changed.

Assumptions

Like most guides, this one makes a number of assumptions. Specifically, the steps in this guide were carried out on a La Fonera rev. 2100A/B/C, which had been flashed with DD-WRT v24 pre SP2 build 14896. If you're using any other hardware, this guide should be taken as informative but not definitive, and should be read in conjunction with the FON Hotspot page.

  1. We assume you're using an original La Fonera, not a La Fonera+ or a La Fonera 2.
  2. We assume that the La Fonera you're using is already registered to your FON account. If not, there's more on registration on the FON Hotspot page.
  3. We assume that your La Fonera has already been flashed with DD-WRT v24 pre SP2 build 14896 (or newer). If not, go see the LaFonera Software Flashing page, and good luck.
  4. We assume you're already pretty familiar with DD-WRT, otherwise why would you be trying to do this?

Setting up DD-WRT

Configure wireless interfaces

Set up the public FON SSID on the physical interface ath0 and put your private SSID on ath0.1; it needs to be this way around thanks to a 'gotcha' in ChilliSpot - when we tell it to separate WiFi from the LAN bridge, that means it takes the physical interface ath0 out of the LAN bridge br0 every time ChilliSpot starts, so you can't have your private network on ath0 without ChilliSpot breaking it. So, we'll put the public SSID on ath0 and the private SSID on ath0.1; that way we can keep the private network bridged to eth0 and unbridge the public one.

Configure bridged networking

Using Wifi in unbridged mode is not recommended, and using ChilliSpot in bridged mode will not achieve what we want, so the answer is a system of two bridges. Under Setup -> Networking, create a new bridge 'br1' and assign ath0 to it, then assign eth0 and ath0.1 to the existing bridge br0.

This now means that br0 holds our LAN/WLAN interfaces (including the private WLAN), while ChilliSpot can take charge of br1 and use it to provide public WLAN to Foneros.

Configure private WLAN

We don't need a separate subnet for the private WLAN; instead, it should provide bridged access to our existing wired network (which, presumably, already has a DHCP server). So, we already configured the bridging, the only thing remaining is to configure a DHCP forwarder via the GUI (Setup -> Basic Setup). Enter the IP address of your main router / gateway / DHCP server. Strictly speaking, bridged networking should be bridging everything including DHCP, so this setting might be superfluous, but it works for me.

At this point, a client connecting to the private SSID should be treated just as though they were a client on the wired network; the IP address will be obtained from the main WAN router / gateway and clients on this network will get full, bridged access to the LAN. This would be a good time to make sure you've set up wireless security on the private SSID.

Configure ChilliSpot via DD-WRT GUI

With the private WLAN working, we can go about setting up the hotspot. Settings here are shamelessly stolen from the FON Hotspot guide. Note that the Radius NAS ID must be your WLAN Mac address in upper case letters separated by dashes.

Sputnik: Disable
Wifidog: Disable

Chillispot: Enable
Seperate Wifi from LAN Bridge: Enable
DHCP Interface: br1
Primary Radius Server: radius01.fon.com
Backup Radius Server: radius02.fon.com
DNS IP: 208.67.222.222
Remote Network: 192.168.182.0/24
Redirect URL: https://www.fon.com/login/gateway
Shared Key: garrafon
Radius NAS ID: XX-XX-XX-XX-XX-XX
UAM Secret: garrafon
UAM Any DNS: 1
UAM Allowed: www.fon.com,www.paypal.com,www.paypalobjects.com,www.skype.com,www.google.com,www.flickr.com
MACauth: Disable
Additional Chillispot Options: (copy and paste the following 6 lines into box)

uamallowed static.flickr.com,video.google.com,shop.fon.co.kr,secure.nuguya.com,inilite.inicis.com,fon-en.custhelp.com
uamallowed maps.fon.com,c20.statcounter.com,fon-en.custhelp.com,www.excite.co.jp,image.excite.co.jp,adimp.excite.co.jp
uamallowed 216.239.51.0/24,66.249.81.0/24,66.249.93.0/24,72.14.207.0/24,72.14.209.0/24,84.96.67.0/24,213.91.9.0/24,80.118.99.0/24
uamallowed 202.47.16.159,202.47.16.161,202.47.17.159,202.47.17.161,202.47.18.159,202.47.18.161,202.47.19.159,202.47.19.161
uamallowed ssl.google-analytics.com,c26.statcounter.com,www.fonshop.jp
dns2 208.67.220.220

HTTP Redirect: Disable
NoCatSplash: Disable
SMTP Redirect: Disable

Once that's done (and you've verified via SSH that ChilliSpot is started successfully), you should be able to connect to the public SSID and get an IP address in 192.168.182.x. You probably won't be able to ping anything yet, thanks to the stock firewall configuration, but check that both public and private WLANs work as expected and that the client is assigned a correct IP address in both cases.

Open up the firewall & test access

By this point, DHCP will be working but DNS and ping will not; the culprit seems to be a couple of rules in the FORWARD chain that drop traffic from br0 and accept only new traffic from tun0. The quick way to preempt these and get everything working (I don't claim that it's secure) is

iptables -I FORWARD -i br0 -o tun0 -j ACCEPT
iptables -I FORWARD -o br0 -i tun0 -j ACCEPT

adding these under Administration -> Commands and clicking Save Firewall to make your changes persistent. Once it works, go back and add a proper firewall so that clients on the public LAN can't contact anything they shouldn't.

Note that you just created a gaping hole in your network security; unsecured wireless clients can now contact anything in your LAN until you lock it down. You have been warned.

Now test your access via the public WLAN; you should now be able to resolve DNS and to ping hosts both on and off your local network. When that works, you have ChilliSpot working correctly and should also be able to test the redirect to the FON login page.

Secure your LAN

As a bare minimum, change that line that accepts everything from tun0 going out of br0 to accept anything going out of br0 that isn't destined for the LAN. Changing the above lines to the following is sufficient for my situation:

iptables -I FORWARD -i tun0 -o br0 -j DROP
iptables -I FORWARD -i br0 -o tun0 -j ACCEPT
iptables -I FORWARD -i tun0 -o br0 -d ! 10.0.0.0/24 -j ACCEPT

and means that ChilliSpot clients can contact anything outside of my network via the WAN gateway (subject to firewalling and QoS on that gateway), but any attempt to contact anything in my LAN stops dead. This assumes that clients are using OpenDNS; if you rely on DNS or Web servers on your LAN then make exceptions accordingly.

Gotcha: Note that because we're using -I to insert rules at the top of the FORWARD chain, we insert each rule on top of the last, so effectively the list of rules above should be read from bottom upwards. The author wondered for an hour or more why he was dropping everything at the start of the FORWARD chain until this dawned upon him.

Configure FON heartbeat

Exactly as per the instructions in the original FON Hotspot guide, make sure you've enabled JFFS2 first, then set "clean JFFS" to Enable and click Apply Settings. You should end up with just over a megabyte of JFFS space. The following is directly reproduced from that guide, with thanks to the original authors:

All routers running official FON firmware send a "heartbeat" signal back to fon every few hours once they're connected to the internet, mainly to update the router's online status on maps.fon.com and let FON know you're part of their community. To do this, you need to implement the FON Heartbeat in DD-WRT by downloading the heartbeat code originally created by Freddy. You can read more about this code at http://fon.freddy.eu.org/heartbeat/ .

NOTE: The heartbeat uses port 1937 to send information so ensure that this port is not blocked by a firewall on your router. If you're unsure, it's probably open anyway.

Ensure Cron is enabled on the Admin > Management web page and then type (or paste) the following into the telnet prompt to download the files.

cd /jffs
wget http://fon.freddy.eu.org/heartbeat/fonkey
wget http://www.inaudible.co.uk/perm/nolog/thinclient
chmod 755 /jffs/thinclient
ls

After the ls, ensure that you see both the fonkey and thinclient files listed, the latter being a light green colour.

Now start the heartbeat script by typing the following code into telnet:

/jffs/thinclient start

After a minute or two wait, the following line should be printed out, but with your own Wireless and LAN MAC addresses listed.

sent: mode='start' wlmac='00:18:39:xx:xx:xx' mac='00:18:39:XX:XX:XX' fonrev='3' firmware='0.6.6' chillver='1.0-1' thclver='1.0' Something is wrong, /tmp/.thinclient.sh is empty

Ignore the final warning; the heartbeat should now be up and running and appear active on maps.fon.com.