Problemrouter mesht nur noch einseitig(watchdog?)

Ich habe hier schon gelesen, dass das wohl ab zu zu auf Problemroutern WiFi Probleme gibt.
Das tritt auch nur sehr selten auf, früher hatte ich das mal auf meinen 3600, so 2-3 mal im Monat.

Jetzt haben wir aber hier einen stark belasteten Uplink Router in einer Unterkunft.

Der Router sendet dann keine Pakete mehr an die anderen, empfängt aber fleißig weiter. Das passiert aber jetzt fast (auch mehrfach) täglich und nervt. Da jeweils die oberen Etagen kein Netz mehr haben.

Behoben kann es werden kann es mit „wifi“ oder einen wlan scan, nach einiger Zeit natürlich auch durch die Bewohner vor Ort per Stecker raus/rein. :frowning:

Nun zur Frage, wenn ich jetzt einfach alle 60 Sekunden einen Hintergrund wlan scan mache, läuft es dann oder handel ich mir damit andere Probleme ein?
Beeinflusst so ein wlanscan den normalen Datenverkehr intensiv, so dass man es womöglich noch öfters machen kann?
Gibt es noch eine elegantere Lösung?

Nimm einfach eines der vielen Watchdog-Pakete, die in den verschiedenen Communites im Einsatz sind.
Ich will jetzt keines besonders empfehlen, weil schließlich alle Vor- und Nachteile haben und auch weder meines, noch PetaByteBoys noch das von Rüben „das Beste“ sind.
Beurteile halt selbst, in welcher Tiefe Du die Checks haben willst, wie lang der Fehlerzustand andauern soll, bevor harte Maßnahmen (reboot) gemacht wird, wieviel false-Positives Du zu tolerieren bereit bist, respektive, wie volatil das Netz ist, wo Environment-Aenderungen so normal sind, dass darauf nicht mit Reboot geantwortet werden soll von Knoten, die sich plötzlich aller ihrer Wifimesh Partner, oder ihrer Lan Meshpartner beraubt sehen.
Oder bei denen es normal ist, dass Ethernet-Ports down gehen im laufenden Betrieb. Oder die wiederholt kein einziges Batman-Gateway mehr sehen konnten. Oder zwar das Batman-Gw noch sehen, aber keinen einzigen Supernode per IPv6 mehr sehen.

(Ja, das sind alles Fehlerzustände, die real auftreten können, wenn man nur genügend Router im Blickfeld hat, die auch alle in einem kaskadierten Mesh irgendwie „wichtig“ sind, bei einem Ausfall also mehr also mehr als nur die eigenen lokalen Clients beeinträchtigen. Und sei es, dass sie zwar die Kernaufgabe noch erfüllen, aber schlicht nichts mehr reporten und auf die man sich selbst auf der Link lokal nicht einloggen kann.)

1 Like

Danke dir. Habe gerade festgestellt, das bei uns schon einiges gecrownjobt wird. Leider das einseitige Mesh abreisen (noch) nicht.

Leider sind die o.g. wachtdogs nur sehr mühlselig zu finden. @PetaByteBoy @rubo77 (Rüben?) @adorfer, möchtet ihr mir was verlinken oder per pn zukommen lassen? Sicherlich muss da für unseren Fall noch was angepasst werden, aber da muss ich mich erst einmal einlesen. Aber zu Ideenfindung finde ich unsere Metacomunity super, vielleicht fällt uns ja noch etwas auf, was wir bis heute noch gar nicht auf dem Schirm haben. :wink:

Wie du schon gemerkt hast muss da ggf. einiges angepasst werden.

2 Likes

Also Ich Heiße Ruben (Auto korrektet. Rüben :smiley:) Es gibt aber noch einen anderen Ruben Klevera oder so hier.
Wir nutzen in Freifunk Nord auch das von Eulen Funk. Ist allerdings für gluon.

Google mal nach „Freifunk Watchdog GitHub“

1 Like

Autokorrektur :joy: Ich war mir nicht sicher :wink: @RubenKelevra

Danke, das hat mir schon geholfen. Viel musste nicht angepasst werden, außer die Interface wohl anders heißen und wir keinen respondd und gluonbug haben.

Sehr elegant geschrieben, keine pauschaler iw scan.
Bin mir nur noch nicht sicher ob es mir auch hilft, denn die Org-Pakete werden ja empfangen, die „Nachbarn sind also da“.

Dann werde ich die Abfrage mal erweitern und direkt bmxd nach der Verbindungsqualität befragen. Der Bug scheint heute nicht auftreten zu wollen… :\

Der Vollständigkeit halber, bin dem Fehler auf die Schliche (hat sich heute keiner dazu durchringen können, den Stecker zu ziehen) gekommen:

[40.350000] random: nonblocking pool is initialized
[38480.290000] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02100020 DMADBG_7=0x00024300
[40580.230000] ath: phy0: DMA failed to stop in 10 ms AR_CR=0x00000024 AR_DIAG_SW=0x02100020 DMADBG_7=0x00024300

wifi behebt diesen Fehler sofort.

[62155.510000] device wlan0-1 left promiscuous mode
[62155.510000] br-wifi2: port 1(wlan0-1) entered disabled state
[62156.660000] device wlan0-1 entered promiscuous mode
[62156.660000] br-wifi2: port 1(wlan0-1) entered forwarding state

Scheinbar gabs einen ähnlichen Fehler schon mal vor 5 Jahren (bei Heavys Loads) und er zieht sich bis heute hin,…
OpenWrt Faden: #9654 (ath: DMA failed to stop in 10 ms) – OpenWrt

Oder meint ihr es ist sicherer einen Reboot durchzuführen == Generell bei Kernel Geschichten?

Liest sich nach dem üblichen ath9-Wifibug, z.B unter TP-Link CPE210 unter Gluon instabil. Dort sind auch Links zu scripten die abgestuft verschiedene Lösungsansätze testen und wenn die nicht helfen einen reboot durchführen.

1 Like