Tag Archives: coovachilli

Captive Portals & Brighton

Yesterday I gave a talk at SANE user group on my history with wireless networks as part of the PierToPier.net project in Brighton (now defunct) and my experimentation with captive portal software which I began revisiting this time last year. I thought it would be a good opportunity to develop my programming skills by tidying up and modernising parts of the codebase which caused problems, such as things preventing builds on a modern system with clang which is now the default compiler for FreeBSD on i386/AMD64 architectures and OS X. The slides from my talk can be found here.

IMG_3248

Back in the early to mid 2000’s there were 2 initiatives to provide public access wifi in Brighton. Loose Connection and PierToPier.net, each had a different focus & approach.
Loose Connection was a commercial venture which could be deemed a VAR, they resold a ADSL connection along with a draytek router & that was it. Individual wireless networks with the loose connection SSID dotted around drinking holes in Brighton, the founding(?) company Metranet lives on as a WISP today.
PierToPier.net was a community driven effort with a technical team of volunteers, predominantly from a service provider / telecoms / networking background. Each node on the network was sponsored by a host who’d buy and run the equipment while the project members managed it.

The project started off based around the fanless VIA mini-itx boards, Prism2 chipset wireless cards, booting linux with hostapd and nocatauth/nocatsplash off a CF card in a IDE to CF adapter.
This was a very flexible platform, if there was no package for it you could build it with ease, problem was that it had a high cost for entry, £250 to £300? so from the start we were looking to reduce costs.
The other issue was though we’d eliminated moving parts, the casing was not suitable for outdoor use.

With the availability of 3rd party firmware and promotional sales of the WRT54G, PierToPier switched hardware platforms as the low cost solution for new nodes.
Tom Grifiths discovered Chillispot around the same time frame and we adopted it due to enhanced functionality it provided, such as RADIUS accounting and working captive portal. We’d previously ran into issues with browser support running nocatauth which by that point was no longer maintained and stability issues with nocatsplash.

Glastonbury 2005
VIA motherboard again this time with CF adapter & mini-pci slot onboard
2x Atheros A/B/G mini-pci cards, one on mini-pci to PCI bridges and second onboard
Stuck to a pelican case with epoxy
Two holes drilled in the side of the case for external antennas

It was early times for support of the cards and the wireless standards. In this era OpenBSD was leading the way in terms of support of hardware and development of their ieee80211 wifi stack, they were the first to reverse engineer the Atheros binary blob HAL (years before anyone?) but late to the game for the 802.11g, 11a was enabled from the start but didn’t appear to work – bringing the interface up in .11a hostap mode wouldn’t necessarily work.
Looking at alternatives there was a short lived live environment named WifiBSD which was based around FreeBSD but later moved to NetBSD before development ceased. The support for the Atheros cards was not as good as OpenBSD, hence not wasn’t much use.

The hardware for the Glastonbury nodes were truly terrible, all functionality had been wired to a single bus which caused the system to lock hard in most configurations. e.g. you booted from a CF card and tried to bring up a wireless interface. The only way to use the system was to disable everything that wasn’t needed in the BIOS including VGA, if there was an issue, you’d have to factory reset the BIOS before diagnosing.

For the wireless network at Glastonbury, the 11a 5GHz network was used as the backhaul while the 11b/g interface was used for connecting wireless clients. No captive portal, connect to the AP & off you go.

We arrived onsite on Tuesday, starting getting things running, Thursday morning the rain and lightning started things went downhill from there. loss of connectivity between the backhaul links meant things fell apart.

By the time we’d discovered Chillipot the project had a 1.0 release out which had preliminary support for FreeBSD. The website claimed only FreeBSD 5 and up were supported, I created a port and submitted it for inclusion in the tree, net-mgmt/chillispot was born, Edwin@ from the ports team fixed the code so that it’d work on previous releases. I then moved onto creating a OpenBSD port, this was slightly harder and the final peace was actually resolved by a Steve Davies. I got the code to build on OpenBSD but networking wouldn’t work. This turned out to be because an additional 4 bytes needed to be allocated which Steve fixed. It never made it into the OpenBSD tree (only tested it on i386 and SPARC, it used strcpy() everywhere and didn’t run on SPARC) but it can be found in ports-wip. I then moved onto creating a live CD environment based on FreeBSD 6 using freesbie for advocacy purposes named BrightonChilli. The idea was to remove the hurdle of going through the installation process and provided an environment that just needed the configuration of network interfaces and chillispot. A person with previous experience of running chillispot would be familiar and a new user would not be too out of place.
This was in the days of X configuration being a part of sysinstall which could hang if Xconfigure was run and you’d have to start the install process again as the install was incomplete (for a newcomer). I was interviewed on BSDtalk #73 regarding BrightonChilli.

