26 November 2016Own project · NetworksOwn post

Freifunk in Meerane: my own Gluon site, my own gateways and why I shut it down

Summary

From 2015 to 2016 I ran a small Freifunk network in Meerane, with my own Gluon firmware, two gateways of my own and signed updates for the routers. In the end there were six to ten access points with up to ten users per device on a daily average, too few for the effort, and I discontinued the project. This post shows what a Gluon site defines, how mine was built, why the traffic went through a paid VPN back then and what has changed in Gluon and in the law since.

Freifunk and Gluon

Freifunk (German for “free radio”) is the idea of building a free Wi-Fi network from many small routers set up by citizens, associations and shops. The routers connect to each other by radio to form a mesh and via VPN over the internet to gateways through which traffic reaches the internet. Whoever sets up a router shares part of their bandwidth without opening their own home network.

Most communities build the firmware for this with Gluon, a framework based on OpenWrt. Gluon itself is neutral; what defines a network is in the site configuration: network name, radio channels, address ranges, the gateways, the path for automatic updates and the texts of the setup wizard. Gluon plus site produce a ready image for every supported router model.

A zone of my own under freifunk.net

Technically the network began with its own DNS space. I created the zone meerane.freifunk.net on two name servers of my own in different networks, and on 18 June 2015 freifunk.net delegated it there via NS records. This put the names for gateways, firmware mirror and services under my control, and I could change records without involving the umbrella organisation each time.

My site

I built and ran the network on my own. My first routers still ran an earlier firmware of mine under the short name ffmee. The new site took them over: a legacy section in the configuration made sure that when updating to my firmware, the old configuration files and VPN profiles were recognised and migrated instead of me having to set up every router again.

The radio side was typical for the time: an open network for users on 2.4 GHz channel 11 and on 5 GHz channel 44, alongside an ad-hoc network (IBSS) for the mesh between routers, on which batman-adv found the routes. Clients got a private IPv4 network with 4,096 addresses and an IPv6 prefix from the range for local addresses. Filters for multicast and for foreign router advertisements and DHCP replies kept the shared network quiet, and a fixed next-node address always reached the router you were currently connected to.

The most important part was the mesh VPN. Every router used fastd to build a tunnel to at most two gateways, encrypted with salsa2012+umac and an MTU of 1406 bytes. An excerpt, without keys and addresses:

fastd_mesh_vpn = {
        methods = {'salsa2012+umac'},
        configurable = true,
        mtu = 1406,
        groups = {
                backbone = {
                        limit = 2,
                        peers = {
                                cbbvpn10 = { key = '…', remotes = { … } },
                                cbbvpn20 = { key = '…', remotes = { … } },
                        },
                },
        },
},

For a router to be allowed into the VPN at all, the setup wizard showed its public fastd key, and I added it on the gateways. In the same wizard the person setting it up entered location and contact details. With the coordinates the node appeared on my node map, and the contact made it possible to reach its operator.

Updates with my own signature

Nobody wants to update routers hanging in other people’s premises one by one. Gluon comes with an autoupdater for this: every router regularly asks a server for a manifest of the latest images and only installs a new one if the manifest is signed with one of the configured keys. My site listed exactly one key, mine, and one valid signature was enough. The keys are created and checked with ecdsautils, signing is done by a script that comes with Gluon.

My build script from 26 November 2016 shows the whole process in a few lines, slightly shortened here:

#!/bin/sh
cd gluon
make dirclean
export GLUON_TARGET=ar71xx-generic
export GLUON_BRANCH=stable
export GLUON_RELEASE=2016112601
git pull
(cd site && git pull)
make update
make clean
make -j8 V=s
make manifest
./contrib/sign.sh ../signaturschluessel.sec output/images/sysupgrade/stable.manifest

The build targeted ar71xx, the platform of the cheap TP-Link routers with Atheros chips at the time. I have replaced the name of the key file here. And this is where a small Freifunk site is vulnerable: whoever holds the private key can push any firmware to every router in the network. It belongs offline, and several signatures from different people are safer than one.

