Uplink ausgebaut

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!

3/2020 – Stand der Dinge

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!

Euer Router funktioniert plötzlich nicht mehr?

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.

Großer Umbruch ist in Planung

Mit der aktuellen Gluon-Version 2018.2.1 haben wir endlich ein wichtiges neues Tool zur Verfügung. Damit können wir unser Netz nun von einem Funkstandard auf einen anderen migrieren ohne, dass uns Router verloren gehen.
Aktuell ist die dafür nötige Firmware 0.11.7 als neue Stable ausgerollt.

Der fest programmierte Umschalttermin in der Firmware ist: 1.5.2019 05:00:00 MEZ

Wichtig: Eure Router müssen zu diesem Zeitpunkt zwingend auf unsere Firmware 0.11.7 upgedatet sein.
Alle Router mit älterer Firmware werden ab dem genannten Zeitpunkt nicht mehr per Funk erreichbar sein.

Unsere Empfehlung lautet:

  • Router 24/7 eingeschaltet lassen
  • Autoupdate aktivieren
  • Firmware älter als unsere 0.11.4 bitte manuell auf die aktuelle „stable 0.11.7“ updaten

Dann wird euer Router sich problemlos selbstständig in das neue Netz integrieren.

Übrigens … wer gerne mittesten oder einfach nur vorab updaten will:
https://github.com/freifunktrier/firmware_store/tree/master/firmware

Die EU-Datenschutzverordnung „DSGVO“

Kaum ein Thema hat die letzten Wochen die IT-Welt so gespalten und in Aufregung versetzt wie diese fünf Buchstaben. Und auch an den Freifunk-Communities ging das nicht spurlos vorbei. Prinzipiell sind wir Freifunker ja auf der Seite der „Schützer“. So haben wir uns z.B. geschlossen gegen die Datensammelwut der Vorratsdatenspeicherung gestemmt, weil diese die Nutzer vollkommen unangemessen unter einen Generalverdacht stellt.

Und jetzt?
Die Meinung der Communities zum DSGVO ist dagegen sehr gespalten bis ablehnend. In vielen Bereichen unserer Arbeit bleibt die Verordnung so schwammig bis unklar, dass Auseinandersetzungen über die Auslegung und Wertung der einzelnen Absätze und Erwägungsgründe leider den Gerichten überlassen bleibt. Denn – Ja, wir verabeiten und speichern auch personenbezogene Daten! Wie sollten wir sonst in der Community mit euch kommunizieren können?

Was uns als Freifunk-Trier dabei tangiert und wo wir den „Datenschutz personenbezogener Daten“ beleuchten müssen, habe ich einmal hier zusammengetragen: trier.freifunk.net/datenschutz/
Ohne Gewähr für die Richtigkeit und Vollständigkeit der Aussagen! Als Nicht-Jurist erwarte man von mir bitte keine profunde gerichtsverwertbare Rechtsauslegung. Vielmehr möchte ich lediglich die Gedankengänge und Meinungen darstellen.

Wenn etwas fehlt, Ihr etwas korrigieren oder anmerken möchtet, bitte ausgiebig die Kommentarfunktion nutzen!

Neue Gluon 2017.1.5 stable kommt per Autoupdate

Nach dem die neue Beta auf mehr als 40 Routern seit einigen Tagen stabil läuft, habe ich mich entschlossen ab sofort das neue Gluon-Release als „stable“ auszurollen. Hinzugekommen ist z.B. Die Firmware für den TP-Link WR1043-v5n (ohne abnehmbare Antennen) und zwei Ubiquiti EdgeRouter. Daneben gibt es einige Bugfixes sowie Änderungen bei unseren GW-Domain-Namen.

Hier auch nochmal herzlichen Dank an alle fleißigen Beta-Tester die meinem Mailaufruf gefolgt sind!

Leider werden wir in Kürze einige unserer potentesten Server verlieren. Die Mietverträge laufen aus und die Eigner möchten die Kosten für die Hardware nicht weiter tragen, da die Gerätekosten für sie alleine unwirtschaftlich geworden sind. Auch mit normaler personeller Fluktuation in unserer Community über die Jahre gehen gelegentlich Server verloren.

Jeder von euch, der freie Hardware beisteuern kann, ist daher dringend eingeladen die ein oder andere KVM für unseren Freifunk „abzuzweigen“.

