Freifunk: Technik der Gateways

Ich hatte mich im Vorfeld etwas schlau gemacht, wo die Freifunk-Firmware denn heute steht — als ich seinerzeit guckte, war die Teilnahme noch kompliziert, denn man mußte sich manuell Knoten-IP-Adressen geben lassen, und wenn man ein Internet-Gateway anbieten wollte, mußte man selber dafür sorgen, daß die Zugriffe nicht auf den eigenen Internetanschluß zurückzuverfolgen waren (oder einen guten Anwalt haben, Stichwort »Störerhaftung«). Das ist heute deutlich komfortabler und ausgereifter.

Stand der Dinge scheint derzeit die von den Lübeckern entwickelte »Gluon«-Firmware zu sein. Diese setzt, klar, auf OpenWRT auf, anders als die älteren Ansätze z. B. in Berlin, wird dort aber nicht in der Wolke per OLSR geroutet, sondern jeder Knoten mit Internetanschluß wird per Tunnel an einen virtuellen Switch angebunden. Knoten ohne Internetzugang dienen zur Vergrößerung der Reichweite des Netzwerkes, ihre Clients (Endgeräte) werden dann zum netztopologisch nächsten Knoten mit Internetzugang geroutet. Das Ganze regelt sich selbst, dank batman-adv …

Die Kollegen von Köln, Bonn und Umgebung (KBU) haben das ausführlich beschrieben — ich rate dazu, sich das vor dem Versuch des Aufsetzens durchzulesen, spart ggf. den ein oder anderen Rückschritt :-)

Da die Paderborner Kollegen ebenfalls auf dieser Basis ihr Netz aufgesetzt haben, fiel die Entscheidung für Gütersloh pro Gluon aus — auch die Fähigkeit des automatischen Firmwareupdates sollte man auch nicht unterschätzen.

Die Frankfurter haben im Wiki eine Checkliste hinterlegt, was bei der Vorbereitung der eigenen Technik beachtet werden sollte. Denn: die Aufbauphase ist ein Henne-Ei-Pro­blem — zum Start nutzt man – nach Absprache – ggf. die Firmware (und damit Infrastruktur) einer Nachbarcommunity mit der eigenen SSID, weil der Aufbau eigener Gateways (virtuelle) Server benötigt, die i. d. R. Geld kosten. Dazu kommt noch der VPN-Tunnel nach Schweden oder Holland, damit die Störerhaftung nicht greift; aber auch VPN-Provider wollen bezahlt werden. Ergo: ohne Nutzer entstehen nur Kosten, ggf. gar langfristige.
Aber irgendwann ist man hoffentlich groß genug, daß man eigene Server aufbaut — dann sollte das Umschalten in der eigenen Hand, sprich dem selbst kontrollierten DNS, liegen. Denn Firmwareupdates sind immer ein potentielles Problem, und man möchte nicht jede interne Änderung in ein neues Firmwareimage münden lassen müssen.

Gateway

Einige machen die Unterscheidung zwischen Gateway und »Super-Node«; derzeit machen wir das für Gütersloh nicht, jedes Gateway bietet auch (über Tunnel), eine Internetanbindung an. Eine Kopplung mit anderen Freifunkwolken findet aktuell nicht statt, das ist auf einen späteren Zeitpunkt vertagt; inwiefern wir dann Gateways klassifizieren, ist noch nicht entschieden. Untereinander sind die Gateways in Gütersloh der Einfachheit halber auch per fastd, statt per OpenVPN oder TINC, verbunden.

Die grundlegenden Pro­gramme/Tech­no­logien für ein Gluon-Gate­way sind: fastd (Tun­nel­dae­mon), bat­man_adv und batctl (B.A.T.M.A.N. ad­van­ced), radvd (IPv6-Adress­ver­gabe), OpenVPN (Tun­nel­dae­mon für IPv4-Stö­rer­haf­tungs­um­geh­ung) und dns­masq (DNS- und DHCP-Server) in­stal­lier­en und kon­fi­gu­rier­en. (In den Bei­spiel­en wird i. d. R. der ISC-DHCP-Server in­stal­liert sowie BIND — und dns­masq; da wir aber nur einen DHCP-Ser­ver und ein biß­chen DNS-Tricks­er­ei be­nötigen, halte ich dnsmasq für beides für aus­reich­end.) Für das sog. »Inter-City VPN« kommen dann noch tinc (Tun­nel­dae­mon) und bird (Rou­ting­dae­mon) hinzu …

