Nachdem wir im letzten Jahr 2023 nach mehreren Beta-Versionen 0.16.x dann bei 0.16.5. schließlich sicher waren, den richtigen Kandidaten für das neue Stable-Release zu haben, sind wir vor etwa 7 Monaten auf die neue Stable 0.16.5 umgestiegen. Basis war hierbei die Gluon Version 2022.1.4.

Mitte 2023 hat Gluon an der ersten Version v2023.1.x gearbeitet. Das zugrunde liegende neue OpenWRT-Release wurde in vielen Bereichen grundlegend verändert. Das machte es nötig, dass auch Gluon viele alte Zöpfe abschneiden musste/konnte und viele Skripte und Funktionen neu programmieren musste.

Gluon 2023.1 war das erste Ergebnis dieser Arbeit und war die Basis für unsere erste Beta “0.17.0”. In der Probezeit wurden, wie immer, einige Issues/Probleme sichtbar und mit der Version 2023.1.1 gefixt, die Basis unserer Beta-Version 0.17.1 . Leider waren aber auch damit noch nicht alle Probleme beseitigt und wir mussten sogar einige Firmware-Builds zurückziehen, weil diese sonst zum “Einmauern” von Routern hätte führen können. Daher wurde auch 0.17.1 nie mehr als nur “Beta”.

Danach hat Gluon diese Woche mit 2023.2 einen weiteren großen Schritt getan, und wir freuen uns mit 0.17.2 nun ebenfalls eine neue Beta mit eben jenem Gluon-Stand anbieten zu können. Es sind damit auch wieder viele neue Routermodelle hinzugekommen, die von uns nun unterstützt werden. Wir würden uns sehr freuen, wenn möglichst viele von euch diese neu Beta ausprobieren würden und uns berichten, sofern Probleme auftreten.

Wie immer könnt Ihr das Update per ssh mit dem Befehl anstoßen:

autoupdater -f -b beta

Seit gestern gibt es bei uns eine neue Beta-Version unserer Gluon-Firmware.
Das neueste Gluon-Release behebt einige gravierende Probleme die in mehreren Communities mit Gluon Versionen ab v2022.1 zutage getreten sind. 
Die Details zu den Bugfixes könnt ihr hier nachlesen: gluon.readthedocs.io/en/latest/releases/v2022.1.3.html

Bei uns sind mir aber keine gravierenden Probleme bekannt geworden. Trotzdem wollen wir natürlich sobald wie möglich eine neue Stable-Version ausrollen. Daher bitte die aktuelle Beta bei euch testen.
Ihr könnt, wie gehabt, per SSH sehr bequem updaten. Der Befehl dazu lautet:

autoupdater -f -b beta

Alternativ geht es auch per Config-Mode und upload des passenden Images.

Wenn ich zeitnah keine Fehlermeldungen erhalte, werden wir die neue Beta-Firmware in der nächsten Woche als “stable” ausrollen.

Mit dem Update von 0.15.x auf 0.16.x (aktuell Beta und Release Candidate) haben wir die Möglichkeiten der Gluon-Tunnelsoftware “fastd” erweitert. Das ermöglicht nun mehr Datendurchsatz im Uplink auf Kosten fehlender Verschlüsselung.

Die von Gluon verwendete Basis für die Herstellung des Uplinks zu unseren Gateways ist bekanntlich fastd. Die Software bietet für unsere Zwecke entscheidende Vorteile gegenüber anderen Tunnelkonstrukten. Schließlich müssen Gateways z.T. einige hundert Tunnel zu verschiedenen FF-Routern gleichzeitig aufrechterhalten.

