Mastodon

Firmware 0.6.5 ab jetzt im Stable und Beta Branch

Ab sofort steht die Firmware Version 0.6.5 auch im Stable und Beta Bereich zur Verfügung. Knoten mit aktiviertem Autoupdate beziehen dieses Update wie immer automatisch. Die Änderungen sind wie hier beschrieben:

Der größte Teil der Knoten hat das Update inzwischen bezogen. Es sieht aktuell so aus, als hätten wir keine Knoten verloren und alles läuft wie erwartet.

Jupp, meine haben auch schon alle die neue Firmware, läuft sehr gut…

Eine Frage bezüglich Update hätte ich: wie läuft das genau ab, werden die Updates immer direkt gezogen, sobald bereitgestellt oder stündlich?

Alle von mir hat es gestern Abend zwischen 22:50 Uhr und 23:00 Uhr erwischt, aktuell nicht wild - aber im Sommer, sobald der Biergarten nebenan (bis 24 Uhr) geöffnet ist surfen um die Uhrzeit viele Leute.

Per cron-job nachts anschubsen ginge nicht? Oder zu unsicher wegen Zwangstrennung/Wartung der Internetleitungen?

Eventuell kann ich ja auch selbst auf den Nodes einstellen, dass der autoupdater nur nachts läuft?!

Der Autoupdater fragt alle 4 Stunden zu einer zufälligen Minuten Zahl an. In der Regel veröffentlichen wir ein Update erst nach 22 Uhr wodurch die meisten Updates zwischen 4 und 5 Uhr morgens stattfinden. Aber selbst wenn es zu einer andern Zeit passiert, dauert das in der Regel nur wenige Minuten. Der Job ist hier definiert: /usr/lib/micron.d/autoupdater
Änderungen hier sind ziemlich sicher nicht Update sicher, werden also bei jedem Update überschrieben.
Passender Quellcode im Autoupdater Paket: https://github.com/freifunk-gluon/gluon/blob/master/package/gluon-autoupdater/luasrc/lib/gluon/upgrade/500-autoupdater

Also ich sage es hier nochmal: Jedes Update in den letzten Monaten löscht bei mir die eigenen Jobs in
/usr/lib/micron.d

Das ist ein bisschen lästig… weil ohne das simple wifi-script
/5 * * * * wifi
Stürzen bei mir täglich mehrmals die mesh-Verbindungen ab…

Das ist dann das zweite Problem:
Wenn ein Knoten WLAN-Mesh macht, dann ist die Wahrscheinlichkeit groß, dass das WIFI des Knotens nach ein paar Stunden einfach nicht mehr reagiert. Manchmal kommt es nach Stunden selber wieder hoch oder man zieht mal kurz den Stecker. Wenn man im Abstand von z.B. 5 Minuten den Befehl WIFI ausführt, hat das keinen negativen Einfluss auf laufende Übertragungen. Wenn das wifi mal wieder hängt hilft der Befehl aber umgehend, ohne Neustart des Routers, dem WIFI wieder auf die Beine.

Ich merke also in der Regel das ein Update gelaufen ist wenn meine Knoten sich wechselweise aus dem WIFI verabschieden… weil mein Script dann weg ist, was den Fehler umgeht.

Dann wäre es total cool wenn du mal bei den Gluon Entwicklern nachfragen könntest ob da was bekannt ist und ob du dafür nen Ticket aufmachen sollst.

Ich evaluiere gerade ein Paket einer anderen Community das genau dieses Problem behandelt und entsprechende Maßnahmen ergreift wenn das Problem auftritt. Es könnte also sein, dass es im nächsten Firmware Release ein Paket dafür gibt, dass direkt mitgeliefert wird.

Ich schau mal wie ich das mit der Frage bei Gluon mache…

Die Lösung mit “wifi” alle 5 Minuten funktioniert bei mir völlig sauber. Ich hatte in den letzten Wochen nur zwei mal ein Problem mit einem Knoten, wo nur ein Neustart geholfen hat. Aber ohne den Trick war das täglich ein Graus.

Ist schon klar, ob die nächste Release auf OpenWRT oder auf LEDE basieren wird?

Ne ist noch nicht 100% sicher. Es könnte sein das zwischendurch nochmal ein Beugfix-Release auf Basis von Gluon 2016.2.3 kommt, welches wir ja aktuell schon nutzen. Das nächste größere Release wird aber ziemlich sicher auf LEDE basieren.

Was bewirkt dieser Crontab genau?
Habe teilweise das gleiche Problem mit dem Knoten “Lustadt-Poststrasse”.
Der verliert gelegentlich die mesh-Verbindung um Uplink, und kommt erst wieder online, wenn der Auto-Reboot den Knoten selbständig neu startet.

Das sind 6 Felder: Minute Stunde Tag Monat Wochentag Befehl

Die oben zitierte Zeile führt zur Minute=5 (Stunde/Tage/Monat/WT = bliebig) den Befehl “wifi” aus. Das ist also einmal pro Stunde.

Der Befehl wifi macht:

Usage: wifi [down|detect|reload|status]
enables (default), disables or detects a wifi configuration.

Er läd also die wifi-Konfiguration neu und resettet damit vermutlich irgendwas.

Bitte achtet darauf die Cronjobs hier richtig anzugeben, sonst wird das kopiert und tut dann nicht oder macht sogar größere Probleme als vorher.

Die richtige Zeile muss so aussehen:

*/5 * * * * wifi

Mit obigen Variationen geht es entweder garnicht oder er wird nur zu jeder vollen Stunde + 5 Minuten ausgeführt

Wie schon gesagt, ich evaluiere gerade eine Paket das genau diesen Cronjob in etwas intelligenterer Form mitbringt. Bitte wartet noch ein paar Tage bevor ihr das jetzt alle manuell da rein fummelt.

Ist es wirklich so schlimm, dass alle 5 Minuten die Konfiguration neu geladen werden muss? Ich hatte “einmal pro Stunde” für einen durchaus realistischen Wert gehalten …

Kurzum: Ja. Damit funktioniert u.U. das WLAN für 5 Minuten die Stunde.

Sorry für den Typpo … aber das WLAN funktioniert bei mir mit dem richtig geschriebenen Befehl immer.
Wenn es ausfällt, dann nur für maximal 5 Minuten.

Wenn @leah da jetzt noch was feineres baut, dann ist es sicher nicht verkehrt darauf zu warten. Mir hat das jedenfalls in den letzten Monaten massiv geholfen. Ohne das musste ich manche Knoten täglich neu starten lassen, von entsprechend genervten Standortstellern.