Wie schon vor knapp zwei Wochen angekündigt, steht ein generelles Firmware-Update an.
Mittlerweile hat die Firmware »testing«-Status erreicht, direkte Tests mit 1043v3, 841v9 bis v11 wurden erfolgreich durchgeführt. Insgesamt 41 Geräte im Kreis GT sowie der Müritz-Region haben erfolgreich sich schon auf diese neue Firmware (als »experimental« bzw. seit Mittwoch »testing«) aktualisiert.
Wie schon im anderen Beitrag dargelegt, ist diese Firmware ein großer Schritt nach vorne — auch wenn sie für den 841v10 formal ein Rückschritt ist (841v10 benötigte bislang die OpenWRT-CC-basierte 0.7.5er Firmware; für Details siehe den vorangegangenen Beitrag. Neben der Vereinheitlichung der Firmware für alle Geräte sind nützliche Ergänzungen, basierend auf der Vorarbeit anderer Communities hinzugekommen:
- Von den Aachener Kollegen haben wir die Funktion »ssid-changer« übernommen: wenn die Verbindung zum Freifunk-Netz abbricht, also keine sinnvolle Funktion als Accesspoint möglich ist, wird die SSID des Accesspoints geändert, sodaß Clients gar nicht erst versuchen, sich zu verbinden. (Die Meshfunktion bleibt aber nach wie vor bestehen. Auch bleibt der AP aktiv unter der neuen SSID; mit statischen IP-Settings (DHCP geht ja nicht, da keine Verbindung zum Mesh) kann man sich da zwecks Debugging mit verbinden.)
- Von den Paderbornern übernommen haben wir Erweiterungen an der »status-page«, also der Webseite, die ein Knoten im Betrieb zu Diagnosezwecken ausliefert. Der Knoten, über den man angeschlossen ist, liefert diese Seite unter http://thisnode.ffgt.net/ aus.
- Auch von den Nachbarn in Paderborn übernommen haben wir die Idee für eigene »banner«-Inhalte. Das »banner« ist ein Text, der beim Login via ssh angezeigt wird. Wir haben da neben Infos zu den Communities ein paar praktische Kommandos aufgelistet sowie Details zur Firmware aufgenommen.
- Schlußendlich beendet die aktuell getestete Software die Zeit mehrerer SSIDs; im Kreis GT senden wir »guetersloh.freifunk.net« und »rheda-wd.freifunk.net« nicht mehr aus — wir gehen davon aus, daß alle Nutzer mittlerweile auf die einheitliche »KreisGT.freifunk.net«-SSID umgestiegen sind. (An der Müritz ändert sich natürlich nichts ;))
- Von der Community »Eulenfunk« übernommen wurde »gluon-wificheck«; dieses Modul schaltet sich selbst scharf, wenn mindestens zwei Nachbarn gefunden wurden und sorgt für einen Reboot, wenn über 15 Minuten lang plötzlich keine Nachbarn mehr gefunden werden. Unter bestimmten Voraussetzungen kam es in der Vergangenheit vor, daß die Funkmodule nicht mehr richtig funktionierten, dieser Check soll in so einem Fall für einen automatischen Reboot sorgen.
- Als Eigenentwicklung kann man ab dieser FW die WAN-MAC als »statisch« markieren. In dem Falle wird zur MAC-Berechnung für das WAN-Interface auf die Routine von Firmware 0.5 (Gluon 2013.3) zurückgegriffen — und zukünftige FFGT-Firmwares werden dies bei gesetztem Flag ebenso tun, somit sollte es nicht mehr zum »Knotenverlust durch MAC-Änderungen« kommen, wie wir ihn leider beim Umstieg auf Firmware 0.7 unwissentlich provoziert haben.
Heißt: wenn die (WAN-) MAC des Knotens beim Aufsteller für den Internetzugang freigeschaltet werden muß, _immer_ dieses Flag (Expert -> MAC) setzen.
Aber Vorsicht: prinzipbedingt wirkt es erst nach einem Neustart, d. h. bei der Erstkonfiguration wird der Knoten noch eine »aktuelle« WAN-MAC haben, erst nach Aktivierung des Flags und Neustart greift diese Änderung. - Wieder aus Paderborn übernommen wurde »ffho-node-tuning«, welches ein paar Kernel-Parameter setzt (konkret die ARP-Caches vergrößert, da wir ja ein ziemliches großes Layer-2-Netz betreiben).
- Und ein weiteres Paderborner Package ist »ffho-wifi-blackout-workaround«. »ANI« (»Adaptive Noise Interference«), ein Treiber-Feature des Atheros-Chipsatzes, der den meisten unterstützten Geräten zugrunde liegt, _scheint_ einen negativen Einfluß auf die WLAN-Stabilität zu haben. Aus diesem Grunde deaktivieren wir dieses Feature (ab 0.7.4~114 in jedem Fall, davor nur bei Geräten mit »stable«-Firmware).
Diese Firmware wird aktuell an die Knoten, die dankenswerterweise(!) den »testing«-Zweig im Autoupdater abonniert haben, ausgerollt. Reale Knoten im Netz über die Stufen »experimental« als auch »testing« als Versuchskanninchen nutzen zu können, ist ziemlich wichtig — vielen Dank an die Aufsteller dieser Knoten!
Wahrscheinlich am Freitag oder Samstag, sollten keine großen Probleme mehr auftreten, wird dann der Hebel umgelegt und alle Knoten mit aktivem Auto-Update bekommen diese Firmware.
Leider haben wir im Kreis GT 5 Knoten, die den Autoupdater deaktiviert haben:
33378-32-b5-c2-6f-93-48, 33378-32-b5-c2-6f-93-63, 33378-32-b5-c2-6f-93-db, ffgt_Eishaus_Isselhorst, ffgt-bkw
Bitte, liebe Knotenbetreiber, denkt dran, die Firmware aktuell zu halten! Ein Knoten läuft noch mit 0.5.3+5-exp20140913, unserer Start-Firmware. Das ist insofern doppelt doof, das dies dann der einzige Knoten mit »guetersloh.freifunk.net«-SSID sein wird.
Entsprechendes gilt auch für die Knoten an der Müritz, hier sind 8 mit deaktiviertem Autoupdate unterwegs:
17192-Stadtverwaltung-Waren, 17192-Teenotel, 17194-Fewo-MV-6430, 17194-Tressow-4e86, 17194-Tressow-9824, 17207-Kleines-Meehr, 17209-Burg-Wredenhagen-d94c, 17209-Eldeweg-a5f0
Evtl. wurde der Autoupdater deaktiviert, weil lokale Änderungen an der Konfiguration vorgenommen wurden — bitte teilt uns sowas ruhig mit, ggf. können wir das entsprechend als Package bauen und somit updatefest machen. So ist z. B. aktuell im Gespräch, andere Kanäle auswählbar zu machen (dann mit deaktiviertem Mesh & aktiviertem Mesh-on-LAN), um z. B. größere Installationen (Flüchtlingsunterkünfte) besser abbilden zu können.
Nachtrag: Außerdem bricht die neue 0.7.4er Firmware mit der bisherigen, von Gluon übernommenem, Eigenart, daß zur Konfiguration auf die gelben, zum Betrieb auf die blauen Ports gesetzt wird. Klartext: ab Firmwarestand 0.7.4~100 wird es nicht mehr notwendig sein, zur Konfiguration Kabel umzustecken! An sich verbindet man den Freifunk-Knoten einmalig, per WAN-Port (»blauer Port« bei den meisten TP-Link-Geräten), mit dem lokalen Netzwerk, und ab dann benutzt man den Knoten auch darüber: zum Setup öffnet sich das Konfigurationsinterface über die per DHCP gelernte (private) IP, im Betrieb geht der Knoten über jene IP online.
0.7.4~118 wird von den Knoten derzeit gezogen; nur Knoten mit 0.7.5~* bleiben diesmal noch außen vor.
Ausblick (Achtung, ab hier wird’s teils sehr technisch.)
0.7.4~118 ist ein Zwischenschritt für eine hoffentlich stabile, einheitliche Basis. 0.7.4~118 ist auch die erste Firmware, die nach einem Continuous-Delivery-Ansatz gebaut wurde (jede Code-Änderung führt zu einem automatischen Firmwarebau); daher auch die krude Nummer, für 0.7.4-0 als »saubere« Nummer im Gluon-Namensschema hätte nochmals der Compiler angeworfen werden müssen. Für 0.7.5-0 soll das anders werden
An Gluon, der Basisfirmware, wird aktiv sehr viel geschraubt, es ist mittlerweile die 5. Bugfix-Release (2016.1.5) draußen. Parallel ändert sich die OS-Basis ebenfalls, mit der Gründung von LEDE fließen nun augenscheinlich schneller Patches für neue Geräte ein, Gluon selbst wird von OpenWRT zu LEDE als Basis wechseln.
Solange aber kein Bedarf für neue, exotische Hardware existiert (841v11, 1043v3, CPE210v1.1 werden ja nun unterstützt, via Backports), liegt zumindest mein Hauptaugenmerk auf dem Lösen bekannter Probleme — eines ist das Updating »abgehängter« Knoten, in dem diese sich als Clients connected. Das hat es in 0.7.4~118 nicht mehr geschafft, soll das Kernfeature für 0.7.5-0 dann werden (welches die 0.7.5~*-Firmwares dann mit einfangen sollte.)
0.7.6 wird dann wohl »endlich« die Netze splitten (über das wie muß noch diskutiert werden), in eine der Versionen hoffentlich wird auch der Wechsel von fastd nach L2TP fallen.
So, da war ich gerade, der Router funktioniert, aber meldet keine Client-Zahlen.
War leider nicht ausgerüstet um da ein Update durchzuführen, darum habe ich mich auch nicht zu erkennen gegeben.
Danke!
Zeit für »Freifunk S.W.A.T. Team«-T-Shirts?
Nach Deiner Aktion am Holiday Inn wüsste ich nur einen, dem das zustehen würde