Autorarchive: tackin

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

Neue Gluon-Firmware 2016.2.7 — bitte testen

Letzte Woche habe ich neue Software compiliert. Ihr findet diese, wie immer, auf  Github Experimental. Die Software trägt meine Versionskennung “0.9.0+tackin”, basiert auf Gluon 2016.2.7 und wurde auf einigen Routern bereits erfolgreich als Upgrade geflasht. Daher würde ich euch gerne bitten, diese ebenfalls bei euch sowohl als Factory als auch als Upgrades auf diverser Hardware zu testen. Sofern im weiteren Verlauf der Tests keine Probleme auftreten, ist geplant diese Version als neues Stable-Update auszurollen. Etwaige Fehler-/Problemberichte bitte an uns weitergeben.
Alle vorab mit dieser Version geflashten Router befinden sich weiterhin im Stable-Branch und werden sich also auch in Zukunft automatisch mit kommenden Updates versorgen. (Ihr hängt also nicht in einem “Testbranch” fest.)
Wie bereits im Mai angekündigt, ist dieses Vorbereitungsupdate hier auf die erste LEDE-Version unbedingt nötig. Wir können also LEDE erst ausrollen, wenn “0.9.0+tackin” überall erfolgreich läuft. Daher bitte ich eure Router zügig mit dieser Version upzudaten oder zumindest ein Autoupgrade an euren Routern zu ermöglichen.
“Unter der Haube” gibt es bei diesem Gluon-Update auch einige weitere zwingende Neuerungen. Dazu schreibe ich aber einen eigenen Artikel.

Fazit: Wer nicht updatet wird in einigen Wochen leider kein Freifunk bei uns mehr genießen können.

Unterstüzung neuerer Hardware

Immer mal wieder werden wir gefragt, wann es denn auch eine Firmware für diesen oder jenen neuen Router mit dieser oder jener Hardware-Version geben wird. Die Frage stellt sich natürlich immer dann, wenn der Freifunker in unserer Firmware-Liste nicht fündig wird. Und dass euer Router sich NIEMALS mit Images für frühere Hardwareversionen erfolgreich flashen lassen wird, sollte jedem klar sein.

Falls ihr die Firmware in einer anderen Community schon findet, dann bedeutet es,
entweder
wir hinken etwas hinterher und müssen unbedingt nochmal den Firmware-Backautomaten anwerfen um die aktuellen Images zu bauen.
Hier lohnt dann der Blick auf evtl. vorhandene andere Branches (z.B. “tackin” oder “experimental”). Diese Builds sind jünger und werden in der Zukunft u.U. sogar unsere neue “stable”-Release.

oder
Die Firmware ist als BROKEN markiert. Dann funktioniert diese Firmware nicht zuverlässig, hat Macken und Einschränkungen oder schrottet gelegentlich auch mal den Router. Solche Firmware bauen wir eigentlich nicht für den Download.

LEDE und/oder ibss/11s haben übrigens bis dato, soweit mir bekannt, keinen Einfluß auf verfügbaren Firmware-Images.

Falls ihr die Firmware auch in anderen Communities nicht findet, dann haben wir die ganz sicher auch nicht. Es erübrigt sich dann auch jedes Nachfragen ob und wann die verfügbar sein wird. Wir wissen es schlicht und ergreifend in aller Regel nicht.

Freifunk ist keine “Firma” mit eigener “Entwicklungsabteilung”.
Jede Firmware entsteht, weil sich jemand mit viel Sachverstand erbarmt, sich Tage oder Wochen hinsetzt und die Soft- und Hardware des neuen Routers inspiziert und versucht Gluon/openwrt darauf ans laufen zu bringen. Selbst wenn wir wissen, es arbeitet gerade jemand an einer Firmware für Gerät X, heißt das noch lange nicht, dass jemals auch eine Firmware wirklich verfügbar sein wird. Manchmal sind die Hürden der Hardware einfach zu hoch weil elementare Treiber fehlen oder nicht sauber arbeiten. Dann wird es auch nach Monaten halt keine fertige Firmware für Gerät X geben. Diese Geräte sind dann evtl mit Gluon als BROKEN-Image betreibbar. Der Support dafür ist aber einfach unmöglich und Totalverlust beim Flashen sehr gut möglich.