Aber auch in Berlin kämpfen wir mit Personalengpässen und gelegentlichen Serverproblemen. Hier wären dringend regelmäßige Investitionen nötig um uns mehr Redundanz zu schaffen. Gerade Gemeinden die Freifunk im Ort aktiv fördern, dürften ein Interesse an einer stabilen Infrastruktur haben und sind schon aus Eigennutz eingeladen, mal über ein finanzielles Engagement nachzudenken.

Störung machte unser Netz einige Tage für manche unbenutzbar

Seit ca. 26.10.2017 habe ich bemerkt, dass meine Knoten gelegentlich eine sehr schlechte Preformance hatten. Ein Neustart des Knoten brachte dann meist wieder Besserung. Meine Vermutung war ein lokales Problem. Als ich aber am Freitag von Usern ebenfalls hörte, dass sie seit Tagen ein Problem mit dem Netz haben, musste ich der Sache nachgehen.

Ich habe mehrere Möglichkeiten Speedtests zu machen:
– zwischen FF-Knoten und GW
– GW zu GW
– FF-Host als Server ins Internet (Upload)
– FF-Client zum Internet (Download)

Nach vielen Stunden Fehlersuche und rum probieren an diversen Configs hatte ich (großer Dank an kpanic!) den Eindruck, dass es ein Problem mit der fastd-Verbindung zwischen Knoten und GW geben musste. Sobald die Knoten versuchen den GW per IPv6 zu erreichen und in Folge eine IPv6-Verbindung für den Aufbau des fastd-Tunnels nutzen, scheint es zu einem massiven Zusammenbruchs der Performance auf diesem Uplink zu kommen. Zwinge ich den Knoten dazu, den Tunnel über eine IPv4-Verbindung zu realisieren, funktioniert es hingegen problemlos.

Jedem Netzwerker kommt jetzt natürlich sofort die MTU als Problemauslöser in den Sinn. Hier kann ein zu hoher Wert im fastd zu massiven Störungen führen. Gegen diese Vermutung spricht aber:

  • den Wert von 1406 verwenden wir von Beginn an und hatten nie Probleme
  • Telekom hat im DSL eine MTU von 1492, sodass uns auf Telekom-Leitungen (z.B. auch meiner) 86 Bit Overhead zu den Nutzdaten im fastd-Tunnel bleiben und das sollte eigentlich reichen.

Was hat sich in der letzten Woche denn geändert? Wir haben LEDE 2017.1.3 per Autoupdate ausgerollt.
Aber auch hier gebe ich zu bedenken, dass ich LEDE im Vorfeld schon 2 Wochen bei mir laufen hatte und ich keine solchen Probleme bemerkt habe. (Vielleicht ist es mir aber auch nur nicht aufgefallen.)

Als erste Maßnahme habe ich auf (fast) allen GWs die fastd-config dahingehend geändert, dass nur noch IPv4-Verbindungen von euren Freifunk-Routern entgegen genommen werden. Auf absehbare Zeit wollen wir aber wieder IPv6 anbieten können. Daher …….

Wer an dieser Stelle jetzt Lust hat sich an der Problemlösung zu beteiligen ist herzlich eingeladen!

Next please! – – Gluon 2017.1.3 kommt

Kaum ist die aktuell stable Version auf den Routern, haben wir auch schon wieder eine neue Experimental, die, wenn alles gut läuft, dann in ein paar Wochen schon unsere nächste Stable werden wird.

Ihr könnt die Experimental-Versionen wie immer hier von Github laden und auf eure Router flashen um fleißig an der Testphase zu partizipieren. Ebenfalls wie immer wird jeder Knoten mit der neuen Experimental automatisch wieder die nächsten Stable-Release mitmachen. Ihr landet also damit nicht in einer Sackgasse was die zukünftige Updatefähigkeit betrifft.

Was hat sich geändert?

  1. Mit dieser Version sind wir auch auf LEDE als Grundlage von Gluon angekommen. Damit gehört OpenWRT, viele Jahre die Basis jeder Gluon-Version, nun der Vergangenheit an.
  2. DnsMasq hat seit langem einen Bug, den man vor kurzem aber erst entdeckt hat. Bei uns wirkt sich der Bug nicht so massiv auf die Sicherheit aus, weil wir eine spezielle Konfiguration haben. Aber man kann Knoten wohl immer noch angreifen und evtl. auch zum Absturz bringen. Dieser Bug wurde mit Gluon 2017.1.3 behoben.
  3. Einige Details an unserer Community-Config ändert sich immer mal. Diesmal jedoch nur Kleinigkeiten. Einige Github-Repos mussten aber auf LEDE angepasst werden.
  4. Für  x86 – Images (Offloader). Wenn eure virtuelle Platte eures Uploaders auf Basis von 2016.2.x erzeugt wurde, muss die unbedingt vor dem Upgrade auf 2017.1.3 auf 273MB oder größer erweitert werden. Das geht mit:    qemu-img resize $IMAGE 273MB
