In den letzten Tagen haben wir in der Community eine Menge zum Thema Gelsenkirchen telefoniert und gechattet und ein paar technisch versiertere Mitglieder mit mehr Freifunk-Erfahrung haben sich den Status Quo angesehen.
Auch wenn wir gerne einmal schimpfen, ist allen klar, dass das Adminteam im Hintergrund unermüdlich an der Verbesserung der Stabilität von Freifunk arbeitet. Der Blick auf die Technik legt momentan den Schluss nahe, dass die Ursachen für die schlechte Erreichbarkeit nicht unbedingt im Backbone zu suchen sind, sondern die Anzahl der einfachen Plasterouter mit den Anforderungen in einem komplexen Mesh einfach nicht auf Dauer stabil zurechtkommt.
Da sich alle Beteiligten allerdings einig waren, dass die Arbeit in Gelsenkirchen Vorzeigeprojektcharakter hat, wagen wir jetzt die Flucht nach vorne. Wir bereiten einen Projektantrag „Modernisierung der Technik im Gelsenkirchener City-Mesh“ vor, den wir dann zur Abstimmung an den Verein Rheinland schicken.
Vorrangiges Ziel soll es sein, veraltete Routermodelle wie 740 und 741 aus dem Verkehr zu ziehen und kritische Punkte durch Modelle mit ausreichend Power und Speicher zu ersetzen, z.B. den 1043v2.
Um den genauen Umfang abzuschätzen, schauen wir jetzt erstmal auf den Bebauungsplan, um auf eine Hausnummer zu kommen.
Gerne würde ich aber schonmal euren Input zum Vorhaben hören und den Erfolgsaussichten.
Wenn es nur an den 74x-ern liegen würde: Wäre schön.
Ich denke aber, es trifft hier selbst die Nanostations, die wegen „Speicher alle“ Kernelpanic werfen.
Entweder man findet, was das auslöst.
Oder man sagt sich „liegt an der Größe der Domain/Zahl der Clients/Zahl der Spielkinder/Wahrscheinlichkeit von Unglücksraben“: Dann würde man die GE-Community in eine eigene Domain abteilen.
In Gelsenkirchen ist es derzeit eine Mischung aus:
Vor Ort:
viel Mesh mit wenigen schlappen Uplinks
dadurch auch viel single Point of Failure
viele Router mit wenig RAM, egal ob jung oder alt
Diagnoseengpässe
Manipulation, im Sinne von Stecker ziehen, Strom abschalten etc.
Backbone:
Probleme im Netz wirken sich auf die schwächsten Strukturen am ehesten und härtesten aus (siehe vor)
experimenteller Charakter auch wenn alle ihr Bestes geben
aktuell zu viele IPv6 Adressen im Mesh unterwegs, was Router mit wenig RAM sehr schnell zum Rebooten zwingt, wenn insgesamt die Umgebungsbedingungen stimmen
Was ist damit gemeint?
Es gibt einen komplexen kausalen Zusammenhang zwischen Mesh-Wolke vor Ort, Anzahl Uplinks und deren Güte, gewählte Routermodelle - sowie Anzahl der IPv6 Prefixe, Anzahl der IPv6 Adressen, IPv6 RA.
Je ungünstiger diese Punkte aufeinander kollidieren, desto größer sind die Probleme und desto schneller wirken sie sich aus. Da es wenige IPv6 Netze in unserer Größe gibt, sind auch kaum Praxiserfahrungen vorhanden.
Team Gluon kümmert sich um die bessere Verarbeitung von IPv6 RA, damit Ressourcen schonender auf den Nodes vorgegangen wird (Stichwort: dhcpv6.script).
Team Ruhrgebiet wird heute eine ungeplante Notfall Aktualisierung über den Autoupdater schicken, in welcher, neben anderen Dingen, das ULA Netz gegen das neue Prefix getauscht wurde, wie auch die Next Node Adresse nun im neuen Prefix liegt.
In den vergangenen Tagen wurde intensiv an der Diagnose gearbeitet, unter Anderem in unsortierter Reihenfolge von @adorfer, NeoRaider, @tcatm, @thomasDOTwtf, @pberndro, um nur ein paar Personen zu nennen.
Die ULA Adressen sind bereits aus dem Ruhrgebiets Backbone verschwunden. Es wurde bereits auf 3 IPv6 Gateways reduziert - 2 Gateways am Rheinland Backbone mit dem neuen Prefix, 1 Gateway in Köln mit dem alten Prefix.
Diese Maßnahme dürfte bereits mindestens 75% der dhcpv6.script Last, so wie ein bisserl unnötigen Traffic reduziert haben.
Warten wir es ab wie gut das Update greift und ob morgen zumindest die akuten Reboot-Syndrome bei den betroffenen Nodes aufhören.
Die Planung in Gelsenkirchen noch einmal neu aufzurollen halte ich für eine hervorragende Idee. Da die meisten Fehler lokaler Herkunft waren liegt dort sehr viel Potential begraben, das derzeit nicht genutzt wird und die User eher verärgert.
Schwierigster Punkt dürften die Uplinks sein, von denen es in der Vergangenheit nicht sonderlich viele gab?
Geschwindigkeitsrekorde wird das City-Mesh GE nicht einfahren, aktuell sehe ich 4 Uplinks. Immerhin scheint es nicht mehr als 3 Hops bis zum nächsten Uplink zu geben, das sollte schon drehen.
Davon (BB/0.6) verspreche ich mir leider wenig.
Warum? Weil die Reboot-Problematik „wege der Scripte“ zumindest bei mir noch heftiger zugeschlagen hat mit den Master-Builds im Dezember. Und an dem Teil wurde afaik nichts geändert.
Ist es nicht möglich, um dieses dhcpv6-script (welches afaik unverändert aus dem openwrt stammt) einen wrapper zu bauen, dass mehrfahre simultane Ausführung abblockt?
Es geht auch vielmehr um das Replacen des ULA Prefix gegen das Rheinland Backbone Prefix.
Natürlich kann man da Locking drum rum bauen, aber bei solch einem Eingriff müssten wir im Anschluss viel länger testen, bevor wir ausrollen können. Wenn dort in der Verarbeitung was schief geht und die Node(s) keine IPv6 Adresse, Route, etc. mehr anlegen, dann erreicht man sie ggfs. mit dem nächsten rettenden Update nicht mehr.
Die Ausführung des dhcpv6.script muss aber bereits wie beschrieben um 3/10tel zurück gegangen sein, da die Gateways angepasst wurden und Wireshark auch nur noch 3 statt 10 IPv6 Gateways sieht…
Im gleichen Zeitraum nur noch 3 statt 10 RA bedeutet entsprechend auch nur noch 3 statt 10 dhcpv6.script Aufrufe. Zumindest wenn es nicht noch von anderen Dingen getriggert wird…
In der Wolke sehen sich zwar viele Knoten, aber wirklich gut kommunizieren können sie nicht. Wenn dann ein Knoten (aus welchen Gründen auch immer) ausfällt, zieht das vermutlich noch andere mit bzw. verschlechtert die Verbindung weiter.
Weitere Uplinks sind meiner meiner Meinung nach wünschenswert, weitere Knoten zwischen den bestehenden sicher auch. Aber ich bin sicher ihr tut vor Ort euer Bestes
