In Essen war nun an mehreren Standorten ein Neustart der uplinks erforderlich, damit Endgeräte ins Internet kamen.
Vorschlag:
Automatischer reboot um ca. 3 bis 5 Uhr nachts, um einem längeren Ausfall vorzubeugen.
@pberndro kann man nachvollziehen warum es in Essen gerade hängt?
Kurzer Zwischenruf:
Das Problem existiert hier auch. Wir haben ein kleines Script auf dem Router:
Ping an mehrere Supernodes, wenn keiner antwortet macht er einen reboot
"eigentlich"™ würde auch „ein batctl p“ auf das batman-gateway reichen und ein fastd- und ggf. network-restart.
Aber ehrlich gesagt ist da ein reboot einfach sinnvoller. Man sollte nur ein Flag setzen, dass den Reboot-Mechanismus erst scharf schaltet, wenn nach dem boot überhaupt einmal ein gateway erreichbar war.
(sonst würden „vorsätzlich“ als Insel betriebene Freifunk-Nodes in einer boot-loop stecken.)
Das Problem scheint in Essen nur bei Knoten aufzutreten, die sehr viel Traffic durchschieben.
Es scheint nicht an fastd, sondern an BATMAN zu liegen, da es auch Router betrifft, die nur per Mesh-on-LAN angeschlossen sind. Habe die Vermutung, dass es mit einem hohen Packet Loss wahrscheinlicher wird.
In einem Flüchtlingsheim war die Notlösung Schaltzeituhren anzubringen, damit die Knoten wenigstens einmal pro Tag neugestartet werden, falls mal wieder einer abstürzt.
@stefan Funktioniert das Script mit dem Ping wirklich zuverlässig? Als einer der Mesh-on-LAN-Knoten abgeschmiert ist, wurde mir nämlich berichtet, dass die LEDs „eingefroren“ sind. Das hat für mich nicht wie ein Problem ausgesehen, dass man mit einem Userland-Script fixen könnte, sondern eher nach einer Kernel-Panic der übelsten Sorte…
Beschreibe das Problem bitte anhand der Symptome (mehr als „Router geht nicht mehr richtig“), dann könnte man da forschen.
Welcher Firmwarestand?
Ich würde einen versuch mit einer 2015.2-experimental machen, da im Openwrt Upstream einiges geändert wurde hinsichtlich des Umgangs mit RAs.
Symptom: Der Router hört spontan auf BATMAN-Traffic zu verarbeiten und irgendwann funktioniert nur noch der Switch (WLAN tot, LED-trigger tot, eben ganzer Kernel tot), aber es findet kein Reboot statt.
Der gleiche Fehler ist auch bei einem Router, der so gut wie nie einen Client hat, aufgetreten (auch LEDs eingefroren, kein Netzwerkverkehr mehr). Aber der lief vorher nen Monat am Stück.
Im Flüchtlingsheim haben wir so einen Absturz alle 2-3 Tage…
Mehr kann ich dazu nicht sagen, weil man dann auch nicht mehr auf den Router zugreifen kann.
Reproduzierbarkeit macht das Debuggen noch schwieriger. Man hat nicht überall 40 Clients pro AP und da will man ja eigentlich nicht andauernt dran rumbasteln.
Der Fehler tritt immer noch beim aktuellen Master auf.
Dann versucht mal, remote eingelogt ein
logread -f
offen zu lassen, in der Hoffnung, dann noch etwas premortem zu bekommen.
(vielleicht ein SSH mit keepalives, damit der auch merkt, wenn die TCP-Session stirbt.)
Mein Tipp: Überlaufende Tabellen, die sich schon vorher mit malloc-Meldungen ankündigen.
Darauf könnte man den reboot triggern.
Die uplinks hier waren noch fleißig am blinken und wirkten von außen völlig normal. WLAN FF ging ja auch noch. Es fehlte halt die Verbindung zum supernode. Es kommt (leider) nicht mehr vor gerade, sodass ich nicht mit debuggen kann.
Hab ich mal gestartet. Kann aber ziemlich lange dauern, bis der Fehler wieder auftritt, wegen dem dirty fix mit der Zeitschaltuhr.
Waren die Knoten schon einige Stunden nicht mehr erreichbar?
Bei mir schmiert auch zuerst BATMAN ab und WLAN läuft noch und nach ein paar Stunden hängt er sich dann richtig auf…
Ansonsten haben wir hier vielleicht zwei verschiedene Fehler.
Mindestens 4h. Ich werde drauf achten.
Während ein android phone keine IP bekommt liefert ein logread -f hier konstant(wiederholt sich alle paar sec!):
Sun Oct 18 15:44:13 2015 daemon.info dnsmasq[1646]: using local addresses only for domain lan
Sun Oct 18 15:44:13 2015 daemon.info dnsmasq[1646]: using nameserver 2a03:2260:1005::32#53
Sun Oct 18 15:44:13 2015 daemon.info dnsmasq[1646]: using nameserver 2a03:2260:1005::24#53
Sun Oct 18 15:44:13 2015 daemon.info dnsmasq[1646]: using nameserver 2a03:2260:1005::16#53
Sun Oct 18 15:44:13 2015 daemon.info dnsmasq[1646]: using nameserver 2a03:2260:1005::8#53
Sun Oct 18 15:44:19 2015 daemon.info dnsmasq[1646]: reading /tmp/resolv.conf.auto
Sun Oct 18 15:44:19 2015 daemon.info dnsmasq[1646]: using local addresses only for domain lan
Sun Oct 18 15:44:19 2015 daemon.info dnsmasq[1646]: using nameserver 2a03:2260:1005::32#53
Sun Oct 18 15:44:19 2015 daemon.info dnsmasq[1646]: using nameserver 2a03:2260:1005::24#53
Sun Oct 18 15:44:19 2015 daemon.info dnsmasq[1646]: using nameserver 2a03:2260:1005::8#53
Sun Oct 18 15:44:25 2015 daemon.info dnsmasq[1646]: reading /tmp/resolv.conf.auto
Sun Oct 18 15:44:25 2015 daemon.info dnsmasq[1646]: using local addresses only for domain lan
Sun Oct 18 15:44:25 2015 daemon.info dnsmasq[1646]: using nameserver 2a03:2260:1005::32#53
Sun Oct 18 15:44:25 2015 daemon.info dnsmasq[1646]: using nameserver 2a03:2260:1005::24#53
Sun Oct 18 15:44:25 2015 daemon.info dnsmasq[1646]: using nameserver 2a03:2260:1005::8#53
Sun Oct 18 15:44:25 2015 daemon.info dnsmasq[1646]: using nameserver 2a03:2260:1005::16#53
Nach einem Neustart kommen die Meldungen etwas seltener aber dennoch konstant… Soll das so sein?
Interessant… Ich bekomme auch die ganzen dnsmasq-Meldungen, aber ich dachte das hängt mit den ganzen Clients die sich an/abmelden zusammen:
Mon Aug 31 12:48:05 2015 daemon.info dnsmasq[1377]: reading /tmp/resolv.conf.auto
Mon Aug 31 12:48:05 2015 daemon.info dnsmasq[1377]: using local addresses only for domain lan
Mon Aug 31 12:48:05 2015 daemon.info dnsmasq[1377]: using nameserver 2a03:2260:1005::24#53
Mon Aug 31 12:48:05 2015 daemon.info dnsmasq[1377]: using nameserver 2a03:2260:1005::32#53
Mon Aug 31 12:48:05 2015 daemon.info dnsmasq[1377]: using nameserver 2a03:2260:1005::8#53
Mon Aug 31 12:48:05 2015 daemon.info dnsmasq[1377]: using nameserver 2a03:2260:1005::16#53
Mon Aug 31 12:48:15 2015 daemon.info hostapd: client0: STA 18:3a:2d:21:9b:af IEEE 802.11: disassociated
Mon Aug 31 12:48:16 2015 daemon.info hostapd: client0: STA 18:3a:2d:21:9b:af IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mon Aug 31 12:48:17 2015 daemon.info hostapd: client0: STA 18:3a:2d:21:9b:af IEEE 802.11: authenticated
Mon Aug 31 12:48:17 2015 daemon.info hostapd: client0: STA 18:3a:2d:21:9b:af IEEE 802.11: associated (aid 12)
Mon Aug 31 12:48:19 2015 daemon.info dnsmasq[1377]: reading /tmp/resolv.conf.auto
Mon Aug 31 12:48:19 2015 daemon.info dnsmasq[1377]: using local addresses only for domain lan
Mon Aug 31 12:48:19 2015 daemon.info dnsmasq[1377]: using nameserver 2a03:2260:1005::24#53
Mon Aug 31 12:48:19 2015 daemon.info dnsmasq[1377]: using nameserver 2a03:2260:1005::32#53
Mon Aug 31 12:48:19 2015 daemon.info dnsmasq[1377]: using nameserver 2a03:2260:1005::16#53
Mon Aug 31 12:48:22 2015 daemon.info hostapd: client0: STA 70:11:24:c8:73:75 IEEE 802.11: disassociated due to inactivity
Mon Aug 31 12:48:23 2015 daemon.info hostapd: client0: STA 5c:0a:5b:d9:9a:1b IEEE 802.11: disassociated
Mon Aug 31 12:48:23 2015 daemon.info hostapd: client0: STA 70:11:24:c8:73:75 IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mon Aug 31 12:48:24 2015 daemon.info hostapd: client0: STA 5c:0a:5b:d9:9a:1b IEEE 802.11: deauthenticated due to inactivity (timer DEAUTH/REMOVE)
Mon Aug 31 12:48:25 2015 daemon.info dnsmasq[1377]: reading /tmp/resolv.conf.auto
Mon Aug 31 12:48:25 2015 daemon.info dnsmasq[1377]: using local addresses only for domain lan
Mon Aug 31 12:48:25 2015 daemon.info dnsmasq[1377]: using nameserver 2a03:2260:1005::24#53
Mon Aug 31 12:48:25 2015 daemon.info dnsmasq[1377]: using nameserver 2a03:2260:1005::32#53
Mon Aug 31 12:48:25 2015 daemon.info dnsmasq[1377]: using nameserver 2a03:2260:1005::16#53
Mon Aug 31 12:48:25 2015 daemon.info dnsmasq[1377]: using nameserver 2a03:2260:1005::8#53
hmm… dann warten wir mal ab, was passiert.
(Von irgendwelchen dnsmasq-Meldungen nicht irre machen lassen, das Ding ist geschwätzig. Und dnsfails sind völlig normal, oder zumindest hier vermutlich nicht ursächlich.)
Gibt es hier neue Erkenntnisse?
Muss auch öfter’s den Router neu starten weil ein verbinden mit dem Freifunk-WLAN nicht möglich ist obwohl dieses noch angezeigt wird.
Tritt bei meinem 4300’er aber bisher nur bei 2,4GHz auf, 5GHz funktioniert dann i.d.R. noch.
Die nachgelagerten Kommunikations- und Verbindungsprobleme bestehen aber auch weiterhin.
Das hat aber nichts mit mit dem beschriebenen Fehlerbild zu tun, oder?
Seid’s mir bitte nicht böse, wenn ich inzwischen etwas gereizt reagiere auf diese „Router geht nicht“-Meldungen.
Frage ist immer:
Cyclic-Boot? Freeze?
Systematisch? Sporadisch?
Schlechte Performance? Totalausfall?
Local? HeadEnd?
Nicht dass das Problem dadurch irgendwie „besser“ oder „weniger“ würde.
Aber wenn die Schwierigkeiten systematisch dahingehend übertrieben werden als „Mein Router stürzt ab“.
Und nach ewigem Diagnostizieren bleibt immer bei übrig: „Internet ist in wirklichkeit nur unbenutzbar langsam oder nicht verfügbar. Und es rührt vom Gateway her, Router-Restart hat dann 50:50-Chance, einen anderen Supernode zu erwischen“: Dann ist es zumindest für mich frustrierend, weil ich mich jedes Mal verarscht vorkomme.
(Es betrifft jetzt NICHT diesen Thread, Aber ich schreibe es bewusst mal hier, da es in anderen sonst evtl. „persönlich“ genommen wird vom jeweiligen Threadstarter)
Es sei hier auch nochmal verwiesen auf
Unterschiedliche Fehlerbilder auf 2.4 und 5GHz deutet übrigens auf Broadcast-Stürme in der Domain (und aufgebrauchte Airtime) hin.
Sei mir nicht böse 
aber Deine Kommentare sind auch absolut nicht hilfreich.
Der Threadstarter merkte an, „In Essen war nun an mehreren Standorten ein Neustart der uplinks erforderlich, damit Endgeräte ins Internet kamen.“
Das ist in der Tat auch bei mir der Fall und selbst wenn nicht, so muss doch eine Rückfrage nach neuen Erkenntnissen nach 6 Tagen ohne Aktivität in diesem Thread wohl erlaubt sein, oder nicht?!?
Und warum sollten Broadcast-Stürme (und/oder aufgebrauchte Airtime) nach einem Reboot plötzlich nicht mehr existent sein?
Problem scheint also zu sein, dass entweder
Welches der 3 Probleme (vielleicht sind es mehr?) nun trifft: Man kann natürlich per Router-Reboot Routlette spielen.
Oder man versucht auf der Konsole, die 3 Möglichkeiten manuell abzuklappern.
Also: Bei manifestierter Störung lokale fastd.conf ändern und
Reconnect auf den gleichen Server durchführen,
Reconnect auf anderen Server durchführen.
oder aber
Batman auf ein anderes gateway zwingen
batman neu starten, aber das gleiche Gateway connecten
batman neu starten, aber auf ein anderes Gateway.
Ich habe mich dann mal durch den oben verlinkten Artikel gehangelt …
ping nextnode IPv6: ok
ping nextnode IPv4: ok
Gateways: 4 vorhanden, 4 pingbar
ping6 2001:4860:4860::8888 ok
ping6 www.google.com ok
ping globale IPv6 des Freifunk-Routers ok
ping lokale IPv6 des Freifunk-Routers ok
Abweichung zur Anleitung:
Im Block „bat0“ ist keine globale IPv6 sondern nur die lokale
Im Block br-client sind beide Einträge vorhanden
Logfile für mich als Anfänger ohne Befund außer das permanent (alle paar Sekunden) die Einstellungen neu gelesen werden:
Tue Nov 17 20:36:51 2015 daemon.info dnsmasq[1832]: reading /tmp/resolv.conf.auto
Tue Nov 17 20:36:51 2015 daemon.info dnsmasq[1832]: using local addresses only for domain lan
Tue Nov 17 20:36:51 2015 daemon.info dnsmasq[1832]: using nameserver 2a03:2260:1005::32#53
Tue Nov 17 20:36:51 2015 daemon.info dnsmasq[1832]: using nameserver 2a03:2260:1005::24#53
Tue Nov 17 20:36:51 2015 daemon.info dnsmasq[1832]: using nameserver 2a03:2260:1005::16#53
Tue Nov 17 20:36:51 2015 daemon.info dnsmasq[1832]: using nameserver 2a03:2260:1005::8#53
Googlesuche funktioniert, Verbindung zu verlinkten Suchergebnissen jedoch nicht (Zeitüberschreitung) oder nur sehr langsam, WhatsApp in Reconnect-Schleife
Das kling dann nach einem Problem im Backbone. (Und dem Zufall per Reboot bei einem anderen Supernode zu landen, der gerade anders zu Backbone routet.)
Klingt danach als wenn die supernodes in Essen wieder fröhlich reboot bingo spielen, aber laut Philipp ist alles ok 
Lasst doch mal einen ping auf die 4 laufen und achte auf kleine Ausfälle, die booten relativ fix.