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.
Also die Fehlerbeschreibung kann ich für die von mir betreuten Standorte weiterhin aufrecht erhalten. Endgeräte kommen regelmäßig nur nach einem reboot der FF-Knoten ins Netz. Im fehlerhaften Zustand sind meistens gar keine oder nur 1 supernode aus dem FF Client Netz zu erreichen. Die Knoten sind jedoch durchgängig auf der Karte mit Clients sichtbar.
Nach einem Reboot funktioniert dann erst einmal wieder „alles“. (Auch nach dem reboot geht z.B. Google Play nicht, aber das ist ein anderes Thema, siehe hier im Forum)
Nach 2 Wochen ist das Bild unverändert. Da das Problem anscheinend nur bei mir existiert bin ich erstmal raus hier und beobachte die FF-E Entwicklung passiv weiter.
Falls sich das Problem dennoch bei jemandem zeigt nutzen vielleicht folgende 2 traceroutes:
Ein fehlerhafter uplink liefert diesen traceroute:
Ein neugestarteter und funktionierender diesen:
Auf node01-1 hing Bird in den Fritten, nach einem Neustart sieht es gut aus und die Kisten Routen auch wieder Traffic.
@apo: Was sagen deine Knoten?
Unschön, hat aber nichts mit dem beschriebenen Problem zu tun.
Ich denke, das ich das gleiche Problem habe. Ich kann über freifunk die internen Dienste, wie das Forum und den Meshviewer erreichen, aber nux im Internet.
Mein Traceroute sieht so wie oben beschrieben aus:
/usr/sbin/traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 10.228.32.1 (10.228.32.1) 26.746 ms 28.482 ms 31.146 ms
2 10.228.16.1 (10.228.16.1) 320.501 ms 321.601 ms 321.573 ms
3 100.64.0.244 (100.64.0.244) 321.539 ms 322.677 ms 322.649 ms
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
Meine Tunnel sehen so aus:
VPN status
fastd running for 151620.532 seconds
There are 4 peers configured, of which 2 are connected:
mesh_vpn_backbone_1_peer_node02: not connected
mesh_vpn_backbone_1_peer_node01: connected for 151578.673 seconds
mesh_vpn_backbone_2_peer_node01: not connected
mesh_vpn_backbone_2_peer_node02: connected for 151580.017 secondsWeshalb tauchen denn da an Position 1 und 2 zwei mal supernodes auf? Ich dachte bisher, dass immer über einen geroutet wird.