Beispiel aus der Praxis:
Professionelle Entwicklung eines Opensource-Treibers für neue WIFI-Chipsätze in aktuellen Routern dauert viele Monate und kostet gerne mal 50.000 Euro. Das kann Freifunk nicht bezahlen, weil Freifunk keine entprechenden Einnahmen hat. Falls also jemand der Community jetzt finanziell unter die Arme greifen möchte um diese elementare Entwicklungsarbeit zu professionalisieren, dem können wir sofort passende Ansprechpartner vermitteln.

Wer tiefer einsteigen will: Hier findet Ihr alle Targets / Router für die es prinzipiel eine Firmware gibt.

Neue Firmware ausgerollt

Mit unserem letzten Stable-Firmware 0.8.4 gab es kaum Probleme. Lediglich einige CPE-Hardware und neuere Routermodelle machten zwischen durch mal neue Experimentals notwendig. Daher gab es auch wenig Grund für ein generelles Update.

In den letzten Monaten kamen nun aber auch bei unserer Infrastruktur einige Veränderungen zusammen, die in einer neuen Firmware jetzt berücksichtigt werden mussten. Nachdem alle Änderungen an unseren Gateways erledigt waren, haben wir uns also entschlossen eine neue Stable-Release zu bauen. Dieses Release basiert auf “Gluon 2016.2.5” und wird wohl das letzte Gluon sein, welches auf OpenWRT basiert.
Am 27.4.2017 fiel der Startschuss für den Roll-Out unsere neue Stable-Firmware “0.8.6”. Stand heute haben sich über 400 unserer Freifunkrouter per Autoupdate problemlos mit dieser neuen Software versorgt.

Unser Fahrplan:
Das nächste Gluon-Release (und damit auch unsere nächste Stable-Router-Firmware) wird noch ein Bugfix- und Vorbereitungsupdate auf LEDE sein und muss unbedingt installiert werden (oder euer Knoten wird sich beim Übergang zu 2017.1 aufhängen). Danach erfolgt mit 2017.1 unsere erste LEDE-basierte-Firmware und die wird auch unser Mesh massiv verändern. Unser Ziel ist ein sicherer Migrationspfad des Funkstandards von IBSS auf 802.11s in unserem Netz zu realisieren. Ein Paralellbetrieb von IBSS und 802.11s führt leider zu massiven Problemen und ist daher auch für eine Übergangszeit nicht machbar.
Schon jetzt sei also hier angekündigt, dass mit diesem Wechsel zu 802.11s dann alle Router mit älteren Firmwareständen und ohne aktiviertem Autoupdate von unserm Mesh-Netz dann plötzlich ausgesperrt sein werden. Wir empfehlen daher euere Router (und die eurer Nachbarn) auf aktuelle Firmware zu prüfen und die Autoupdate-Funktion aktiviert zu lassen.

Freifunkertreffen in Sirzenich

Wir waren gestern mal wieder auf eine Pizza und ein paar Bier zu Gast bei Christoph im Dorftreff Sirzenich. Der Dorftreff ist, wie unsere Freifunker-Community, ein tolles Beispiel für modernes ehrenamtliches Engagement zum Wohl der Gemeinden. Infos: Dorfgemeinschaft Sirzenich  Die Renovierung und das neue Ambiente des alten Gemäuer sind wirklich beeindruckend.

Der Dorfgemeinschaftsverein verwaltet den Dorftreff mit dem Ziel einen Beitrag für ein lebendiges Dorf mit Zukunft zu leisten. Konzerte, Flohmärkte, Kaffee-Nachmittage, Senioren-Treffen und eine Location auch für private Feiern und Fest, bringen Alt-Sirzenicher und Neubürger hier jede Woche zusammen. Jeden Freitag trifft man sich so z.B. auf dem Vorplatz beim Bääker zum Bier und frisch gebackener Pizza. Der Andrang ist in der Regel so groß, dass man auf die Pizza schon mal 2 Bier lang warten muss.

Gemeinsam mit Christoph vom Dorfgemeinschaftsverein haben wir rund um den Dorftreff im letzten Jahr Freifunk nach Sirzenich gebracht. Grund genug also mal wieder dort auch nach dem Rechten zu sehen.

Christoph wir danken dir natürlich sehr für deine herzliche Einladung zu euch in den Dorftreff und für die spitzenmäßige Beköstigung.