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!

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!

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”.

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.

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.