FON Hotspot on La Fonera

From DD-WRT Wiki

(Difference between revisions)
Jump to: navigation, search
Revision as of 14:52, 18 December 2011 (edit)
Magick777 (Talk | contribs)
(Adding additional routers)
← Previous diff
Current revision (19:22, 22 June 2012) (edit) (undo)
Glenn (Talk | contribs)
(+ Category:LaFonera Software (en))
 
Line 328: Line 328:
Done correctly, a client connecting wirelessly to the virtual access point is bridged (over an EoIP tunnel across the wired network) to the Fonera, where it gets bridged onto Chillispot for DHCP. authentication & access control. tunnelled from Chillispot through firewalling and QoS, out onto the LAN bridge of the Fonera and through the gateway to the wider Internet. That is every bit as convoluted as it sounds, but current status is Works For Me. Done correctly, a client connecting wirelessly to the virtual access point is bridged (over an EoIP tunnel across the wired network) to the Fonera, where it gets bridged onto Chillispot for DHCP. authentication & access control. tunnelled from Chillispot through firewalling and QoS, out onto the LAN bridge of the Fonera and through the gateway to the wider Internet. That is every bit as convoluted as it sounds, but current status is Works For Me.
 +
 +[[Category:LaFonera Software (en)]]

Current revision

Contents

[edit] Running a FON Hotspot with DD-WRT on La Fonera

The existing FON Hotspot guide says it "may not work" on 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. Contrary to the information in the FON Hotspot guide, which was written a couple of years ago, 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.

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.

[edit] References

This is by no means the first attempt to document setting up a FON hotspot using ChilliSpot on a Fonera, but it updates previous material to reflect recent improvements in the DD-WRT firmware. The author is indebted to the (unknown) authors of the following pages:

[edit] Compatibility assumptions

Like most guides, this one makes a number of assumptions about what you're trying to achieve and about the hardware and firmware you're using to do so.

  1. 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 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. With that said, this guide can probably be used on most routers running DD-WRT v24 pre SP2.
  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; please read it before proceeding.
  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.

[edit] Setting up DD-WRT for FON

We assume that your LaFonera is connected to a wired Ethernet network, obtaining Internet access through some sort of gateway, that the LAN address, netmask and gateway are static, that you have both SSH and Web GUI access and a degree of familiarity with DD-WRT.

[edit] Configure the 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 will take 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.

[edit] 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.

[edit] Configure the 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.

[edit] 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.

[edit] 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.

[edit] 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. The following is sufficient for my situation:

# Allow desired traffic from tun0
iptables -I INPUT -i tun0 -j ACCEPT
iptables -I FORWARD -i tun0 -j DROP;
iptables -I FORWARD -i tun0 -o br0 -j ACCEPT
iptables -I FORWARD -i br0 -o tun0 -j ACCEPT

# Block traffic to unauthorised RFC1918 addresses in the PREROUTING stage
iptables -t nat -I PREROUTING -i tun0 -d 192.168.0.0/16 -j DROP
iptables -t nat -I PREROUTING -i tun0 -d 169.254.0.0/16 -j DROP
iptables -t nat -I PREROUTING -i tun0 -d 172.16.0.0/12 -j DROP
iptables -t nat -I PREROUTING -i tun0 -d 10.0.0.0/8 -j DROP
iptables -t nat -I PREROUTING -i tun0 -d 192.168.182.1/32 -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 FON clients are using external DNS such as 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.

[edit] Configure the 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. Now go on and add a cron job to run the heartbeat every half an hour, i.e.

24,54 * * * * root /jffs/thinclient cron > /dev/null 2>&1 &

and you should hopefully find yourself with a working FON hotspot.

Note: if you're following this guide on something other than a Fonera, and you don't have JFFS, see the Without JFFS section of the generic FON Hotspot guide.

[edit] Finishing touches

Items in this section are optional extras, not critical to the operation of your FON spot. Some items in this section may still be works in progress. Use at your own risk; feel free to add any recipes here.

[edit] Custom pre-login page for FON users (optional)

Since we're no longer running the Fonera firmware, we're perfectly free to use ChilliSpot's "uamhomepage" parameter to display a customised intercept page from which users can choose to login via FON, or do whatever else we allow them to.

[edit] Requirements

  1. a web server capable of serving up the intercept page and any associated content
  2. access to that web server configured in the "uamallowed" variable
  3. a link on the intercept page to proceed with RADIUS login

[edit] Possible approaches

[edit] Web server on Fonera