Einen Nachteil hat fastd jedoch auch. Der Durchsatz hängt stark von der verwendeten CPU ab. Schwächere Routermodelle schaffen es nur ca. 8-10 Mbit/s durch den Tunnel zu schaufeln. Stärkere Hardware schafft 24MBit/s. Das liegt daran, dass fastd für den Transport und das Managment der Pakete jeweils einen “Kontextwechsel” vom Kernelspace zum Userspace und zurück durchführen muss. Dabei muss das empfangene Paket mit dem individuellen Key des FF-Knotens entschlüsselt/verschlüsselt und dann weiterverarbeitet werden. Dieser Wechsel kostet erhebliche Rechenzeit (Takte).

Fastd hat mit der aktuellen Version V22 eine weitere Möglichkeit für den VPN-Tunnel zu unseren Gateways erhalten bei der man aber dann auf die Verschlüsselung der Pakete verzichtet. Dabei nutzt der FF-Router das nur im Kernelspace laufende Protokoll “l2tp”. Damit entfällt der Kontextwechsel im FF-Router für den VPN-Tunneltraffic. Mit einer Fritzbox4040 z.B. sind dabei dann Uplinks mit Transferraten von 120MBit und mehr möglich.

Wir werden jedoch nicht automatisch auf dieses Verfahren umsteigen, sondern es nur als neue Option anbieten, denn:
1. Belastet der “mehr Traffic” natürlich u.U. auch überproportional unsere Gateways und unsere Netzwerkverbindungen. Das wirkt sich dann wieder auf alle User aus, die dann u.U. doch wieder nur geringere Bandbreiten zur Verfügung haben.
2. Mag nicht jeder DSL-Anschlussinhaber, dass sein DSL-Anschluss alleine mit dem Freifunk-Router vollkommen ausgelastet ist und ihm damit selbst nur noch viel weniger Bandbreite in seinem heimischen Netzwerk zur Verfügung steht.
3. Wollen wir nicht als kostenlose Alternative in Konkurenz mit anderen Netzbetreibern stehen (fair use policy).

Wer jedoch unbedingt die neue Bandbreite benötigt und sich im klaren darüber ist, dass
1. die Daten unverschlüsselt zu uns gelangen
2. sein DSL-Anschluss u.U. nur mit dem Freifunk-Traffic schon komplett ausgelastet ist

kann das nun einstellen.

Dazu:
1. Update auf neue Beta durchführen mit
autoupdater -f -b beta
2. Zur neuen l2tp-Einstellung switchen mit
gluon-switch-domain ‘fftr_l2tp’

Danach macht der Router automatisch einen Neustart.
Das ganze ist dann für die Zukunft an dem Router auch updatefest.

Zurück zum Standard-Tunnel geht es wieder mit:
gluon-switch-domain ‘fftr’

Wir machen heute einen großen Schritt mit einer neuen Beta-Firmware. Nachdem die neue Gluon-Version 2022.1 am Dienstag raus kam, habe ich unsere site.config angepasst und eine Firmware für uns compiliert.

Es gibt (leider) einige sehr tiefgreifenden Änderungen bei Gluon.
Siehe: https://gluon.readthedocs.io/en/latest/releases/v2022.1.html

Unterbau von Gluon ist nun erstmalig das neue Openwrt-Release v22.03.0
Das bedeutet, wie schon vor 2 Jahren mehrfach angedroht, nun definitiv für einige Router leider das Ende des Supports. Weder RAM noch FLASH (oder gar gleich beides) sind bei den “Altlasten” in der Lage das neue OpenWRT  zu speichern oder zu betreiben.

Daher werden nun einige ältere FF-Router auf dem Stand 0.15.x “einfrieren”, da keine neuere Firmware mehr dafür auf unserem Server existiert.

Ich werde dort dann ggf noch neue Netzwerkkonfigurationen und sofern Scurity-patches für die alte Gluon-Version kommen, auch diese einpflegen. Dann werden die alten Geräte im ggfl auch in der Zukunft mal noch gesondert ein Update erfahren (sofern ich es dann noch compilieren kann). Allerdings machen die Gluon-Macher hier wenig Hoffnung, dass die sich nach EOL in 11/2022 da noch wirklich “kümmern” wollen.
ggfl. muss man daher als Betreiber alter Geräte also damit rechnen, dass neue Sicherheitslücken weder kommuniziert, noch behoben werden.
Ist also jetzt euer Risiko!