Mein Rat: Alle die auf hohe Sicherheit wert legen, und die Angriffs-Risiken minimieren möchten, sollten dieses Update auf alle Fälle ausprobieren und nach und nach auf die Router ausrollen.

Und nicht vergessen: Rückmeldung geben, wenn etwas damit klemmt!   Danke!

Neue Gluon-Version 2016.2.7 ist ausgerollt

Abgesehen von einigen Routern, die permanent offline sind oder die Auto-Update-Funktion deaktiviert haben, ist die Migration unserer Firmware von 2016.2.5 nach 2016.2.7 nun abgeschlossen.

Dieses Update war aus mehreren Gründen notwendig:

  • die Vorgängerversion hatte einen Bug im Updateskript, der ein automatische Update nach 2017.x und dem damit verbundenen Wechsel auf LEDE bei einigen Routern/Offloadern verhindert hätte.
  • enthält das Update eine weitere Uplink-Möglichkeit. Dabei wurde der Public-Key von unserem Gateway Neso erneuert, der nach einem Crash leider längere Zeit nicht mehr zur Verfügung stand.
  • Die Knoten kennen jetzt die zusätzlichen Zielports von 10.001 – 10.010 auf den GWs

Da die Gateways schon einige Wochen über die neuen Segmente verfügen, werden auch eure Knoten nun in den Nächsten Tagen anhand der bei uns hinterlegten PLZ im Dateinamen eurer Keys diesen Segmenten zugeteilt.

Dabei kann es zu kurzen Störungen kommen, die aber in der Regel nicht länger als eine halbe Stunde dauern sollten. Wenn Ihr jedoch permanent ein Problem mit eurem Freifunk-Router haben solltet, meldet euch bitte bei uns.
Falls euer Router nicht updatet, wäre jetzt die letzte Chance dies nachzuholen. Anschließend ist ein Update meist nur noch per Mesh möglich. Router mit älterer Firmware werden sich dann nicht mehr mit den Gateways per eigenem Uplink verbinden können, solange ihr keine aktuelle Firmware dort installiert.

Wichtig für Inhaber statischer IPs in unserem Netz:
Euer IPs werden mit dem Augenblick der Migration in die Segmente nicht mehr gültig sein. Wer eine feste IP benötigt, kann diese auch weiterhin bekommen, jedoch wird die IP abhängig vom Netzsegment in dem sich der Host befindet.
Die Aufteilung der Netzsegmente erfolgt nach dieser Liste:  https://trier.freifunk.net/geplante-aufteilung-der-segmente/
Ihr könnt uns vorab auch jetzt schon mitteilen, welche statische IP ihr weiterhin nutzen möchtet und in welchem Segment sich dieser Host befinden wird. Dann werden wir das im Vorfeld schon anpassen. Umstellungsbedingt kann es zur zwischenzeitlichen Unerreichbarkeit eurer aktuellen Hosts kommen!

Ebenfalls wird sich einmalig die derzeitige (statische) Knoten-IPv6 eures Knotens ändern, da sich auch diese IPv6 aus dem Netzsegment ergibt indem euer Knoten sich befindet. Danach bleibt diese dann aber wieder nahezu „statisch“.

Die „Hoods“ kommen

Wir wollen weiter wachsen und müssen uns der Tatsache stellen, dass größere Netze auch einen größeren Traffic-Overhead bedeuten. Das würde unweigerlich dazu führen, dass wir bald mit jedem hinzukommenden Router ein wenig langsamer werden, weil immer größere Datenmengen im Netz nur noch dazu gebraucht werden, um die Infrastruktur zu managen und somit unseren Clients nicht mehr zur Verfügung stehen.

Diesem Szenario wollen wir rechtzeitig mit neuen Verwaltungsstrukturen in unserem Netz entgegenwirken. Ein probates Mittel in vielen anderen Communities sind die Einführung von „Hoods“.
Hoods oder auch „Netz-Segmente“ sind strukturierte, voneinander abgegegrenzte Bereiche einer gemeinsamen Freifunk-Community. Diese mindern den Traffic-Overhead des Gesamtnetzes enorm.