As discussed on the WEB_server page, it's possible to run a second instance of httpd within DD-WRT itself, however CGI scripts no longer work and I don't know how to write ASP or what support for it there is within the DD-WRT httpd, so effectively this is limited to static HTML.

This is fine for a simple landing page that tells users what they're connected to, what they can use it for and how to get in touch, but it doesn't offer the flexibility to allow would-be users to contact me there and then e.g. to request local or VPN access, nor does it allow me to grant such access upon registration if I want.

[edit] Web server on LAN

[edit] Web server on Internet

[edit] Obtain IP address via DHCP (optional)

The behaviour of the original Fonera firmware is to obtain the LAN IP address via DHCP, which is not natively supported by the Web GUI configurator of DD-WRT. It is also not recommended unless you know you have a good reason for needing the Fonera to configure itself via DHCP; the author is quite happy with static IP addresses for his routers. But, if you're setting one up for Grandma, or deploying a job lot of them across a campus, you can follow the instructions over on the Wireless Access Point page to add DHCP functionality via a startup script.

[edit] Afterthoughts

Note: this section is a work in progress and items in this section should be taken as ideas, not necessarily tried and tested recommendations.


[edit] Additional private WiFi subnet via EoIP (optional)

It would be nice to be able to provide another private WiFi subnet (i.e. not using Fon) for friends & neighbours, giving the option of sharing internet access on a more permanent basis without touching my own network. We cannot do this on the Fonera itself, or we'll end up with NAT behind NAT; so this section assumes your Fonera is running behind another DD-WRT router (in my case, a DIR-615).

[edit] Limitations

The method described below currently works for one additional private WiFI network on one EoIP tunnel; it relies on connecting a virtual WAP, through a virtual ethernet cable provided by EoIP, to a virtual bridge on the gateway. It doesn't seem we can create multiple bridged EoIP tunnels between the same two hosts on the same LAN to repeat this procedure for multiple subnets, or at least, it didn't work when I tried it, and neither will bridging all the VAPs to a single EoIP tunnel at the Fonera end, because each physical interface (which an oet tunnel emulates) can only be a member of one bridge, so we're stuck for providing separate DHCP at the router end. If anyone can see a way of getting this to work for half a dozen VAPs, through separate tunnels, to separate bridges with separate DHCP servers, please update this page accordingly.

[edit] Additional wireless SSID

The starting point is to set up the extra wireless network on the Fonera, using pretty much the same setup as we did for the private WLAN above, except that we do not want it bridged to the LAN interface on eth0/br0. So, we create a new VAP as ath0.2, bridged mode, and then we create a new bridge br2 and assign ath0.2 to br2. We'll give it the address 192.168.1.1 and netmask 255.255.255.0. Set up WPA2 or other encryption as desired.

[edit] Tunnelling

Before we worry about DHCP, the next question is how to put a NAT gateway into the above subnet, in such a way that clients on 192.168.1.1/24 can deal directly with my gateway router. This will necessarily involve some sort of tunnelling, but exactly how to achieve it is open to debate.

One approach is that the upstream router gains an IP address on our private network and offers DHCP and gateway to clients on the private WLAN, via the bridge we created on the Fonera. This strikes me as simplest. The other approach is to let the Fonera manage its own DHCP assignments and act as host to the WLAN clients, a la ChilliSpot, then somehow bridge and tunnel the whole thing through to the upstream router as if the Fonera were just another interface on that router.

[edit] Tunnelling protocols

Next comes the business of deciding precisely how to tunnel the packets across my local LAN.

[edit] OpenVPN

OpenVPN was discounted as an idea because the DD-WRT build on my upstream DIR-615 router doesn't support it. The Fonera build does, though, so if anyone goes the OpenVPN route then feel free to add details here.

[edit] PPTP

PPTP is the only VPN option common to both devices, but I'm not convinced I need the complexities of a VPN to shift packets around my local area network.

[edit] EoIP

That leaves us with Ethernet over IP, which thankfully turns out to be the right tool for the job. First, configure an EoIP tunnel on both the upstream DD-WRT and the Fonera using the Web GUI; set both ends to Bridged mode and enter the corresponding LAN IP addresses for the opposite ends of the tunnel. Apply your settings and up comes your tunnel, as interface oet1.

[edit] Configure EoIP at command line

Now comes the gotcha; the Web GUI's Networking page doesn't know about oetN interfaces and so it won't let us reassign the tunnelled interface to br2, which we need to do on the Fonera to bridge it with the WLAN. Fix that via SSHd for now, with:

brctl delif br0 oet1
brctl addif br2 oet1

and then, while you're there on the Fonera,

ifconfig br2 192.168.1.254 broadcast 192.168.1.255 netmask 255.255.255.0

Now, moving over to the upstream router, we need first to create another bridge on there (do this via the GUI), and then a similar process to set up the bridged interface.

brctl delif br0 oet1
brctl addif br2 oet1

and then, while you're there on the upstream router,

ifconfig br2 192.168.1.1 broadcast 192.168.1.255 netmask 255.255.255.0

The effect of all those incantations should be to give you a bridged interface br2 on the upstream router, containing only the interface oet1, and having IP address 192.168.1.1, plus a bridged interface br2 on the Fonera, containing interfaces oet1 and ath0.2, and having IP address 192.168.1.254. Subject to any firewall restrictions, you should now be able to ping those addresses from both routers.

[edit] Configure EoIP settings in nvram

Once it works, we need to get these settings into nvram in order to make them persistent. First, on the Fonera, set up the IP addresses of the bridges in the GUI, so we have less to do. Then check out the existing bridgesif variable:

root@fonera:~# nvram show | grep bridgesif
bridgesif_count=4
bridgesif=br0>eth0>63 br0>ath0.1>63 br1>ath0>63 br2>ath0.2>63
size: 24354 bytes (41182 left)

and do what seems to make sense:

root@fonera:~# nvram set bridgesif="br0>eth0>63 br0>ath0.1>63 br1>ath0>63 br2>ath0.2>63 br2>oet1>63"
root@fonera:~# nvram set bridgesif_count=5                                                          
root@fonera:~# nvram commit

Moving swiftly on to the upstream router, it didn't have any other previous bridges, so all I did was

root@router:~# nvram set bridgesif="br2>oet1>63"
root@router:~# nvram set bridgesif_count=1      
root@router:~# nvram commit

Hopefully, that should make our changes permanent, or at least it will until you edit something and the GUI buggers them up again. If you want to make this more permanent, you can insert those commands into the shutdown script - just remember, if you do, that this will supersede any future changes you may wish to make to bridging via the GUI, so wait until you've finished playing before you configure startup or shutdown scripts.

Perform a reboot test on both your Fonera and the upstream router and verify that the tunnel comes back up without manual intervention.

[edit] Add an extra DHCP Server

With our tunnelled bridge up and running, we need to provide DHCP and NAT for clients on the private wireless network. I chose to put the DHCP on the upstream router to avoid the need to specify a non-standard gateway address; this was as easy as filling out the Multiple DHCP servers tab under Networking (on the upstream router).

So, in theory, we should now have:

  • an additional private WLAN on the Fonera
  • bridged through an EoIP tunnel to the upstream router
  • DHCP, DNS, NAT, UPnP provided by the upstream router

and, if all that is working, the ability to connect a wireless client, get an auto-assigned IP address in 192.168.1.x and connect to the Internet just as though we were using an ordinary NAT router.

[edit] Update your firewall configuration

Since we've just added another interface and subnet to the Fonera, we'd better update the firewall to suit. We want to do more or less what we did for the ChilliSpot clients; block all traffic destined for RFC1918 addresses but allow traffic to the Internet. Add something like:

# Block traffic to unauthorised RFC1918 addresses from our extra private WLAN
iptables -t nat -I PREROUTING -i br2 -d 192.168.0.0/16 -j DROP
iptables -t nat -I PREROUTING -i br2 -d 169.254.0.0/16 -j DROP
iptables -t nat -I PREROUTING -i br2 -d 172.16.0.0/12 -j DROP
iptables -t nat -I PREROUTING -i br2 -d 10.0.0.0/8 -j DROP
iptables -t nat -I PREROUTING -i br2 -d 192.168.1.1/32 -j ACCEPT

[edit] QoS arrangements for multiple networks

Clever though this might be, we've just caused ourselves a headache in terms of bandwidth restrictions because any QoS statements we apply to tun0 for ChilliSpot don't apply to our new interface on br2. The only way we can rate-limit the overall traffic to and from the Fonera is to put our QoS on eth0 - but if we do, then it also applies to LAN traffic on our private WLAN (bridged to our own wired Ethernet), which probably isn't what we want either.

That leaves us with a number of choices:

  1. put QoS on the two separate interfaces and accept that it will be imperfect
  2. put QoS on our Fonera's LAN interface eth0 and provide separate classes for Internet traffic and LAN traffic
  3. leave QoS to the upstream router and avoid the complexities on the Fonera altogether

[edit] What are our requirements in terms of QoS?

Which of the above is best will probably depend on a variety of factors, including the nature of the QoS arrangements on the upstream router and how mission-critical QoS is in your particular network. From the point of view of just prioritising my VoIP traffic over someone else's bittorrent, without concern for overall bandwidth use, that's already done by the upstream router, using DD-WRT's stock implementation of the HFSC qdisc.

However, while this would let me prioritise my traffic over other people's, setting my whole LAN to "Express", or deprioritising everything behind the Fonera to "Bulk" does not seem like an ideal solution. The other purpose of QoS is to provide enough rate-limiting that I stay within my ISP's traffic management policies, and my upstream router doesn't do that. It just prioritises traffic, and assumes I will use schedulers and rate-limiting to avoid uploading or downloading too much at peak times. The same assumption can't be made for third parties and so I want a level of QoS on the Fonera that I don't require on the upstream router.

My Internet connection (Virgin Media) is notionally 10Mbit down and 512kbit up (restricted to 384kbit by QoS at the upstream router), but it comes with a traffic management policy that says that my total downloads must not exceed 3000MB from 10am to 3pm plus 1500MB from 4pm to 9pm, and that my total uploads must not exceed 800MB between 3pm and 8pm. If they do, my connection gets "graced" to 25% of the usual speed for five hours. So, we want to keep the total average transfer rate on my connection inside 80KB/sec down and 40KB/sec up (that's in kiloBYTES) during the peak 3pm - 9pm; we want to keep downloads below an average of 170KB/sec from 10am to 3pm, and outside of that, do what you like as long as it doesn't bugger up my connection.

[edit] How do we translate that into QoS terms?

[edit] Downstream

The original Fonera provides for 512kbit of downstream; but I don't have a 2Mbit connection any more. Over night, I'm happy to let FON users have at least 2Mbit, the equivalent of a basic ADSL connection; this should probably come down to 1Mbit during the daytime peak and 512kbit during the evening peak.

[edit] Upstream

We have a maximum available upstream of 384kbit/sec, given the QoS at the upstream router; it seems reasonable to limit hotspot users to 256kbit/sec upstream bandwidth all of the time, and maybe drop this to 192kbit/sec or 128kbit/sec at peak times. I say maybe, because a majority of hotspot users won't even be trying to use p2p and it seems excessive to rate-limit uploads to 16KB/sec when someone's uploading a photo to Flickr or the like. One wonders if we can rate-limit uploads but use a large burst size, to cater to precisely that scenario; let the first couple of megabytes go through fast, then rate-limit heavily.

[edit] Extending WiFi range

The Fonera 2100 has a maximum transmit power of 63mW (18dBm) and a replaceable 2dB antenna, which provides the maximum UK legal EIRP of 20dBm and the typical range of a stock wireless device. At best, it's accessible from two or three houses away, which isn't that great.

[edit] Extending the WiFi range of the Fonera

After a read of this article on receive sensitivity, power levels and antenna gain, we can perhaps extend the range of the Fonera itself - while remaining within legal limits - by increasing the antenna gain and reducing transmit power as described in the article. This will vary from situation to situation; some users may require vertical reach which militates against a long-range omnidirectional antenna, for others it may be a useful solution.

[edit] Adding additional routers

[edit] WDS / repeaters

Adding more routers via WDS means putting restrictions on the speeds, routers, chipsets and encryption that we use; it's not the right tool for the job. Similarly, any form of repeating the wireless signal is limited to the type, nature, frequency and encryption of the original, so we'd have to dedicate the hardware to that job alone.

[edit] Virtual APs over EoIP

Now, here's where DD-WRT comes into its own... if you've gone to the trouble of reflashing your Fonera with DD-WRT in order to continue to use it to provide a FON spot, presumably you're also running DD-WRT on at least one other router. If so, you can configure a virtual wireless access point on that router, unbridge it, and add it to a separate bridge containing just the VAP and an EoIP tunnel pointing at your Fonera. Meanwhile, on the Fonera, create the other end of your EoIP tunnel, unbridge it, and add it to the Chillispot bridge along with ath0.

Done correctly, a client connecting wirelessly to the virtual access point is bridged (over an EoIP tunnel across the wired network) to the Fonera, where it gets bridged onto Chillispot for DHCP. authentication & access control. tunnelled from Chillispot through firewalling and QoS, out onto the LAN bridge of the Fonera and through the gateway to the wider Internet. That is every bit as convoluted as it sounds, but current status is Works For Me.