Seit einer Woche ist der Knoten zuverlässig per Reverse SSH über IPv4 erreichbar und lässt sich so bei Ausfall ohne Vor-Ort-Einsatz wieder starten, was die Ausfallzeiten deutlich reduziert. Auch die Ausgabe von logread -f läuft permanent über die gleiche Verbindung. Es sieht daher so aus, als ob die Mobilfunkverbindung per IPv4 stabil ist, also wohl keine Hardwarestörung beim Anbieter, in der Speedbox oder auf dem Knoten vorliegt.
Am längsten lief der Knoten bisher, wenn das WLAN-Mesh zum zweiten und dritten Knoten eine gute Verbindung hatte (ganz am Anfang 7 d 21 h, danach wurde Knoten in anderen Raum gestellt) oder manuell deaktiviert war (4 d 4 h). Da Mesh über 2,4 GHz deutlich stabiler als über 5 GHz ist, habe ich heute früh Mesh für 5 GHz deaktiviert in der Hoffnung, das damit Ausfälle weniger häufig vorkommen.
Bei den letzten Ausfällen zeigte tcpdump, dass nach wie vor Daten mit einem Gateway ausgetauscht wurden. Es fällt auf, dass ein Ausfall praktisch immer zeitgleich mit einem Wechsel des Mesh Links auftritt.
Vorhin gab es um 14:20 einen erneuten Ausfall, allerdings mit neuem Fehlerbild: der Knoten blieb weiterhin von außerhalb noch anpingbar, die Statusseite des Knoten war per HTTP erreichbar, und die Knoten 2 und 3 liefen durchgehend normal, also mit angemeldeten Clients und Statusmeldungen.
Es gibt nun endlich Mal wieder eine aktuelle Nightly auf Basis des aktuellen Gluon Master Branch.
Ich werde die Tage aber wohl auch Experimental Firmware auf Basis des gestrigen Gluon Releases bauen.
OpenWRT müsste zwischen Release und master gleich sein. In master sind aber ein paar Gluon spezifische Neuerungen welche erst im nächsten Major Gluon Release landen werden weil sie nicht backported wurden.
Seit drei Tagen laufen auch die beiden Knoten Ladenburg-INTAKT-001 und Ladenburg-INTAKT-002 mit der Nightly Firmware.
Der nur per WLAN-Mesh angebundene Knoten Ladenburg-INTAKT-003, der zuerst diese Firmware bekam und zuvor 39 Tage durchgehalten hatte, ist seit gestern Abend genau um 20:00 nicht mehr erreichbar. Ohne Vor-Ort-Termin mit den Hausmeistern kann ich leider nichts machen.
Seit 2023-03-02 13:45 läuft Ladenburg-INTAKT-001 in einer geänderten Umgebung. Der Mobilfunkrouter wurde ausgetauscht gegen eine HyperBox 5G mit zwei Ethernet-Anschlüssen. Am zweiten Anschluss hängt ein neuer Knoten Ladenburg-INTAKT-005 (TP-Link TL-WR1043N v5). Beide Knoten sind per WLAN Mesh untereinander und mit weiteren Knoten verbunden und decken so den gesamten Nutzungsbereich gut ab.
Durch diese neue Konfiguration ist Ladenburg-INTAKT-001 auch dann noch über Ladenburg-INTAKT-005 per ssh erreichbar, wenn die Verbindung zum Gateway und der Reverse-SSH-Kanal ausgefallen sind, und kann so analysiert und manuell neu gestartet werden. Das war bereits einmal der Fall. Außerdem bleibt Freifunk funktionsfähig, wenn nur einer der Knoten am Mobilfunkrouter ausfällt.
Auffällig ist, dass auch der neue Knoten Ladenburg-INTAKT-005 mit anderer Hardware bereits dreimal neu gestartet ist, ohne dass es dafür einen ersichtlichen Grund gab. Allerdings gab es dabei keine längeren Unterbrechungen.
Der Knoten Ladenburg-INTAKT-001 fällt weiterhin häufig aus, ist aber zu meiner Überraschung meist noch per SSH / IPv6 erreichbar und kann so manuell neu gestartet werden. Zusätzlich ist er inzwischen über Ladenburg-INTAKT-005 per SSH / IPv4 erreichbar, so dass ich mich bisher bei jedem Ausfall irgendwie verbinden konnte.
Von den beiden weiteren Routern mit MT7915E im gleichen Mesh ist gestern Ladenburg-INTAKT-002 ausgefallen. Offenbar fallen die Router nach ihrer Nutzungshäufigkeit aus, was wieder ein Indiz für den WLAN-Treiber als Ursache ist.
Nach einem erneuten Firmware-Update auf Basis von gluon next (neuestes OpenWrt und mt76) lief der Knoten mit 18 Tagen eine neue Rekordzeit, musste dann aber manuell neu gestartet werden, weil wieder die timeout-Meldungen auftraten und der Uplink ausgefallen war. Allerdings gab es mit der neuen Firmware keine Verbindungen über owe mehr.
Das war im April. @TomH weiß das vermutlich genauer, aber es gab um die Zeit herum IIRC auch einen FW-Wechsel in Gluon für Geräte mit dieser Funk-Hardware? @sweil, ist denn mittlerweile alles Friede, Freude, Eierkuchen mit den ZyXEL NWA50AX, oder bereust Du die Wahl der Hardware?
Das kommt darauf an. Ich vermute, dass die Hardware ohne WLAN Mesh problemlos läuft. Aber in meiner Konstellation fällt sie immer noch sporadisch aus, zuletzt vor zwei Tagen nach immerhin 28 Tagen Dauerbetrieb und muss dann manuell neu gestartet werden. Meine Firmware von Anfang April hatte ich mit dem damals neuesten Stand von OpenWrt und Gluon gebaut. Mit der offiziellen Firmware traten die Ausfälle deutlich öfter auf.
Alles von scratch gebaut? Mal im docker container probiert? Ich habe bislang nur auf Systemen mit dem Software Stand von bullseye oder neuer gebaut.
$ ./openwrt/staging_dir/host/bin/autoconf -V
autoconf (GNU Autoconf) 2.71
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
<https://gnu.org/licenses/gpl.html>, <https://gnu.org/licenses/exceptions.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by David J. MacKenzie and Akim Demaille.
(mit dem gluon master branch war die version 2.69)
Yepp. Allerdings eingebunden in ein „Meta-Make“, was halt noch Gluon patcht. Und da kam dann merkwürdigerweise dies:
ffgt@kaos:~/build/gluon-ffgt-v2023.1/site-ffgt/gluon-build$ ~/build/gluon-ffgt-v2023.1/site-ffgt/gluon-build/openwrt/staging_dir/host/bin/autoconf -V
autoconf (GNU Autoconf) 1.6.0~4
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
<https://gnu.org/licenses/gpl.html>, <https://gnu.org/licenses/exceptions.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by David J. MacKenzie and Akim Demaille.
Mit v2022.1.x war auch 2.69 am Start.
ffgt@kaos:~/build/gluon-ffgt-v2023.1/site-ffgt/gluon-build$ ~/build/gluon-ffgt-v2022.1/site-ffgt/gluon-build/openwrt/staging_dir/host/bin/autoconf -V
autoconf (GNU Autoconf) 2.69
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>, <http://gnu.org/licenses/exceptions.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by David J. MacKenzie and Akim Demaille.
ffgt@kaos:~/build/gluon-ffgt-v2023.1/site-ffgt/gluon
Allerdings bringt auch der direkte Build von gluon-next23.05 „nur“ 2.69 bei mir?
ffgt@kaos:~/build/gluon-ffgt-v2023.1/site-ffgt/gluon-build$ ~/build/gluon-next23.05//openwrt/staging_dir/host/bin/autoconf -V
autoconf (GNU Autoconf) 2.69
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>, <http://gnu.org/licenses/exceptions.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by David J. MacKenzie and Akim Demaille.
Hallo Tom, Deinen Branch habe ich noch nicht getestet, dafür aber die 2.0.6-20230514. Die lief noch schlechter als frühere offizielle Firmware, wie man in der Statistikhistorie des Knotens Ladenburg-INTAKT-001 deutlich sieht.
Seid gestern läuft wieder eine selbstgebaute Firmware auf Basis von gluon next, bisher erfreulich gut. Auch owa und Mesh über 5 GHz funktionieren wieder, was bei früheren Versuchen mit gluon next nicht immer der Fall war.
Aktuell ist der nur in master/main von openwrt. Soweit ich das mitbekommen habe ist angedacht das der gebackported wird für Gluon v2023.1 (auf Basis von openwrt-22.03) das irgendwann demnächst mal kommen soll (einen Draft für Release Notes gibt es schon, gibt aber noch ein paar offene Punkte).
Muss aber natürlich noch jemand machen. Ich habe auch noch nicht geschaut wie kompliziert der Backport ist. Ebenfalls weiß ich gerade auch nicht was sonst noch relevant gewesen sein könnte.
Mein Branch mit dem Wechsel auf 23.05 wird dann vermutlich nachdem v2023.1.x von gluon master gebranched ist gemerged. Und das wird dann aller Voraussicht nach als Gluon v2023.2 veröffentlicht werden.
Das Ziel dahinter ist die Änderungen aus dem master Branch unter die Leute zu bringen ohne gleich auch noch einen Major OpenWrt Bump vornehmen zu müssen. Das sollte dann die halbwegs zügige Verbreitung von v2023.1 fördern.
@sweil Ich habe mal temporär einen neuen Firmware Branch angelegt der sich „unstable“ nennt. Die Firmware dort basiert auf dem Code aus meinem openwrt-23.05 PR #2920.
Genauer gesagt auf meinem next-23.05-new-device-support branch (das ist der PR Branch + noch ein wenig neuer Hardware Support).
Installieren lässt es sich folgendermaßen:
Erst den unstable Branch hinzufügen:
uci set autoupdater.unstable=branch
uci add_list autoupdater.unstable.mirror='http://fw.gluon.ffrn.de/unstable/sysupgrade'
uci set autoupdater.unstable.good_signatures='1'
uci set autoupdater.unstable.name='unstable'
uci add_list autoupdater.unstable.pubkey='e191158c837941158d827e5c6df971bfb01161d5d6f86a366d8a7897feedf9da'
uci commit autoupdater.unstable
Und dann die Firmware von diesem installieren:
uci set autoupdater.settings.branch=unstable
uci commit autoupdater.settings.branch
autoupdater
Ich würde noch nicht damit rechnen das es damit keine Probleme mehr gibt, aber es wäre gut zu wissen wie es damit aktuell aussieht.
Disclaimer: unstable ist noch wesentlich experimenteller als nightly und auch das wird ja schon ohne weitere Tests gebaut, signiert und hochgeladen. Es kann also jederzeit zu unvorhergesehenen Problemen kommen.
Danke. Der Knoten läuft seit ein paar Minuten mit dieser Firmware, zunächst unauffällig (inklusive der leider sehr häufigen Logmeldungen von airtime_link_metric_get). Ich bin gespannt!
Mit der selbstgebauten Firmware davor gab es gemischte Erfahrungen, zuerst 12 Tage lang ununterbrochener Betrieb bis zum Ausfall, danach aber eine Phase mit mehreren scheinbar unmotivierten Neustarts nach jeweils ein oder zwei Tagen Laufzeit.
Vor zwei Tagen ist der Knoten mit Toms Firmware wieder mit den üblichen Fehlermeldungen ausgefallen ([349497.324820] mt7915e 0000:02:00.0: Message 00005aed (seq 13) timeout). IPv4 funktionierte noch, ich konnte mich darüber per ssh verbinden, IPv4-Adressen im Internet anpingen und ihn neu starten. Name lookup funktionierte nicht.