fastd ist der Dreh- und Angelpunkt in den aktuellen, batman-adv-basierten Setups: Auf jedem Gateway läuft er, jeder Freifunk-Knoten mit Internet-Uplink verbindet sich über fastd mit den Gateways (typischerweise limitiert auf maximal zwei gleichzeitig); dies bildet, unterstützt durch batman-adv, einen großen, virtuellen Switch in der Wolke. Für den Nutzer als auch für Linux ist ffXX-mesh-vpn ein großer Switch. Per batman-adv weiß dieser, welches Gerät über welche Netzwerkverbindungen erreichbar ist.

B.A.D.M.A.N. Advanced

Ja, das ist am Anfang ggf. etwas verwirrend; batman-adv bildet das Maschennetzwerk eben auf ISO-Ebene 2, dem Transport-Layer. Im alten, OLSR-basierten, Ansatz mußte jeder Knoten jede IPv4-Route (sprich: ISO-Ebene 3) im Netz kennen und aufgrund von per aktiver Netzmessung neuberechneten Qualitätsmerkmalen laufend neu bewerten. Typischerweise stieß dieses, insbesondere auf den schwachen CPUs der Router, schnell an Grenzen — an dieser Stelle setzt eben a »better approach to mobile ad-hoc networking«, kurz: B.A.T.M.A.N., an.
Wie das konkret funktioniert, da muß ich dann auch passen (naja, grob, denke ich, weiß ich es, es werden Kontrollpakete über die Verbindungen geschickt, Antwortpakete ausgewertet und darüber Verbindungsgraphen erstellt); faktisch »weiß« badman-adv aber, wie es im aktuellen Netz am besten von Gerät A zu Gerät B kommen kann. Das geschieht auf auf Basis der MAC-Adresse; das Hilfsprogramm »batctl« bietet aber die von Layer-3-Protokollen wie IP gewohnten Methoden »ping« und »traceroute« an:

root@gw04:~# batctl tr f8:d1:11:bd:5e:24
traceroute to f8:d1:11:bd:5e:24 (fa:d1:11:bd:5e:24), 50 hops max, 20 byte packets
 1: ea:94:f6:52:4b:54  29.372 ms  29.748 ms  29.365 ms
 2: fa:d1:11:bd:5e:24  33.291 ms  32.282 ms  30.777 ms

(fa:d1:11:bd:5e:24 ist mein Testknoten, der nur per WiFi an freifunk-e894f6524b54 angeschlossen ist; da jeder Knoten zu jedem der aktuell 2 Gateways eine Verbindung haben sollte, ist dieser Trace, auf Layer 2, unspektakulär.)

Screenshot

Unser noch kleines, vermaschtes Netzwerk, visualisiert.

Und weil das so ist, wie es ist, nämlich ziemlich undurchsichtig einfach »unter der Haube« passiert, möchte man das gerne visualisieren. Kann man auch, allerdings wurde diese Funktionalität aus dem badman-adv-Kernelmodul jüngst entfernt und in »alfred« (»Almighty Lightweight Fact Remote Exchange Daemon«) bzw. »batadv-vis« verlagert. Und so lustig die Akronyme auch gewählt sind: wer danach googelt, landet ganz woanders …

Kurzum: heute laufen auf den Freifunk-Knoten die Daemons »alfred« und »batadv-vis«, letzterer im Servermodus, neben dem Kernelmodul batman-adv. Irgendwo im Freifunknetz, sprich auf einem Gateway, sollte dann ein alfred-Master laufen, der die Daten, die die Freifunkknoten minütlich senden (Uptime, Durchsatz, Firmwareversion, GPS-Angaben, …), empfängt und abfragbar macht.

IPv4 Routing

Ein Freifunknetz nach diesem Muster operiert normalerweise auf Basis eines /16, also z. B. 10.0.0.0/16. Jedes Gateway vergibt Adressen aus einem virtuellen /24, bedient also max. 253 Clients, vergibt diese Adressen aber mit einer Netzmaske /16. Daher kann ein Gateway auch ohne Internetzugang funktionieren, indem es z. B. von 10.1.0.2 bis 10.1.0.254 vergibt, als Gateway aber 10.2.0.1 nennt. Auch das ist latent tricky, sollte man sich verinnerlichen, daß, und warum, das so funktioniert. Und auch sollte man sich im Vorfeld überlegen, ob man ggf. mehr als 253 Clients per Gateway bearbeitet werden sollte — falls ja, sollte man keine virtuellen /24 per Gateway vergeben sondern eher /23 (gut 500 Adressen/Gateway), die sich natürlich nicht mit den Bereichen für andere Gateways überschneiden dürfen.

Unklar ist mir denn auch, was passiert, wenn z. B. GW01 keine freien IPs mehr hat, wird dann ein Client von GW02 bedient, auch wenn GW01 das nächste Gateway ist? Aber das ist wohl ein Luxusproblem, 200+ Clients wären ja schon schön ;)