Ausfall Freifunk-Knoten mit unklarer Ursache

Technik
62

… und wieder war er vier Tage ausgefallen, was ich leider heute erst bemerkte. @TomH, damit muss ich leider feststellen, dass diese Firmware die Stabilität nicht verbessert. Immerhin muss ich dank der Ethernet-Verbindung zum Knoten Ladenburg-INTAKT-005 nur noch selten vor Ort gehen, um den Ladenburg-INTAKT-001 neu zu starten.

Übrigens zeigt auch der Ladenburg-INTAKT-005 Auffälligkeiten. Dieser TP-Link TL-WR1043N v5 fällt sehr oft aus (14 x in den letzten 24 Stunden), startet dabei aber glücklicherweise immer wieder neu und bleibt so erreichbar. Da aber das gesamte Mesh am ausgefallenen Ladenburg-INTAKT-001 und am ständig neu startenden Ladenburg-INTAKT-005 hängt, war die Nutzbarkeit in den letzten Tagen schon sehr beeinträchtigt. Im Juni lief Ladenburg-INTAKT-005 auch mal 13 Tage durch, aber lange Laufzeiten sind bei diesem Knoten eher die Ausnahme.

Momentan ist im Mesh noch ein ausgefallener Knoten (Ladenburg-INTAKT-003). Vermutlich sendet er immer noch seine SSID aus. Da sollte es doch im Prinzip funktionieren, einen der anderen Knoten als WLAN-Client mit dem ausgefallenen Knoten zu verbinden, um sich dann per SSH einzuloggen und den Knoten neu zu starten. Gibt es für so etwas schon eine Anleitung / hat das jemand schon mal gemacht?

63

Gestern um 13:33 neueste unstable Firmware von @TomH installiert, lief bis 17:32, dann wieder Ausfall mit bekannten timeout-Fehlermeldungen. Eben neu gestartet.

64

… und nach einer Stunde Laufzeit vorhin wieder ausgefallen.

65

Gibt es denn irgendwo einen Export dessen was du in der Konsole siehst?

66

Ja. Die Ausgaben von dmesg und logread beim letzten Ausfall stehen hier.

Ein sicherer Indikator für Ausfall ist immer diese Meldung mit timeout:

Fri Sep  1 11:55:28 2023 kern.err kernel: [ 7841.692065] mt7915e 0000:02:00.0: Message 00005aed (seq 2) timeout

Und oft sieht man auch sehr viele Prozesse und steigenden Speicherverbrauch im Kontext mit Meldungen dieser Art:

Fri Sep  1 11:55:48 2023 daemon.notice netifd: wan6 (2809): Command failed: ubus call network.interface notify_proto { "action": 0, "link-up": true, "data": { }, "keep": false, "ip6addr": [ { "ipaddr": "2a01:599:b04:1ac4:70a2:96ff:fecb:fe80", "mask": "64", "preferred": 14400, "valid": 86400, "offlink": true } ], "routes6": [ { "target": "::", "netmask": "0", "gateway": "fe80::a48a:acff:fe67:32b7", "metric": 640, "valid": 30 }, { "target": "2a01:599:b04:1ac4::", "netmask": "64", "metric": 256, "valid": 86400 } ], "dns": [ "fe80::a48a:acff:fe67:32b7" ], "interface": "wan6" } (Request timed out)
67

Sind die Probleme mit den NWA50AX noch existent?

Mit mt76: fix system recovery routine for MT7915 by blocktrron · Pull Request #3436 · freifunk-gluon/gluon · GitHub und einigen anderen Verbesserungen in mt76 habe ich auf NWA55AXE (ist die Outdoor Variante vom NWA50AX) jetzt in letzter Zeit keine Ausfälle mehr gesehen.
Es ist wohl noch nicht alles perfekt, aber mir scheint es auf APs die sonst oft Ausfälle hatten wesentlich besser. Genau genommen habe bislang keinen Ausfall oder Probleme mehr selbst gesehen.

Ich habe jetzt jedoch nicht geprüft ob die Fehler hier aus dem Log genau zu dem passen was nun alles behoben wurde.

Aber falls es noch Probleme gibt wäre jetzt wohl mal wieder ein guter Zeitpunkt zu schauen was der Stand ist.

Falls da Interesse besteht kann ich gerne mal schauen das ich eine aktuelle FFRN Firmware mit den Fixes baue und verlinke.

68

Leider ja. Schau dir mal die Uptime z. B. hier an: Grafana.

69

Ich habe eine neue nightly mit dem aktuellen Stand von gluon main als v2.3.x-20250325 getagged.

Den Build Fortschritt sieht man hier: Merge pull request #40 from Freifunk-Rhein-Neckar/bump-2.3 · Freifunk-Rhein-Neckar/site-ffrn@725099e · GitHub

Das sollte dann theoretisch (wenn noch alles funktioniert, die letzte nightly ist ja schon wieder etwas her :D) automatisch auf dem Firmware Server landen und von den nightly Knoten wenn es vor 04:00 fertig ist (denke nicht dass das passieren wird) direkt zwischen 4 und 5 Uhr installiert werden und sonst wird das morgen passieren.

Sobald es hochgeladen ist kann man es aber auch manuell mit dem autoupdater -f Befehl per ssh anstoßen wenn man nicht so lange warten möchte.

1 „Gefällt mir“
70

So. Der Firmware Build hat geklappt! :smile:

Sofortige Installation geht wie gesagt per autoupdater -f für Nodes welche dem nightly Branch folgen. Ich habe es schon mal probiert und es ist nicht direkt in die Luft geflogen.

71

FTR: sieht bislang ganz gut aus:

Es gibt noch andere mt76 Issues die ggf. ein Problem sein könnten. Zum Beispiel:

Aber momentan ist mein Eindruck das es so langsam wird. :slight_smile: