This is the first in a series of articles describing one possible setup of temporary Wi-Fi service for users at a remote location where more conventional means of Internet access are unreliable or unavailable.
Every year in June I go camping in northern New Hampshire with 1,000 or more of my closest friends. Unfortunately for them, decent Internet service is rather difficult to get in the north country. There is almost no mobile phone service to speak of, unless you are with the one carrier that actually introduced 4G service in the area in 2013. The campground’s own paid Wi-Fi service appears to be on a creaky old T1 line with 1.5 megabits of bandwidth; it’s wholly inadequate to serve even dozens of people.
What to do, what to do? If you said “Set up temporary Wi-Fi service and undercut the competition” then give yourself a cookie.
But how do you set up temporary Wi-Fi service? If your first thought was “Call Cisco or Ubiquiti and order a whole bunch of hardware” then stop trying to think. That’s just too expensive for something that runs one week a year. There’s no way to recoup the investment in a reasonable timeframe. For this, something a little less enterprisey is called for. A lot less, actually.
In the future I’ll go over all the details of how to construct the service. But for now, this is generally how I built it:
First, there was the problem of actually getting Internet service to the campground. This was solved with a fixed wireless link, but for various reasons I am not at liberty to name the vendor or go into further technical detail. Suffice it to say that I had at least 10 megabits per second down and 5 megabits up to work with.
Next, there was the problem of providing the Wi-Fi itself. When I first did this last year, I took an off-the-shelf home router literally right off my desk, bought the highest gain outdoor omnidirectional antenna I could find on eBay, and set it up as an AP with OpenWrt. This worked well but didn’t cover that much of the campground. This year I added a second home router as an AP, also with an external antenna, and set them up for WDS, to provide spot coverage at one of the more heavily-trafficked areas. Unfortunately this didn’t work in the lab due to an apparent Linux kernel bug, so at the last minute I undid WDS and added a third wireless router (that I dug out of my junkbox) as a client to provide wireless backhaul to the first router, and wired it to the second AP.
Then there was the issue of making money from this. I evaluated a number of captive portal solutions before the first setup last year, and almost went with PacketFence, but it did not have support for OpenWrt at the time, and still does not have support for taking Bitcoin payments. In the end I hacked together my own Bitcoin-accepting captive portal from scratch. It currently weighs in at just over 500 lines of PHP code (not counting various libraries that it uses). Perhaps half of that number is actually HTML markup rather than code.
But because this is a security-conscious crowd, some more work was required. I set up the wireless APs to use multiple SSIDs. The first is an open SSID which anyone can connect to and be redirected to the captive portal, which uses HTTPS. Once signed up and paid, they then switch to the other SSID, which uses 802.1x EAP and authenticates them against a FreeRADIUS server, which the captive portal controls. This setup keeps all aspects of the network reasonably secure from wireless sniffing on-site, which, given the nature of the event, can reasonably be expected to happen. It worked well for most users, but pre-Windows 8 and Linux computers needed significant configuration changes to work with it, so there was some high-touch end user support.
I also thought it necessary to keep the traffic reasonably secure from the nameless fixed wireless provider, especially in light of the Snowden revelations, which had just begun to be published a few weeks before the first time I set this up. To do this I obtained a VPS from Digital Ocean, and ran OpenVPN over the link, with freshly generated certificates each year. This, of course, does not keep the traffic safe from them, but it does make things much more difficult with dozens of people exiting at the same endpoint.
One performance optimization I put in place was to use squid as an intercepting proxy to cache HTTP content. HTTPS content is not intercepted, as I cannot really install CA certificates on random people’s devices to implement SSL bump, and it raises too many privacy issues anyway. Unfortunately, with so many popular web sites having moved to HTTPS, this doesn’t help as much as it could. It’s still useful enough to keep, though, as perhaps 20% of the total bandwidth used was served from the cache.
In the first year, having coverage of less than 10% of the campground, only 42 users signed up, but as a trial balloon it floated well. This year, with two hotspots available, 90 users signed up, about half of them paying in Bitcoin, plus a special arrangement with Free Talk Live to provide Internet access for the equipment for several radio shows and podcasts which were recording or broadcasting live from the event.
There were a number of issues to be resolved over the course of each week, such as the fixed wireless link dropping, or OpenVPN dropping and logging potential replay attacks, all the way to significant radio interference which required changing the channels of all the wireless devices. There were also a couple of hours where the available bandwidth appeared completely saturated, as well as spam and DMCA complaints to deal with. I will also describe these in detail at a later date.
Overall, despite the issues, it was fun and rewarding to help my old and new friends get online in the middle of nowhere. I made enough money to pay for all of my expenses for the service, and for my vacation, and had some left over. Next year I plan to expand it even further. Eventually all the mobile phone carriers will service the area and then there won’t be much of a market for it, but that will likely be many years away.