PierToPier also produced its own Linux image named Muddy Linux targeted for x86 hardware that ran the necessary stack to serve as a node on the network.
After Chillispot 1.1.0, the project went quiet, there was no answer from the founding developer for quite a while and eventually the web hosting stopped and the domain expired.
The community rehomed to coova.org and development continued in Coovachilli which was founded by David Bird, a contributor to Chillispot.
Coovachilli initially lacked support for FreeBSD but it was eventually added in by David and net-mgmt/coovachilli was born in ports. Not much else was done after that until a year ago. With FreeBSD 10 and the switch to clang, the codebase needed attention, first step was to get it to build correctly with GCC. The use of error_t from glibc caused the build to fail as it’s not available in FreeBSD, ensuring this was declared allowed the build to complete successfully. To resolve build issues with clang, nested functions were separated out. Any function with missing prototypes & parameter lists were addressed next.
struct ifreq had been marked as deprecated since 2000 and was finally removed in FreeBSD 10. The *BSD specific sections of Coova were switched out to the new struct ifaliasreq & Linux was left to use the pre-existing method. There was extensive use of macros for the logging functionality, these were dropped in favour of using the existing standard syslog(3) with the correct log level defined. This had the benefit of revealing issues which were not detected previously such as incorrect format specifiers.
There are still many things that need to be cleared up, the 3rd party functions added in are particularly problematic and will probably be my next task to replace with standard components.
CoovaChilli & Chillisport have seen large scale deployments thanks to use by Fon, o2 and Google which now owns Coova.

IMG_3250

Building CoovaChilli on FreeBSD 10 & newer

I’ve been working on getting CoovaChilli running on FreeBSD 10 the past few weeks. The first problem was that the source code would not build. FreeBSD 10 shipped with clang instead of GCC as the default compiler which is not as forgiving as GCC, clang flagged up lots of issues with the code base such as lack of parameters for functions, one change needed which was a shortcoming of clang itself was the lack of support for nested functions.
The other problem was that CoovaChilli was using a structure that had been marked as deprecated in Net/Free/OpenBSD/Darwin for quite some time & with the release of 10.0, FreeBSD removed this structure from their codebase. This resulted in the tun(4) interface being initialised but no IP address being assigned to it, which was interesting, dhcp responses were still going out but obviously nothing could talk back to the IP address that coova was configured to be listening on (uamlisten).

All BSDs & derivatives were separated out from Linux in dev_set_address(), Linux was set to use the pre-existing method & the BSD & derivatives were switch to use the “new” ifaliasreq structure.

With these change, it’s possible for a client connected to a router running CoovaChilli to visit sites listed in uamallowed. These are sites which CoovaChilli allows to be browsed without needing authentication through the captive portal first. Next stage is to get the captive portal running along with a RADIUS server so that the previous revision of the setup guide can be updated. With the release of FreeRADIUS 3 configuration has changed somewhat, hence the old documentation for version 2 doesn’t necessarily apply.

These changes so far only allow the code to build without any features enabled, for example, enabling OpenSSL support yielded more errors which have not been fixed yet & I suspect others will show up as more options are switched on.

The work so far can be found here

Merged 3/6/2014

CoovaChilli for FreeBSD

I’ve created a long overdue port of CoovaChilli for FreeBSD, this should be considered as a work in progress for a couple of reasons:
1) As the current stable release v1.0.11 doesn’t build on the BSD’s the port installs a SVN checkout of build 152 which resolves build issues with FreeBSD
2) this is a result of a couple of hours of faffing around due to me being a bit rusty, the port definitely installs & uninstalls cleanly
but doesn’t install things in the right place as far as where things should live in the BSD userland e.g the www files are installed in {PREFIX}/etc/chilli/www which is wrong + some others bits.
3) The port doesn’t include any of additional docs/configs which where included with the chillispot port, eg a PF config.
4) No testing has been done apart from the fact that it builds correctly

You can grab a copy of the port here
copy the file to /usr/ports/net-mgmt
& uncompress

Update:
Small change, the correct location of the localstate directory (/var) is passed onto configure, redownload the file if you grabbed a copy previously.