Als Trost kamen aber auch eine Menge neuer Geräte dazu, die im Budget-Segment jetzt als Alternative dienen können.

Weiterhin hat Gluon mit dem neuen openWRT auch eine neue Strategie für Updates bekommen.
Also: DSA subsystem ersetzt das OpenWrt swconfig
https://gluon.readthedocs.io/en/v2022.1.x/releases/v2022.1.html#system-reconfiguration

Alles was ihr bei euren Routern bisher umgefummelt habt und was bisher auch irgendwie update-fest war (z.B. Tausch von WAN und LAN-Ports am Switch) wird kaputt gehen.
Der Knoten führt nach dem Update auf 2022.1  und auch bei allen weiteren Updates ein “Tabula Rasa” durch. Alles an Einstellungen wird erst mal platt gemacht und nur “Dinge” aus der Site-Config und Geräte-Config werden ins neue Betriebssystem im Knoten eingepflegt.

Wer also z.B. einen Knoten betreibt, der LAN und WAN getauscht hat (war manchmal ganz praktisch um einen separaten eigenen Switch einzusparen), wird danach alles an Clients (also euer ganzes privates Netz) an den LAN-Ports plötzlich im FF hängen haben und der Uplink ist tot, weil der nach dem Update am WAN Port (blaue Buchse) erwartet wird.

Wer einen solchen Spezial-Config-Router betreibt, bitte also umkonfigurieren oder erst mal einen eigenen Switch davor hängen und dann auf die neue Firmware updaten.
Wenn Ihr sicher gehen wollt, dann macht ein manuelles  Update beim Router und konfiguriert euch das anschließend neu.
Um das in Zukunft auch wieder updatefest zu bekommen.
1. updaten auf 0.16.1
2. Per SSH auf Knoten gehen und in /etc/config/gluon tauschen der beiden Zeilen list role ‘uplink’   und  list role ‘client’
3. gluon-reconfigure
4. reboot oder service network restart

Alternativ natürlich auch wie immer mit UCI möglich.
Siehe: https://gluon.readthedocs.io/en/v2022.1.x/features/wired-mesh.html#wired-mesh-commandline

Nachdem wir mit Gluon auf dem neuesten Stand sind, haben wir jetzt auch nochmal an der Infrastruktur geschraubt. Seit ca. 2 Jahren bereits war unser IPv6 nur noch sporadisch existent. Das Problem lag dabei nicht bei uns, sondern an der übergeordneten defekten/wackeligen Infrastruktur in Berlin.
Wir haben in dieser Woche nun unser Global-IPv6-Prefix aus dem Freie-Netze-Pool heraus lösen können und announcen dieses Prefix jetzt in Eigenregie per BGP. Heute früh hat auch die Telekom unser Announcement akzeptiert und sind nun wieder komplett auch inbound per IPv6 erreichbar.
Zusätzlich haben wir bei der Gelegenheit auch einen weiteren Uplink ins Internet in Betrieb genommen. Damit konnten wir die Redundant unserer Internetanbindung deutlich verbessern und selbst ein Totalausfall in Berlin könnte uns nicht mehr stoppen.
Auch die Gesamtbandbreite unseres Traffics hat sich damit nochmals deutlich erhöht. Ich könnt also jetzt wieder jede Menge neue Router aufstellen!

