Orginaler Blog-Post: Freifunk nach dem Hype: Gluon »multidomain« – Freifunk Kreis GT
Mit der Version »v2018.1«, die im Juli 2018 das Licht der Welt erblickte, brachte »Gluon«, das viel verwendete Freifunk-Firmware-Framework, ein überfälliges Feature: »multidomain«.
Freifunk-Netze sind … anders. Einerseits möchte man eine große Flächendeckung, andererseits dem Dezentralitätsprinzip folgen, siehe Freifunk-Vision:
Wir verstehen frei als
- öffentlich und anonym zugänglich
- nicht kommerziell und unzensiert
- im Besitz einer Gemeinschaft und dezentral organisiert
Das mit dem »dezentral organisiert« ist allerdings so ein Punkt, wo technische Spezifikation und Freifunk-Ideologie in den Ring steigen und die Sache »ausdiskutieren« müssen. Ich will gar nicht zu sehr in die Technik abtauchen, nur soviel: Ein Funknetz, welches eine Kennung »Funknetz_von_Anbieter_X« ausstrahlt, muß aufgrund technischer Gegebenheiten alle Zugangspunkte »hintenrum« in einem Netz haben — oder, anders gesagt: Es funktionierte aufgrund technischer Gegebenheiten nicht, ein stadtweites WLAN zu ermöglichen, indem einfach jeder WLAN-Router ein offenes WLAN »Gastzugang $Ort« offerierte.
Sprich: die dezentralen »Hotspots« brauchen ein zentralen Backhaul, und dies ist der Zeitpunkt, wo die Dezentralität der Ideologie auf die Zentralität der real existierenden Technik trifft.
Für einen traditionellen Provider, wie die Deutsche Telekom oder BiTel, ist es relativ einfach, alle seine Accesspoints technisch in einem Netz zu betreiben: sie legen/schalten dorthin Leitungen. Freifunker hingegen nutzen heute das Internet als Medium zur Zusammenschaltung: ein Knoten ist über Telekom, einer über Unitymedia, noch einer über BiTel angebunden. Ergo »bauen« Freifunker sich ein Overlay-Netz, aber miteinhergehend ist der Verlust der Dezentralität: dieses Overlay-Netz muß koordiniert gebaut und am Leben gehalten werden, was ohne ein gewisses Maß an Zentralität nicht geht.
Und damit kommen wir langsam zum neuen Feature »multidomain«. Dieses neue Feature ermöglicht es prinzipiell, daß die vorhandenen Mittel besser eingesetzt werden können: eine Gruppe kümmert sich um die Technik, mehrere lokale Gruppen kümmern sich darum, daß Knoten aufgestellt werden. Dies hat den Vorteil, daß vorhandene Ressourcen zielgerichtet eingesetzt werden können. Man kann die Idee vorantreiben, ohne die Technik bis auf das letzte Bit pro Datenpaket verstanden haben zu müssen; für letzteres verweist man auf »den Maschinenraum«.
Aber auch für größere Communities bietet es einen gravierenden Vorteil: dort wurde der Notwendigkeit lokal unterschiedlicher Konfigurationen meist dadurch begegnet, daß unzählige, sich nur in einer Handvoll Konfigurationsparameter unterscheidende, Firmwares produziert und bereitgestellt wurden.
Wir haben derlei schon »damals«, kurz nach der »für Rheda-Wiedenbrück brauchen wir Sonderlocken«-Firmware, eine Absage erteilt; das war im Mai 2015. Seitdem haben die Meshes im Kreis Gütersloh, in der Müritz-Region und, neuerdings, auch der Feldberger Seenlandschaft, eine einheitliche Firmware, die aufgrund der zu nennenden Geokoordinaten die entsprechenden Konfiguration ermittelt — recht ähnlich, wie dies seit Gluon v2018.1 mit dem »multidomain«-Feature möglich ist. (Technischer Unterschied: wir ersetzten die komplette site.conf; mit »multidomain« werden nur Teile der Konfiguration ausgetauscht.)
Diese Funktion erlaubte es uns unter anderem, für die aufstrebende Gruppe in Feldberg »virtuell eine eigene Firmware« zu nutzen — faktisch die Müritzer Einstellungen mit eigener SSID für AP und Mesh.
Die Erfahrungen mit unserer Lösung sind durchaus positiv, und so haben wir unsere neueste, auf Gluon v2018 basierende, Firmware auf »multidomain« angepaßt. Getreu dem Sprichwort, daß das Bessere der Feind des Guten sei: Eine zentral gepflegte Funktion ist einfach besser als ein eigener Hack 
Ein weiteres Szenario, daß durch »multidomain« ermöglicht wird: Sofern die Grundparameter des Meshroutings überstimmen (batman-adv v14 vs. v15; IBSS vs. 802.11s), könnte man einfach z. B. eine Firmware für andere Communities/Meshes erstellen. Sei es, weil dort sich eine neue Firmware aus $Gründen noch hinzieht, sei es, weil jene Community nicht mehr die Zeit/die Resourcen aufbringen kann oder will, eine eigene Firmware zu pflegen.
Letztlich ist es so auch einfach geworden, anderen Communities quasi als »technischer Dienstleister« unter die Arme zu greifen — im einfachsten Fall bedarf es nur einer kleinen Datei und eine neue Community kann in einen bestehenden Mesh mit zumindest eigener SSID mitlaufen.
Allerdings: mit »dezentral organisiert« hat das nicht mehr viel zu tun. Oder, auf eine gewisse Art, auch wieder, indem nun quasi jede Firmware für jedes Mesh konfiguriert werden kann.