Why traffic went through a VPN

My two gateways did not send traffic straight to the internet but through a commercial VPN provider that I paid in Bitcoin at the time. The reason was German Störerhaftung (secondary liability): whoever ran an open Wi-Fi could be held liable to cease and desist and receive warning letters for legal violations by their users, typically file sharing. Many Freifunk communities therefore routed their traffic through VPN providers abroad or through their own provider structures, so that the connection of a router operator did not appear in the warning letters.

The legal situation changed exactly while I was running the network. On 21 July 2016 an amendment to the German Telemedia Act clarified that Wi-Fi providers also enjoy the provider privilege, but left the secondary liability itself untouched in the text of the law. In September 2016 the European Court of Justice ruled in the McFadden case that injunctions remain possible. Secondary liability for Wi-Fi operators was only abolished with the amendment that came into force on 13 October 2017.

Usage and the end

As far as I remember, the network in the end consisted of two gateways and six to ten access points. Three of them were in a restaurant and bar, a TP-Link TL-WA901N/ND, a TL-WR1043N/ND and a TL-WR741N/ND, spread over several rooms. On a daily average there were up to ten users per access point.

For a network run by one person, that is too little. The gateways had to run and be updated, the VPN cost money, every new Gluon version meant building, testing, signing and rolling out, and new routers had to be added to the VPN. Freifunk lives from many people taking part and sharing the work; in a small town with few locations this critical mass never came together. So I discontinued the project. The last build in my project folder dates from 26 November 2016.

One thing I forgot: to hand back the DNS delegation. The NS records at freifunk.net stayed in place for years. As late as May 2022, more than five years after the last build, they still pointed to my servers, although my first name server only returned empty answers for the zone and no name server was running on the second one any more, a classic lame delegation. Today it has been removed; the freifunk.net name servers no longer have any entries of their own for meerane.freifunk.net. Orphaned delegations like this are more than cosmetic: if one of the name server domains ever expires and someone else registers it, they can answer for the whole subzone.

What has changed since

Platform: the current Gluon documentation no longer knows ar71xx; Atheros routers now run as ath79.
Mesh: instead of ad-hoc networks (IBSS), Gluon now uses 802.11s as the basis for the mesh between routers.
VPN: fastd still exists, alongside WireGuard with VXLAN. Tunneldigger is marked as deprecated.
Devices: none of my three router types is still on the device list. For the TL-WR1043N/ND only version 2 onwards is listed, and devices with 4 MB of flash such as the TL-WR741N/ND are too small for today’s firmware.
Law: since October 2017 secondary liability for Wi-Fi operators has been abolished in Germany. The costly detour via a VPN is no longer a must for an open Wi-Fi, but many Freifunk networks keep it to separate router operators from users.

What you can take away

A community network is above all a social project. Plan the work for gateways, updates and support so that it fits on several shoulders before you build the technology.
Rather join an existing Freifunk community nearby than run your own site. Their gateways and updates also carry individual routers.
Keep firmware signing keys offline and require several signatures.
Plan generously with router flash: devices with 4 MB are the first to drop out of support.
When shutting down a project, also hand back DNS delegations, domains and accounts, not just the servers.

Numbers at a glance

freifunk.net delegated the zone meerane.freifunk.net on 18 June 2015; today the delegation has been removed.
The site used batman-adv in compatibility mode 15 and fastd with salsa2012+umac at an MTU of 1406 bytes.
Every router connected to at most two of the gateways (limit = 2).
The autoupdater only accepted manifests with a valid signature of the configured key.
The Telemedia Act amendment of 21 July 2016 put Wi-Fi providers under the provider privilege; secondary liability only fell with the amendment of 13 October 2017.
The current Gluon documentation lists Atheros routers under ath79 and offers WireGuard with VXLAN as mesh VPN.

References

Remarks

This is based on my project folder with site configuration, build script and node list, a DNS query of 7 November 2026 and my memory of the numbers; operating statistics have not survived. I leave out addresses, keys and locations, and I deliberately do not name the restaurant where the routers hung.

Read the Gluon documentation