Vor ca. einem Jahr hat unser Netz einen größeren Umbau erfahren. Damals sind wir vom Funkstandard IBSS auf 802.11s umgestiegen. Die Umstellung erforderte einiges an Vorbereitung und Strategie, um keine unserer Geräte im Netz zu “verlieren”.
Im wesentlichen hat die Umstellung sehr gut funktioniert. Wir konnten bereits mit dem Stable-Update im Herbst die letzten “alten Zöpfe” von Code hinter uns lassen und die erste Gluon-Version ausschließlich für 802.11s an alle unsere Router ausrollen. Das war eine sehr wesentliche Hürde, aber Grundvoraussetzung für unsere zukünftige Entwicklung.

Auch für die Gluon-Entwickler war das Jahr 2019 turbulent. So wurde erst Ende Dezember 2019 das erste Release “Gluon 2019.1” veröffentlicht. Noch einmal verbessert aber bereits am 15.2.2020 von Gluon 2020 abgelöst, welche dann auch keinerlei Unterstüzung mehr für den alten Funkstandard IBSS beinhaltete. Mit dessem ersten Update auf v2020.1.1 im März 2020 war die Zeit für ein neues Stable-Update in unserem Netz reif.

Wir sind damit also heute mit fast allen Routern auf dem aktuellsten Stand der Gluon-Entwicklung, mit über 700 Routern im Netz auch quick lebendig und immer noch am wachsen.
Danke an alle Mitmacher!

Am 1.5.19 5:00 Uhr MEZ wird unser Netz sich automatisch auf eine andere Mesh-Funktechnik umstellen, nämlich von “IBSS” auf “802.11s”.

Falls euer Router zu dem Zeitpunkt aber aus war, dann kann es passieren, dass er später nicht sofort nach Inbetriebnahme wieder wie gewohnt funktioniert. Was ist zu tun?

Fall A:
Euer Router verfügt bereits über die aktuelle Stable-Firmware 0.11.7
In dem Fall gibt es zwei Szenarien.
1. Euer Router baut mit dem DSL-Router eine VPN-Verbindung zu uns auf.
Dort wird er sofort mit der aktuellen “Systemzeit” versorgt, merkt dann, dass der Umsschaltzeitpunkt erreicht/überschritten ist und wird binnen 10 Minuten selbstständig zu dem neuen Netz umschalten. Fertig.
2. Eure Router mesht nur per Funk mit unserem Netz.
In diesem Fall bekommt er keinen Kontakt mehr zu unserem Netz, denn euer Router befindet sich noch im alten IBSS-Modus. Somit kann er sich auch nicht mit der korrekten aktuellen “Systemzeit” versorgen. Er weiß also leider nicht “wie spät es ist”.
Dann wird er einfach mal für 120 Minuten in diesem Zustand bleiben. Nach den 120 Minuten wird er dann ebenfalls automatisch auf das neue Netz umschalten. Fertig.

Fall B:
Euer Router verfügt über eine ältere Firmware als 0.11.7
1. Der Router baut eine VPN-Verbindung über euer DLS-Modem zu uns auf.
Er sollte sich die aktuelle Firmware holen und aktualisieren, falls “Autoupdate” aktiviert war.
Falls nicht … manuell updaten.
2. Euer Router mesht nur per Funk
In diesem Fall müsst ihr leider manuell die neueste Firmware aufspielen.

Falls euer Mesh schon vor dem 1.5.19 plötzlich nicht mehr funktioniert, so liegt das vermutlich daran, dass Ihr den Uplink-Router längere Zeit ausgeschaltet hattet und die Mesh-Knoten mit der Firmware 0.11.7 weiter liefen und nach 120 Minuten ohne Internet dann auf 802.11s umgeschaltet haben, da sie ja keine aktuelle Uhrzeit mehr aus dem Netz bekommen haben.
In dem Fall könnt Ihr am einfachsten auch den Uplink-Router auf 802.11s bringen damit euer Netz wieder funktioniert. Dazu:
– Uplink-Router vom Internet trennen
– ausschalten
– einschalten
– 125 Minuten warten
– jetzt sollte der Router umgeschaltet haben
– Uplink zum Internet mit LAN-Kabel wieder herstellen.