Wir haben uns in den letzten Monaten viele Gedanken über mögliche Strukturen in unserem Netz gemacht und sind zu dem Ergebnis gekommen:

  • wir werden Netzsegemente bei uns ebenfalls einführen (Endausbau: 16 Stück)
  • wir wollen, dass jedes Gateway auch jedes Segment betreuen kann
  • wir wollen vermeiden für jedes Segment eine eigene Gluon-Version zu erstellen

Unsere Gateways sind in den vergangenen Monaten mehrfach umstrukturiert worden. Zum einen haben wir in Berlin 2 Gateways, die unseren IPv4-Traffic jetzt direkt ausleiten ins Internet. Danach wurden alle anderen Gateways degradiert und arbeiten den Gateways in Berlin nur noch zu, haben weder einen eigenen Uplink ins Internet, keinen DHCP-/RA-Service, kein DNS, noch eine eigene tinc- und BGP-Session. In einem weiteren Schritt haben wir auf allen GWs für jedes geplante Segment eine Bridge, eine Fastd-Instanz und je einem BATMAN-Interface aufgerüstet. Die Verbindung der GWs untereinander erfolgt mit jeweils 5 Fastd-Tunneln. Diese Zahl wird in Zukunft mit jedem weitern Netzsegment steigen.

Derzeit sind noch alle Knoten im Netzsegment „00“ unterwegs. Mit dem neuen Firmwareupdate „0.9.0+tackin“ bekommt jeder Router eine neue Knfiguration, die ihm überhaupt erst ermöglicht, an den neuen Netzsegmenten teilzunehmen. Sobald wir die Vorbereitungen zum „Go“ für die Segmente abgeschlossen haben, werden wir auf unseren GWs steuern, welcher Router sich in welches Netzsegment integrieren wird (und wirklich NUR dort). Eure Router werden das automatisch erledigen, es gibt nichts was ihr tun müsst … sofern euer Router das besagte Update auch installiert hat.

Alle Router, die ältere Software nutzen und einen Uplink haben, werden danach dann keine Verbindung mehr zu unserem GW aufbauen können. … Sorry!

Ein Risiko bleibt

Die Segmente/Hoods haben allerdings immer ein Risiko. Es ist nicht ausgeschlossen, dass ein User (absichtlich oder unbeabsichtigt) zwei Router betreibt, die untereinander verbunden sind, aber in zwei unterschiedlichen Netzsegementen eingebucht sind. Dieses „bridging“ bringt die Netze durcheinander und führt zu massenhaftem unsinnigem Traffic. Dem könnten wir begegnen, indem wir für jedes Segment auch eine eigene Gluon-Version erzeugen, die dann verhindern soll, dass die beiden Problem-Router sich überhaupt untereinander verbinden können.
Ich vertraue jedoch erst einmal darauf, dass dieses Problem bei uns nicht oder nur sehr sehr selten auftritt, sodass der Aufwand einer eigenen Gluon-Version in keinem Verhältnis dazu stehen würde. Wenn sich zeigt, dass Maßnahmen nötig sind, werden die Router, die an dem Bridging beteiligt waren, dauerhaft von unseren GWs ausgesperrt. Im Extremfall, werden wir auch eigene Gluonversionen einführen.

Wir werden die Segmente anhand der Hostnamen festlegen. Dabei nutzen wir die PLZ um GEO-Regionen festzulegen indem ein Segment arbeitet. Daher war in der Vergangenheit die Angabe der PLZ erwünscht. Das bedeutet: ihr dürft NIE zwei Router mit unterschiedlichen PLZ gemeinsam nebeneinander mit uplink betreiben – auch und besonders nicht testweise.

  • Solltet ihr für einen anderen Ort einen Router vorbereiten, dann darf dieser Router zwar testweise gerne im WLAN-Mesh teilnehmen, Ihr dürft aber keinen Uplink zu unserem GW mit diesem Router zulassen.
  • Sollte sich der Aufstellort ändern, brauchen wir die Info damit wir ggfl. das Netzsegment dieses Routers anpassen
  • Schickt uns den Key mit dem Hinweis, ab wann wir den eintragen sollen, damit ihr in Ruhe testen könnt, aber kein Bridging passieren kann