Verbindungsabbrüche / Fragen zur Meshkonfiguration

Guten Morgen,

vielleicht habt Ihr ja noch eine Idee.

Mir ist aufgefallen, dass ab irgendeinem Zeitpunk anscheinend keine Daten mehr übertragen werden. Will heißen meine die beiden 1043 sind online (Laut Karte), aber wenn ich versuche, Webseiten zu öffnen gibt es irgendwann einen Timeout.
Starte ich die Router neu, geht es wieder.

Aufbau: 1043 Nr. 1 hängt am Lan4 (Gästenetzwerk) der Fritzbox und hat zwei WLAN-Mesh aufgebaut (mit dem Router eines Nachbarn und mit 1043 Nr. 2).
1043 Nr. 2 habe ich aktuell nicht mehr am Lan bzw. VPN, weil ich mir gedacht habe, es ist sinnvoller eine VPN-Verbindung mit höherer Bandbreite aufzubauen, statt zwei mit niedriger.

Was sagt denn ein logread auf den Knoten? Scheinbar scheint ja die VPN-Verbindung abzubrechen, vielleicht findet sich da ein Hinweis auf die Ursache.

Probier ich aus wenn es das nächste mal ausfällt.
Ich richte mal ssh ein ^^.

P.S. Ich bin noch nicht so tief im Thema drin

Also ich habe ein bisschen weiter getestet. Meshing erst mal komplett aus. Dann beide einzeln getestet. keine Probleme. Sobald beide gleichzeitig an sind Will es nicht mehr.

Kann es sein das ich mich selber zublase Wlan mäßig? Die beiden stehen nur ca. 10m auseinander und nutzen den gleichen Kanal?

P.S. habe die Config mal auf Lede angepasst und es auch kompiliert bekommen :smile:

1 „Gefällt mir“

-v

Eigentlich sollten zwei Router auf dem gleichen Kanal noch normal funktionieren wenn auch mit verringerten Geschwindigkeiten. Die Router müssen ja den gleichen Kanal benutzen damit sie überhaupt miteinander reden können.

Frage mich gerade was passiert wenn ein Client (in dem Fall Ich mit meinem Handy) immer wieder zwischen den beiden wechselt.

Ich bin hier so gesehen voll flexibel mit meinem Aufbau. mein Lan liegt in beiden Räumen. Ich kann wie im Moment mit 2xVPN-Mesh-Verbindungen arbeiten (je halbe Bandbreite eingestellt). Ich könnte 1xVPN-Mesh(doppelte Bandbreite) aufbauen und die Beiden Router per WLAN-Mesch verbinden, oder per Lan-Mesh.

Wobei ich hier noch das Problem mit einem Port zu wenig habe. Kann ich bei einem Router WAN-Mesch anmachen beim anderen Lan-Mesh?

P.S. @system, @MPW, @Markus, @stefan, @Florian, @jbacksch, @anon68922371 : sollten das hier abgespalten werden, wird glaube ich etwas offtopic?

Hab ich mal eben gemacht. Du kannst gerne die Überschrift noch anpassen.

Wenn eh ein Kabel liegt, ist das die einzig vernünftige Option. WLAN-Masch ist auch schön, aber Kabel ist doch besser. Und bitte nicht einfach zwei mal VPN-Einwahl machen. Das belastet die Gateways unnötig. Wenn es einer macht, ist es quasi egal, aber wenn es jeder macht, bräuchte man deutlich mehr Gateways. Denn leider ist nicht nur der Durchsatz ein limitierender Faktor, sondern scheinbar auch die Anzahl der aktiven VPN-Verbindungen. Ist zumindest bei uns so. Außerdem verdoppelt sich auch das Grundrauschen auf deiner Internetleitung.

Vielen Dank fürs verschieben :smile:

Ich probier mal aus ob WAN to LAN Mesh funktioniert, sonst muss ich mal suchen wo ich meine Owncloud hinstelle ^^.

P.S. Teste gerade: Router 1 mit doppelter Bandbreite im VPN, mit WAN to LAN Mesh zu Router 2. WLAN Mesh bei beiden aus.

P.P.S. Problem bleibt das Gleiche, sobald beide WLANs an sind bekomme ich einfach keine Webseiten mehr auf.

P.P.P.S. Jetzt bin ich mit meinem Latein am Ende, Jetzt habe ich bei Router1 das Client- und Mesh-Wlan komplett abgeschaltet. Das Problem bleibt.

@DevilX ich denke du solltest ein wenig detailliertere Informationen sammeln, um festzustellen, wo das Problem eigentlich liegt.
Kannst du von Router1 die Link-Local-IPv6 auf dem mesh0/ibss0-Interface von Router2 pingen?
Wenn ja: Kannst Router1 die IPv6 auf bat0 von Router2 pingen?
Wenn ja: Kannst du vom Client aus das Gateway pingen?
Wenn ja: traceroute zu 8.8.8.8?

1 „Gefällt mir“

@PetaByteBoy Danke,

werden ich testen. Jetzt steht erst mal offline leben an ;-). Kann also etwas dauern.

Wir sind hier wieder bei

Selbstverständlich können wir gerne, die einzelen Schritte „was man alles abprüfen kann“ hier nochmal interaktiv im Forum durcharbeiten.
Die einzelnen Schritte bitte ich trotzdem im verlinkten Wiki-Artikel nachzulesen.

(Andernfalls können wir uns an solchen Sätzen abarbeiten. Denn beim „anscheinend“ stimme ich vorbehaltlos zu, beim „keine Daten“ sollten wir dann Deine Definktion von „Daten“ besprechen. Führt nur vermutlich zu nix. Weil am Ende herauskommt, dass Deine Feststellung so nicht korrekt ist. Was aber nichts an der Tatsache ändert, dass Du da einen Freifunkknoten mit schlechter Userexperience hast. Und das wird der Kern sein, den es zu hinterfragen gilt, nicht Deine vermutlich mindestens teilweise falschen Diagnosen.)

Ich werde mich mal an die Tipps / Artikel wagen sobald ich das Problem wieder reproduziert habe.
Vielen Dank schon mal.

Gestern Nacht war es das Problem da und ich habe keine Webseite auf bekommen. Als ich mich heute Morgen ans Debuggen machen wollte, ging wieder alles. Ich habe nichts neugestartet o.ä. bin gerade etwas irritiert.

Ich habe gestern Nacht allerdings noch vom Client aus einen Ping auf verschiedene Webseiten gemacht, der Anstandslos durch ging. Aber die Webseiten im Browser wollten nicht. Da kann ich mir gerade nicht so recht einen Reim drauf machen.

@adorfer ich weiß schon, wieso ich anscheinend schreibe, dass alles nur Indizien sind die ich beobachtet habe und das ich bis jetzt nichts Stichhaltiges.

Im Moment:
Vom Client: Ping IPV4 Nextnode OK, IPV6 Nextnode OK,
Gateway 1 OK (~25ms), Gateway 2 OK ( ~300ms), Gateway 3 OK (85 ms)
Gerät 1: ping6 2001:4860:4860::8888: = 150 ms
Gerät 1: ping6 www.google.com = ~150 ms
Gerät 2: ping6 2001:4860:4860::8888: = 160 ms
Gerät 2: ping6 www.google.com = ~160 ms
ping -6 auf Gerät 1: ~100ms
ping -6 auf Gerät 2: ~180ms

Logread Gerät 1:

Wed Apr 12 14:11:12 2017 daemon.info fastd[1692]: 151.80.64.185:10000 authorized as <mesh_vpn_backbone_peer_node02>
Wed Apr 12 14:11:12 2017 daemon.info fastd[1692]: new session with <mesh_vpn_backbone_peer_node02> established using method `salsa2012+umac'.
Wed Apr 12 15:02:49 2017 daemon.info fastd[1692]: refreshing session with <mesh_vpn_backbone_peer_node02>
Wed Apr 12 15:02:49 2017 daemon.info fastd[1692]: sending handshake to <mesh_vpn_backbone_peer_node02>[151.80.64.185:10000]...
Wed Apr 12 15:02:49 2017 daemon.info fastd[1692]: received handshake response from <mesh_vpn_backbone_peer_node02>[151.80.64.185:10000] using fastd v17
Wed Apr 12 15:02:49 2017 daemon.info fastd[1692]: 151.80.64.185:10000 authorized as <mesh_vpn_backbone_peer_node02>
Wed Apr 12 15:02:49 2017 daemon.info fastd[1692]: new session with <mesh_vpn_backbone_peer_node02> established using method `salsa2012+umac'.
Wed Apr 12 15:54:52 2017 daemon.info fastd[1692]: refreshing session with <mesh_vpn_backbone_peer_node02>
Wed Apr 12 15:54:52 2017 daemon.info fastd[1692]: sending handshake to <mesh_vpn_backbone_peer_node02>[151.80.64.185:10000]...
Wed Apr 12 15:54:52 2017 daemon.info fastd[1692]: received handshake response from <mesh_vpn_backbone_peer_node02>[151.80.64.185:10000] using fastd v17
Wed Apr 12 15:54:52 2017 daemon.info fastd[1692]: 151.80.64.185:10000 authorized as <mesh_vpn_backbone_peer_node02>
Wed Apr 12 15:54:52 2017 daemon.info fastd[1692]: new session with <mesh_vpn_backbone_peer_node02> established using method `salsa2012+umac'.
Wed Apr 12 16:49:45 2017 daemon.info fastd[1692]: refreshing session with <mesh_vpn_backbone_peer_node02>
Wed Apr 12 16:49:45 2017 daemon.info fastd[1692]: sending handshake to <mesh_vpn_backbone_peer_node02>[151.80.64.185:10000]...
Wed Apr 12 16:49:45 2017 daemon.info fastd[1692]: received handshake response from <mesh_vpn_backbone_peer_node02>[151.80.64.185:10000] using fastd v17
Wed Apr 12 16:49:45 2017 daemon.info fastd[1692]: 151.80.64.185:10000 authorized as <mesh_vpn_backbone_peer_node02>
Wed Apr 12 16:49:45 2017 daemon.info fastd[1692]: new session with <mesh_vpn_backbone_peer_node02> established using method `salsa2012+umac'.
Wed Apr 12 17:40:34 2017 daemon.info fastd[1692]: refreshing session with <mesh_vpn_backbone_peer_node02>
Wed Apr 12 17:40:35 2017 daemon.info fastd[1692]: sending handshake to <mesh_vpn_backbone_peer_node02>[151.80.64.185:10000]...
Wed Apr 12 17:40:35 2017 daemon.info fastd[1692]: received handshake response from <mesh_vpn_backbone_peer_node02>[151.80.64.185:10000] using fastd v17
Wed Apr 12 17:40:35 2017 daemon.info fastd[1692]: 151.80.64.185:10000 authorized as <mesh_vpn_backbone_peer_node02>
Wed Apr 12 17:40:35 2017 daemon.info fastd[1692]: new session with <mesh_vpn_backbone_peer_node02> established using method `salsa2012+umac'.
Wed Apr 12 18:35:28 2017 daemon.info fastd[1692]: refreshing session with <mesh_vpn_backbone_peer_node02>
Wed Apr 12 18:35:29 2017 daemon.info fastd[1692]: sending handshake to <mesh_vpn_backbone_peer_node02>[151.80.64.185:10000]...
Wed Apr 12 18:35:29 2017 daemon.info fastd[1692]: received handshake response from <mesh_vpn_backbone_peer_node02>[151.80.64.185:10000] using fastd v17
Wed Apr 12 18:35:29 2017 daemon.info fastd[1692]: 151.80.64.185:10000 authorized as <mesh_vpn_backbone_peer_node02>
Wed Apr 12 18:35:29 2017 daemon.info fastd[1692]: new session with <mesh_vpn_backbone_peer_node02> established using method `salsa2012+umac'.
Wed Apr 12 19:27:32 2017 daemon.info fastd[1692]: refreshing session with <mesh_vpn_backbone_peer_node02>
Wed Apr 12 19:27:32 2017 daemon.info fastd[1692]: sending handshake to <mesh_vpn_backbone_peer_node02>[151.80.64.185:10000]...
Wed Apr 12 19:27:32 2017 daemon.info fastd[1692]: received handshake response from <mesh_vpn_backbone_peer_node02>[151.80.64.185:10000] using fastd v17
Wed Apr 12 19:27:32 2017 daemon.info fastd[1692]: 151.80.64.185:10000 authorized as <mesh_vpn_backbone_peer_node02>
Wed Apr 12 19:27:32 2017 daemon.info fastd[1692]: new session with <mesh_vpn_backbone_peer_node02> established using method `salsa2012+umac'.
Wed Apr 12 20:19:28 2017 daemon.info fastd[1692]: refreshing session with <mesh_vpn_backbone_peer_node02>
Wed Apr 12 20:19:28 2017 daemon.info fastd[1692]: sending handshake to <mesh_vpn_backbone_peer_node02>[151.80.64.185:10000]...
Wed Apr 12 20:19:28 2017 daemon.info fastd[1692]: received handshake response from <mesh_vpn_backbone_peer_node02>[151.80.64.185:10000] using fastd v17
Wed Apr 12 20:19:28 2017 daemon.info fastd[1692]: 151.80.64.185:10000 authorized as <mesh_vpn_backbone_peer_node02>
Wed Apr 12 20:19:28 2017 daemon.info fastd[1692]: new session with <mesh_vpn_backbone_peer_node02> established using method `salsa2012+umac'.
Wed Apr 12 21:11:45 2017 daemon.info fastd[1692]: refreshing session with <mesh_vpn_backbone_peer_node02>
Wed Apr 12 21:11:45 2017 daemon.info fastd[1692]: sending handshake to <mesh_vpn_backbone_peer_node02>[151.80.64.185:10000]...
Wed Apr 12 21:11:45 2017 daemon.info fastd[1692]: received handshake response from <mesh_vpn_backbone_peer_node02>[151.80.64.185:10000] using fastd v17
Wed Apr 12 21:11:45 2017 daemon.info fastd[1692]: 151.80.64.185:10000 authorized as <mesh_vpn_backbone_peer_node02>
Wed Apr 12 21:11:45 2017 daemon.info fastd[1692]: new session with <mesh_vpn_backbone_peer_node02> established using method `salsa2012+umac'.
Wed Apr 12 21:23:06 2017 daemon.notice netifd: client (1414): cat: write error: Broken pipe
Wed Apr 12 22:04:45 2017 daemon.info fastd[1692]: refreshing session with <mesh_vpn_backbone_peer_node02>
Wed Apr 12 22:04:45 2017 daemon.info fastd[1692]: sending handshake to <mesh_vpn_backbone_peer_node02>[151.80.64.185:10000]...
Wed Apr 12 22:04:45 2017 daemon.info fastd[1692]: received handshake response from <mesh_vpn_backbone_peer_node02>[151.80.64.185:10000] using fastd v17
Wed Apr 12 22:04:45 2017 daemon.info fastd[1692]: 151.80.64.185:10000 authorized as <mesh_vpn_backbone_peer_node02>
Wed Apr 12 22:04:45 2017 daemon.info fastd[1692]: new session with <mesh_vpn_backbone_peer_node02> established using method `salsa2012+umac'.
Wed Apr 12 22:57:40 2017 daemon.info fastd[1692]: refreshing session with <mesh_vpn_backbone_peer_node02>
Wed Apr 12 22:57:40 2017 daemon.info fastd[1692]: sending handshake to <mesh_vpn_backbone_peer_node02>[151.80.64.185:10000]...
Wed Apr 12 22:57:40 2017 daemon.info fastd[1692]: received handshake response from <mesh_vpn_backbone_peer_node02>[151.80.64.185:10000] using fastd v17
Wed Apr 12 22:57:41 2017 daemon.info fastd[1692]: 151.80.64.185:10000 authorized as <mesh_vpn_backbone_peer_node02>
Wed Apr 12 22:57:41 2017 daemon.info fastd[1692]: new session with <mesh_vpn_backbone_peer_node02> established using method `salsa2012+umac'.
Wed Apr 12 23:34:53 2017 kern.info kernel: [36896.420000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Port 5 is down
Wed Apr 12 23:35:03 2017 kern.info kernel: [36906.520000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Port 5 is up
Wed Apr 12 23:35:15 2017 kern.info kernel: [36918.640000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Port 5 is down
Wed Apr 12 23:35:21 2017 kern.info kernel: [36924.700000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Port 5 is up
Wed Apr 12 23:35:43 2017 kern.info kernel: [36946.920000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Port 5 is down
Wed Apr 12 23:35:45 2017 kern.info kernel: [36948.940000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Port 5 is up
Wed Apr 12 23:35:47 2017 user.notice firewall: Reloading firewall due to ifupdate of wan6 (br-wan)
Wed Apr 12 23:36:21 2017 daemon.notice fastd[1692]: connection with <mesh_vpn_backbone_peer_node02> disestablished.
Wed Apr 12 23:36:21 2017 daemon.info fastd[1692]: resolving host `sn-b.ov.lil.freifunk-essen.net' for peer <mesh_vpn_backbone_peer_node02>...
Wed Apr 12 23:36:30 2017 daemon.info fastd[1692]: resolving host `sn-a.ak.ber.freifunk-essen.net' for peer <mesh_vpn_backbone_peer_node03>...
Wed Apr 12 23:36:30 2017 daemon.info fastd[1692]: resolved host `sn-a.ak.ber.freifunk-essen.net' successfully
Wed Apr 12 23:36:31 2017 user.notice firewall: Reloading firewall due to ifupdate of wan6 (br-wan)
Wed Apr 12 23:36:35 2017 daemon.info fastd[1692]: resolving host `sn-a.ov.lil.freifunk-essen.net' for peer <mesh_vpn_backbone_peer_node01>...
Wed Apr 12 23:36:35 2017 daemon.info fastd[1692]: resolved host `sn-a.ov.lil.freifunk-essen.net' successfully
Wed Apr 12 23:36:36 2017 daemon.info fastd[1692]: resolving host `sn-b.ov.lil.freifunk-essen.net' failed: Name or service not known
Wed Apr 12 23:36:36 2017 daemon.info fastd[1692]: resolving host `sn-b.ov.lil.freifunk-essen.net' for peer <mesh_vpn_backbone_peer_node02>...
Wed Apr 12 23:36:36 2017 daemon.info fastd[1692]: resolved host `sn-b.ov.lil.freifunk-essen.net' successfully
Wed Apr 12 23:36:48 2017 daemon.info fastd[1692]: sending handshake to <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000]...
Wed Apr 12 23:36:48 2017 daemon.info fastd[1692]: resolving host `sn-a.ak.ber.freifunk-essen.net' for peer <mesh_vpn_backbone_peer_node03>...
Wed Apr 12 23:36:48 2017 daemon.info fastd[1692]: resolved host `sn-a.ak.ber.freifunk-essen.net' successfully
Wed Apr 12 23:36:48 2017 daemon.info fastd[1692]: received handshake response from <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000] using fastd v17
Wed Apr 12 23:36:49 2017 daemon.info fastd[1692]: 185.46.137.143:10000 authorized as <mesh_vpn_backbone_peer_node03>
Wed Apr 12 23:36:49 2017 daemon.notice fastd[1692]: connection with <mesh_vpn_backbone_peer_node03> established.
Wed Apr 12 23:36:49 2017 daemon.info fastd[1692]: new session with <mesh_vpn_backbone_peer_node03> established using method `salsa2012+umac'.
Thu Apr 13 00:27:44 2017 daemon.info fastd[1692]: refreshing session with <mesh_vpn_backbone_peer_node03>
Thu Apr 13 00:27:44 2017 daemon.info fastd[1692]: sending handshake to <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000]...
Thu Apr 13 00:27:44 2017 daemon.info fastd[1692]: received handshake response from <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000] using fastd v17
Thu Apr 13 00:27:45 2017 daemon.info fastd[1692]: 185.46.137.143:10000 authorized as <mesh_vpn_backbone_peer_node03>
Thu Apr 13 00:27:45 2017 daemon.info fastd[1692]: new session with <mesh_vpn_backbone_peer_node03> established using method `salsa2012+umac'.
Thu Apr 13 01:22:34 2017 daemon.info fastd[1692]: refreshing session with <mesh_vpn_backbone_peer_node03>
Thu Apr 13 01:22:34 2017 daemon.info fastd[1692]: sending handshake to <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000]...
Thu Apr 13 01:22:34 2017 daemon.info fastd[1692]: received handshake response from <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000] using fastd v17
Thu Apr 13 01:22:35 2017 daemon.info fastd[1692]: 185.46.137.143:10000 authorized as <mesh_vpn_backbone_peer_node03>
Thu Apr 13 01:22:35 2017 daemon.info fastd[1692]: new session with <mesh_vpn_backbone_peer_node03> established using method `salsa2012+umac'.
Thu Apr 13 01:46:22 2017 user.notice firewall: Reloading firewall due to ifupdate of wan6 (br-wan)
Thu Apr 13 02:15:04 2017 daemon.info fastd[1692]: refreshing session with <mesh_vpn_backbone_peer_node03>
Thu Apr 13 02:15:04 2017 daemon.info fastd[1692]: sending handshake to <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000]...
Thu Apr 13 02:15:04 2017 daemon.info fastd[1692]: received handshake response from <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000] using fastd v17
Thu Apr 13 02:15:04 2017 daemon.info fastd[1692]: 185.46.137.143:10000 authorized as <mesh_vpn_backbone_peer_node03>
Thu Apr 13 02:15:04 2017 daemon.info fastd[1692]: new session with <mesh_vpn_backbone_peer_node03> established using method `salsa2012+umac'.
Thu Apr 13 03:09:08 2017 daemon.info fastd[1692]: refreshing session with <mesh_vpn_backbone_peer_node03>
Thu Apr 13 03:09:08 2017 daemon.info fastd[1692]: sending handshake to <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000]...
Thu Apr 13 03:09:08 2017 daemon.info fastd[1692]: received handshake response from <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000] using fastd v17
Thu Apr 13 03:09:09 2017 daemon.info fastd[1692]: 185.46.137.143:10000 authorized as <mesh_vpn_backbone_peer_node03>
Thu Apr 13 03:09:09 2017 daemon.info fastd[1692]: new session with <mesh_vpn_backbone_peer_node03> established using method `salsa2012+umac'.
Thu Apr 13 04:01:07 2017 daemon.info fastd[1692]: refreshing session with <mesh_vpn_backbone_peer_node03>
Thu Apr 13 04:01:07 2017 daemon.info fastd[1692]: sending handshake to <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000]...
Thu Apr 13 04:01:08 2017 daemon.info fastd[1692]: received handshake response from <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000] using fastd v17
Thu Apr 13 04:01:08 2017 daemon.info fastd[1692]: 185.46.137.143:10000 authorized as <mesh_vpn_backbone_peer_node03>
Thu Apr 13 04:01:08 2017 daemon.info fastd[1692]: new session with <mesh_vpn_backbone_peer_node03> established using method `salsa2012+umac'.
Thu Apr 13 04:51:11 2017 daemon.info fastd[1692]: refreshing session with <mesh_vpn_backbone_peer_node03>
Thu Apr 13 04:51:11 2017 daemon.info fastd[1692]: sending handshake to <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000]...
Thu Apr 13 04:51:11 2017 daemon.info fastd[1692]: received handshake response from <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000] using fastd v17
Thu Apr 13 04:51:11 2017 daemon.info fastd[1692]: 185.46.137.143:10000 authorized as <mesh_vpn_backbone_peer_node03>
Thu Apr 13 04:51:11 2017 daemon.info fastd[1692]: new session with <mesh_vpn_backbone_peer_node03> established using method `salsa2012+umac'.
Thu Apr 13 05:41:37 2017 daemon.info fastd[1692]: refreshing session with <mesh_vpn_backbone_peer_node03>
Thu Apr 13 05:41:37 2017 daemon.info fastd[1692]: sending handshake to <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000]...
Thu Apr 13 05:41:37 2017 daemon.info fastd[1692]: received handshake response from <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000] using fastd v17
Thu Apr 13 05:41:37 2017 daemon.info fastd[1692]: 185.46.137.143:10000 authorized as <mesh_vpn_backbone_peer_node03>
Thu Apr 13 05:41:37 2017 daemon.info fastd[1692]: new session with <mesh_vpn_backbone_peer_node03> established using method `salsa2012+umac'.
Thu Apr 13 06:35:02 2017 daemon.info fastd[1692]: refreshing session with <mesh_vpn_backbone_peer_node03>
Thu Apr 13 06:35:02 2017 daemon.info fastd[1692]: sending handshake to <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000]...
Thu Apr 13 06:35:02 2017 daemon.info fastd[1692]: received handshake response from <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000] using fastd v17
Thu Apr 13 06:35:02 2017 daemon.info fastd[1692]: 185.46.137.143:10000 authorized as <mesh_vpn_backbone_peer_node03>
Thu Apr 13 06:35:02 2017 daemon.info fastd[1692]: new session with <mesh_vpn_backbone_peer_node03> established using method `salsa2012+umac'.
Thu Apr 13 07:25:22 2017 daemon.info fastd[1692]: refreshing session with <mesh_vpn_backbone_peer_node03>
Thu Apr 13 07:25:22 2017 daemon.info fastd[1692]: sending handshake to <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000]...
Thu Apr 13 07:25:23 2017 daemon.info fastd[1692]: received handshake response from <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000] using fastd v17
Thu Apr 13 07:25:23 2017 daemon.info fastd[1692]: 185.46.137.143:10000 authorized as <mesh_vpn_backbone_peer_node03>
Thu Apr 13 07:25:23 2017 daemon.info fastd[1692]: new session with <mesh_vpn_backbone_peer_node03> established using method `salsa2012+umac'.
Thu Apr 13 08:18:45 2017 daemon.info fastd[1692]: refreshing session with <mesh_vpn_backbone_peer_node03>
Thu Apr 13 08:18:45 2017 daemon.info fastd[1692]: sending handshake to <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000]...
Thu Apr 13 08:18:45 2017 daemon.info fastd[1692]: received handshake response from <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000] using fastd v17
Thu Apr 13 08:18:46 2017 daemon.info fastd[1692]: 185.46.137.143:10000 authorized as <mesh_vpn_backbone_peer_node03>
Thu Apr 13 08:18:46 2017 daemon.info fastd[1692]: new session with <mesh_vpn_backbone_peer_node03> established using method `salsa2012+umac'.
Thu Apr 13 09:13:26 2017 daemon.info fastd[1692]: refreshing session with <mesh_vpn_backbone_peer_node03>
Thu Apr 13 09:13:26 2017 daemon.info fastd[1692]: sending handshake to <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000]...
Thu Apr 13 09:13:26 2017 daemon.info fastd[1692]: received handshake response from <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000] using fastd v17
Thu Apr 13 09:13:26 2017 daemon.info fastd[1692]: 185.46.137.143:10000 authorized as <mesh_vpn_backbone_peer_node03>
Thu Apr 13 09:13:26 2017 daemon.info fastd[1692]: new session with <mesh_vpn_backbone_peer_node03> established using method `salsa2012+umac'.
Thu Apr 13 09:45:24 2017 authpriv.info dropbear[6636]: Child connection from 192.168.178.32:37986
Thu Apr 13 09:45:31 2017 authpriv.notice dropbear[6636]: Password auth succeeded for 'root' from 192.168.178.32:37986
Thu Apr 13 10:06:40 2017 daemon.info fastd[1692]: refreshing session with <mesh_vpn_backbone_peer_node03>
Thu Apr 13 10:06:40 2017 daemon.info fastd[1692]: sending handshake to <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000]...
Thu Apr 13 10:06:40 2017 daemon.info fastd[1692]: received handshake response from <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000] using fastd v17
Thu Apr 13 10:06:40 2017 daemon.info fastd[1692]: 185.46.137.143:10000 authorized as <mesh_vpn_backbone_peer_node03>
Thu Apr 13 10:06:40 2017 daemon.info fastd[1692]: new session with <mesh_vpn_backbone_peer_node03> established using method `salsa2012+umac'.

Logread Gerät 2 (leider nicht bis Gestern wie es aussieht)

So… der Fehler ist wieder da (Router neu gestartet)
Bin die Schritte durchgegangen:

Vom Client: Ping IPV4 Nextnode OK, IPV6 Nextnode OK,
Gateway 1 OK (~90ms), Gateway 2 OK ( ~30ms), Gateway 3 OK (~100 ms)
Gerät 1: ping6 2001:4860:4860::8888: = 180~250 ms
Gerät 1: ping6 www.google.com = ~190~500 ms
ping -6 auf Gerät 1: ~100ms

Hier das Logread:

Thu Apr 13 10:33:32 2017 kern.info kernel: [   11.070000] Ebtables v2.0 registered
Thu Apr 13 10:33:32 2017 kern.info kernel: [   11.070000] ip_tables: (C) 2000-2006 Netfilter Core Team
Thu Apr 13 10:33:32 2017 kern.info kernel: [   11.160000] nf_conntrack version 0.5.0 (948 buckets, 3792 max)
Thu Apr 13 10:33:32 2017 kern.info kernel: [   11.240000] xt_time: kernel timezone is -0000
Thu Apr 13 10:33:32 2017 kern.debug kernel: [   11.280000] ath: EEPROM regdomain: 0x0
Thu Apr 13 10:33:32 2017 kern.debug kernel: [   11.280000] ath: EEPROM indicates default country code should be used
Thu Apr 13 10:33:32 2017 kern.debug kernel: [   11.280000] ath: doing EEPROM country->regdmn map search
Thu Apr 13 10:33:32 2017 kern.debug kernel: [   11.280000] ath: country maps to regdmn code: 0x3a
Thu Apr 13 10:33:32 2017 kern.debug kernel: [   11.280000] ath: Country alpha2 being used: US
Thu Apr 13 10:33:32 2017 kern.debug kernel: [   11.280000] ath: Regpair used: 0x3a
Thu Apr 13 10:33:32 2017 kern.debug kernel: [   11.290000] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
Thu Apr 13 10:33:32 2017 kern.info kernel: [   11.300000] ieee80211 phy0: Atheros AR9561 Rev:0 mem=0xb8100000, irq=47
Thu Apr 13 10:33:33 2017 daemon.notice haveged: haveged starting up
Thu Apr 13 10:33:35 2017 daemon.info haveged: haveged: ver: 1.9.1; arch: generic; vend: ; build: (gcc 4.8.3 CV); collect: 128K
Thu Apr 13 10:33:35 2017 daemon.info haveged: haveged: cpu: (); data: 32K (P); inst: 32K (P); idx: 19/40; sz: 32699/67115
Thu Apr 13 10:33:35 2017 daemon.info haveged: haveged: fills: 0, generated: 0 
Thu Apr 13 10:33:37 2017 authpriv.info dropbear[1109]: Not backgrounding
Thu Apr 13 10:33:39 2017 daemon.warn netifd: You have delegated IPv6-prefixes but haven't assigned them to any interface. Did you forget to set option ip6assign on your lan-interfaces?
Thu Apr 13 10:33:39 2017 kern.info kernel: [   19.920000] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Thu Apr 13 10:33:39 2017 daemon.notice netifd: Interface 'client_lan' is enabled
Thu Apr 13 10:33:39 2017 kern.info kernel: [   19.930000] device eth0.1 entered promiscuous mode
Thu Apr 13 10:33:39 2017 kern.info kernel: [   19.930000] device eth0 entered promiscuous mode
Thu Apr 13 10:33:39 2017 kern.info kernel: [   19.950000] IPv6: ADDRCONF(NETDEV_UP): br-client: link is not ready
Thu Apr 13 10:33:39 2017 daemon.notice netifd: Interface 'client' is enabled
Thu Apr 13 10:33:39 2017 kern.info kernel: [   19.970000] device eth0.2 entered promiscuous mode
Thu Apr 13 10:33:39 2017 daemon.notice netifd: Interface 'wan6' is enabled
Thu Apr 13 10:33:39 2017 daemon.notice netifd: Interface 'wan' is enabled
Thu Apr 13 10:33:39 2017 daemon.notice netifd: Interface 'mesh_wan' is enabled
Thu Apr 13 10:33:39 2017 kern.info kernel: [   20.000000] IPv6: ADDRCONF(NETDEV_UP): br-wan: link is not ready
Thu Apr 13 10:33:39 2017 kern.info kernel: [   20.040000] device br-client entered promiscuous mode
Thu Apr 13 10:33:39 2017 kern.info kernel: [   20.050000] IPv6: ADDRCONF(NETDEV_UP): local-node: link is not ready
Thu Apr 13 10:33:39 2017 user.notice sysctl: net.ipv6.conf.br-client.forwarding = 0
Thu Apr 13 10:33:39 2017 daemon.notice netifd: Interface 'local_node' is enabled
Thu Apr 13 10:33:39 2017 daemon.notice netifd: Interface 'local_node' is setting up now
Thu Apr 13 10:33:39 2017 daemon.notice netifd: Interface 'local_node' is now up
Thu Apr 13 10:33:39 2017 daemon.notice netifd: Interface 'loopback' is enabled
Thu Apr 13 10:33:39 2017 daemon.notice netifd: Interface 'loopback' is setting up now
Thu Apr 13 10:33:39 2017 daemon.notice netifd: Interface 'loopback' is now up
Thu Apr 13 10:33:39 2017 daemon.notice netifd: Network device 'lo' link is up
Thu Apr 13 10:33:39 2017 daemon.notice netifd: Interface 'loopback' has link connectivity 
Thu Apr 13 10:33:40 2017 user.notice firewall: Reloading firewall due to ifup of local_node (local-node)
Thu Apr 13 10:33:40 2017 kern.info kernel: [   21.640000] eth0: link up (1000Mbps/Full duplex)
Thu Apr 13 10:33:40 2017 kern.info kernel: [   21.640000] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Thu Apr 13 10:33:40 2017 daemon.notice netifd: Network device 'eth0' link is up
Thu Apr 13 10:33:41 2017 kern.info kernel: [   21.660000] br-client: port 1(eth0.1) entered forwarding state
Thu Apr 13 10:33:41 2017 kern.info kernel: [   21.660000] br-client: port 1(eth0.1) entered forwarding state
Thu Apr 13 10:33:41 2017 kern.info kernel: [   21.670000] br-wan: port 1(eth0.2) entered forwarding state
Thu Apr 13 10:33:41 2017 kern.info kernel: [   21.670000] br-wan: port 1(eth0.2) entered forwarding state
Thu Apr 13 10:33:41 2017 kern.info kernel: [   21.690000] IPv6: ADDRCONF(NETDEV_CHANGE): br-client: link becomes ready
Thu Apr 13 10:33:41 2017 kern.info kernel: [   21.690000] IPv6: ADDRCONF(NETDEV_CHANGE): br-wan: link becomes ready
Thu Apr 13 10:33:41 2017 kern.info kernel: [   21.700000] IPv6: ADDRCONF(NETDEV_CHANGE): local-node: link becomes ready
Thu Apr 13 10:33:41 2017 daemon.notice netifd: VLAN 'eth0.1' link is up
Thu Apr 13 10:33:41 2017 daemon.notice netifd: Interface 'client_lan' has link connectivity 
Thu Apr 13 10:33:41 2017 daemon.notice netifd: Interface 'client_lan' is setting up now
Thu Apr 13 10:33:41 2017 daemon.notice netifd: Interface 'client_lan' is now up
Thu Apr 13 10:33:41 2017 daemon.notice netifd: VLAN 'eth0.2' link is up
Thu Apr 13 10:33:41 2017 daemon.notice netifd: Bridge 'br-client' link is up
Thu Apr 13 10:33:41 2017 daemon.notice netifd: Interface 'client' has link connectivity 
Thu Apr 13 10:33:41 2017 daemon.notice netifd: Interface 'client' is setting up now
Thu Apr 13 10:33:41 2017 daemon.notice netifd: Bridge 'br-wan' link is up
Thu Apr 13 10:33:41 2017 daemon.notice netifd: Interface 'wan6' has link connectivity 
Thu Apr 13 10:33:41 2017 daemon.notice netifd: Interface 'wan6' is setting up now
Thu Apr 13 10:33:41 2017 daemon.notice netifd: Interface 'wan' has link connectivity 
Thu Apr 13 10:33:41 2017 daemon.notice netifd: Interface 'wan' is setting up now
Thu Apr 13 10:33:41 2017 daemon.notice netifd: Interface 'mesh_wan' has link connectivity 
Thu Apr 13 10:33:41 2017 daemon.notice netifd: Interface 'mesh_wan' is setting up now
Thu Apr 13 10:33:41 2017 daemon.notice netifd: MAC VLAN 'local-node' link is up
Thu Apr 13 10:33:41 2017 daemon.notice netifd: Interface 'local_node' has link connectivity 
Thu Apr 13 10:33:42 2017 daemon.notice netifd: wan (1418): udhcpc (v1.23.2) started
Thu Apr 13 10:33:42 2017 daemon.notice netifd: wan (1418): Sending discover...
Thu Apr 13 10:33:42 2017 daemon.notice netifd: wan (1418): Sending select for 192.168.178.33...
Thu Apr 13 10:33:42 2017 daemon.notice netifd: wan (1418): Lease of 192.168.178.33 obtained, lease time 864000
Thu Apr 13 10:33:43 2017 kern.info kernel: [   23.660000] br-client: port 1(eth0.1) entered forwarding state
Thu Apr 13 10:33:43 2017 kern.info kernel: [   23.670000] br-wan: port 1(eth0.2) entered forwarding state
Thu Apr 13 10:33:43 2017 daemon.notice netifd: Interface 'wan' is now up
Thu Apr 13 10:33:43 2017 kern.info kernel: [   24.030000] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Port 5 is up
Thu Apr 13 10:33:43 2017 daemon.notice netifd: radio0 (1199): Configuration file: /var/run/hostapd-phy0.conf
Thu Apr 13 10:33:43 2017 kern.info kernel: [   24.080000] IPv6: ADDRCONF(NETDEV_UP): client0: link is not ready
Thu Apr 13 10:33:43 2017 kern.info kernel: [   24.220000] device client0 entered promiscuous mode
Thu Apr 13 10:33:43 2017 kern.info kernel: [   24.280000] IPv6: ADDRCONF(NETDEV_CHANGE): client0: link becomes ready
Thu Apr 13 10:33:43 2017 kern.info kernel: [   24.290000] br-client: port 2(client0) entered forwarding state
Thu Apr 13 10:33:43 2017 kern.info kernel: [   24.290000] br-client: port 2(client0) entered forwarding state
Thu Apr 13 10:33:43 2017 daemon.notice netifd: radio0 (1199): client0: interface state UNINITIALIZED->COUNTRY_UPDATE
Thu Apr 13 10:33:43 2017 daemon.notice netifd: radio0 (1199): Using interface client0 with hwaddr a2:6e:27:a4:c8:70 and ssid "Freifunk"
Thu Apr 13 10:33:43 2017 daemon.notice netifd: radio0 (1199): client0: interface state COUNTRY_UPDATE->ENABLED
Thu Apr 13 10:33:43 2017 daemon.notice netifd: radio0 (1199): client0: AP-ENABLED 
Thu Apr 13 10:33:43 2017 kern.info kernel: [   24.470000] batman_adv: bat0: Adding interface: primary0
Thu Apr 13 10:33:43 2017 kern.info kernel: [   24.480000] batman_adv: bat0: Interface activated: primary0
Thu Apr 13 10:33:43 2017 kern.info kernel: [   24.510000] batman_adv: bat0: Adding interface: br-wan
Thu Apr 13 10:33:43 2017 kern.info kernel: [   24.510000] batman_adv: bat0: The MTU of interface br-wan is too small (1500) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem.
Thu Apr 13 10:33:43 2017 kern.info kernel: [   24.540000] batman_adv: bat0: Interface activated: br-wan
Thu Apr 13 10:33:43 2017 kern.info kernel: [   24.540000] 8021q: adding VLAN 0 to HW filter on device bat0
Thu Apr 13 10:33:43 2017 daemon.notice netifd: Interface 'bat0' is enabled
Thu Apr 13 10:33:43 2017 kern.info kernel: [   24.550000] device bat0 entered promiscuous mode
Thu Apr 13 10:33:43 2017 kern.info kernel: [   24.560000] br-client: port 3(bat0) entered forwarding state
Thu Apr 13 10:33:43 2017 kern.info kernel: [   24.560000] br-client: port 3(bat0) entered forwarding state
Thu Apr 13 10:33:43 2017 daemon.notice netifd: Network device 'bat0' link is up
Thu Apr 13 10:33:43 2017 daemon.notice netifd: Interface 'bat0' has link connectivity 
Thu Apr 13 10:33:43 2017 daemon.notice netifd: Interface 'bat0' is setting up now
Thu Apr 13 10:33:43 2017 daemon.notice netifd: Interface 'bat0' is now up
Thu Apr 13 10:33:44 2017 daemon.notice netifd: Network device 'client0' link is up
Thu Apr 13 10:33:44 2017 kern.info kernel: [   24.740000] batman_adv: bat0: no_rebroadcast: Changing from: disabled to: enabled
Thu Apr 13 10:33:44 2017 daemon.notice netifd: Interface 'mesh_wan' is now up
Thu Apr 13 10:33:44 2017 kern.info kernel: [   25.630000] batman_adv: bat0: Changing gw mode from: off to: client
Thu Apr 13 10:33:44 2017 kern.info kernel: [   25.630000] batman_adv: bat0: hop_penalty: Changing from: 30 to: 15
Thu Apr 13 10:33:45 2017 kern.info kernel: [   25.660000] batman_adv: bat0: multicast_mode: Changing from: enabled to: disabled
Thu Apr 13 10:33:45 2017 kern.info kernel: [   25.660000] batman_adv: bat0: orig_interval: Changing from: 1000 to: 5000
Thu Apr 13 10:33:45 2017 daemon.info dnsmasq[1634]: started, version 2.73 cachesize 150
Thu Apr 13 10:33:45 2017 daemon.info dnsmasq[1634]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC loop-detect inotify
Thu Apr 13 10:33:45 2017 daemon.info dnsmasq[1634]: reading /var/gluon/wan-dnsmasq/resolv.conf
Thu Apr 13 10:33:45 2017 daemon.info dnsmasq[1634]: using nameserver 192.168.178.1#53
Thu Apr 13 10:33:45 2017 daemon.info dnsmasq[1634]: cleared cache
Thu Apr 13 10:33:45 2017 daemon.info dnsmasq[1629]: started, version 2.73 cachesize 150
Thu Apr 13 10:33:45 2017 daemon.info dnsmasq[1629]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC loop-detect inotify
Thu Apr 13 10:33:45 2017 daemon.info dnsmasq[1629]: DNS service limited to local subnets
Thu Apr 13 10:33:45 2017 daemon.info dnsmasq[1629]: using local addresses only for domain lan
Thu Apr 13 10:33:45 2017 daemon.warn dnsmasq[1629]: no servers found in /tmp/resolv.conf.auto, will retry
Thu Apr 13 10:33:45 2017 daemon.info dnsmasq[1629]: read /etc/hosts - 1 addresses
Thu Apr 13 10:33:45 2017 kern.info kernel: [   26.290000] br-client: port 2(client0) entered forwarding state
Thu Apr 13 10:33:45 2017 kern.info kernel: [   26.560000] br-client: port 3(bat0) entered forwarding state
Thu Apr 13 10:33:46 2017 daemon.notice fastd[1761]: fastd v18 starting
Thu Apr 13 10:33:46 2017 daemon.notice netifd: Interface 'mesh_vpn' is enabled
Thu Apr 13 10:33:46 2017 daemon.notice netifd: Network device 'mesh-vpn' link is up
Thu Apr 13 10:33:46 2017 daemon.notice netifd: Interface 'mesh_vpn' has link connectivity 
Thu Apr 13 10:33:46 2017 daemon.notice netifd: Interface 'mesh_vpn' is setting up now
Thu Apr 13 10:33:46 2017 daemon.notice fastd[1761]: changed to UID 0, GID 800
Thu Apr 13 10:33:46 2017 daemon.info fastd[1761]: adding peer <mesh_vpn_backbone_peer_node03>
Thu Apr 13 10:33:46 2017 daemon.info fastd[1761]: adding peer <mesh_vpn_backbone_peer_node02>
Thu Apr 13 10:33:46 2017 daemon.info fastd[1761]: adding peer <mesh_vpn_backbone_peer_node01>
Thu Apr 13 10:33:46 2017 daemon.info fastd[1761]: resolving host `sn-a.ov.lil.freifunk-essen.net' for peer <mesh_vpn_backbone_peer_node01>...
Thu Apr 13 10:33:46 2017 daemon.info fastd[1761]: resolving host `sn-b.ov.lil.freifunk-essen.net' for peer <mesh_vpn_backbone_peer_node02>...
Thu Apr 13 10:33:46 2017 daemon.info fastd[1761]: resolving host `sn-a.ak.ber.freifunk-essen.net' for peer <mesh_vpn_backbone_peer_node03>...
Thu Apr 13 10:33:46 2017 daemon.info fastd[1761]: resolved host `sn-b.ov.lil.freifunk-essen.net' successfully
Thu Apr 13 10:33:46 2017 daemon.info fastd[1761]: resolved host `sn-a.ov.lil.freifunk-essen.net' successfully
Thu Apr 13 10:33:46 2017 daemon.info fastd[1761]: resolved host `sn-a.ak.ber.freifunk-essen.net' successfully
Thu Apr 13 10:33:46 2017 user.emerg syslog: setting up led USB
Thu Apr 13 10:33:46 2017 user.emerg syslog: Skipping trigger 'usbdev' for led 'USB' due to missing kernel module
Thu Apr 13 10:33:46 2017 user.emerg syslog: setting up led WLAN
Thu Apr 13 10:33:46 2017 user.emerg syslog: setting up led WAN
Thu Apr 13 10:33:47 2017 user.emerg syslog: setting up led LAN1
Thu Apr 13 10:33:47 2017 user.emerg syslog: setting up led LAN2
Thu Apr 13 10:33:47 2017 user.emerg syslog: setting up led LAN3
Thu Apr 13 10:33:47 2017 user.emerg syslog: setting up led LAN4
Thu Apr 13 10:33:47 2017 kern.info kernel: [   27.880000] batman_adv: bat0: Adding interface: mesh-vpn
Thu Apr 13 10:33:47 2017 kern.info kernel: [   27.880000] batman_adv: bat0: The MTU of interface mesh-vpn is too small (1280) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem.
Thu Apr 13 10:33:47 2017 kern.info kernel: [   27.910000] batman_adv: bat0: Interface activated: mesh-vpn
Thu Apr 13 10:33:47 2017 kern.info kernel: [   27.990000] batman_adv: bat0: no_rebroadcast: Changing from: disabled to: enabled
Thu Apr 13 10:33:47 2017 daemon.notice netifd: Interface 'mesh_vpn' is now up
Thu Apr 13 10:33:47 2017 daemon.notice netifd: Interface 'wan6' is now up
Thu Apr 13 10:33:47 2017 daemon.info fastd[1761]: sending handshake to <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000]...
Thu Apr 13 10:33:47 2017 daemon.info fastd[1761]: resolving host `sn-a.ak.ber.freifunk-essen.net' for peer <mesh_vpn_backbone_peer_node03>...
Thu Apr 13 10:33:47 2017 daemon.info fastd[1761]: resolved host `sn-a.ak.ber.freifunk-essen.net' successfully
Thu Apr 13 10:33:48 2017 daemon.info fastd[1761]: received handshake response from <mesh_vpn_backbone_peer_node03>[185.46.137.143:10000] using fastd v17
Thu Apr 13 10:33:48 2017 user.emerg syslog: /etc/rc.d/S99alfred: waiting 30 secs for br-client address...
Thu Apr 13 10:33:48 2017 user.emerg syslog: /etc/rc.d/S99alfred: starting alfred
Thu Apr 13 10:33:48 2017 user.emerg syslog: /etc/rc.d/S99alfred: starting batadv-vis
Thu Apr 13 10:33:48 2017 daemon.info procd: - init complete -
Thu Apr 13 10:33:48 2017 daemon.info fastd[1761]: 185.46.137.143:10000 authorized as <mesh_vpn_backbone_peer_node03>
Thu Apr 13 10:33:48 2017 daemon.notice fastd[1761]: connection with <mesh_vpn_backbone_peer_node03> established.
Thu Apr 13 10:33:48 2017 daemon.info fastd[1761]: new session with <mesh_vpn_backbone_peer_node03> established using method `salsa2012+umac'.
Thu Apr 13 10:33:49 2017 user.notice firewall: Reloading firewall due to ifup of wan (br-wan)
Thu Apr 13 10:33:49 2017 daemon.info dnsmasq[1634]: reading /var/gluon/wan-dnsmasq/resolv.conf
Thu Apr 13 10:33:49 2017 daemon.info dnsmasq[1634]: using nameserver fd00::3a10:d5ff:feb3:493a#53
Thu Apr 13 10:33:49 2017 daemon.info dnsmasq[1634]: using nameserver 192.168.178.1#53
Thu Apr 13 10:33:51 2017 user.notice firewall: Reloading firewall due to ifup of wan6 (br-wan)
Thu Apr 13 10:33:55 2017 daemon.notice netifd: Interface 'client' is now up
Thu Apr 13 10:33:55 2017 user.notice firewall: Reloading firewall due to ifup of client (br-client)
Thu Apr 13 10:33:56 2017 kern.notice kernel: [   37.090000] random: nonblocking pool is initialized
Thu Apr 13 10:33:59 2017 authpriv.info dropbear[2253]: Child connection from 2003:e3:13c8:c600:2084:8ffa:e99b:1dee:33468
Thu Apr 13 10:34:14 2017 daemon.info dnsmasq[1629]: reading /tmp/resolv.conf.auto
Thu Apr 13 10:34:14 2017 daemon.info dnsmasq[1629]: using local addresses only for domain lan
Thu Apr 13 10:34:14 2017 daemon.info dnsmasq[1629]: using nameserver 2a03:2260:1005::32#53
Thu Apr 13 10:34:14 2017 daemon.info dnsmasq[1629]: using nameserver 2a03:2260:1005::24#53
Thu Apr 13 10:34:14 2017 authpriv.notice dropbear[2253]: Password auth succeeded for 'root' from 2003:e3:13c8:c600:2084:8ffa:e99b:1dee:33468
Thu Apr 13 10:34:14 2017 authpriv.info dropbear[2253]: Exit (root): Exited normally
Thu Apr 13 10:34:14 2017 authpriv.info dropbear[2301]: Child connection from 2003:e3:13c8:c600:2084:8ffa:e99b:1dee:33472
Thu Apr 13 10:34:16 2017 daemon.info dnsmasq[1629]: reading /tmp/resolv.conf.auto
Thu Apr 13 10:34:16 2017 daemon.info dnsmasq[1629]: using local addresses only for domain lan
Thu Apr 13 10:34:16 2017 daemon.info dnsmasq[1629]: using nameserver 2a03:2260:1005::32#53
Thu Apr 13 10:34:16 2017 daemon.info dnsmasq[1629]: using nameserver 2a03:2260:1005::24#53
Thu Apr 13 10:34:16 2017 daemon.info dnsmasq[1629]: using nameserver 2a03:2260:1005::8#53
Thu Apr 13 10:34:17 2017 kern.warn kernel: [   58.510000] br-client: Multicast hash table maximum of 512 reached, disabling snooping: bat0
Thu Apr 13 10:34:24 2017 authpriv.notice dropbear[2301]: Password auth succeeded for 'root' from 2003:e3:13c8:c600:2084:8ffa:e99b:1dee:33472
Thu Apr 13 11:27:28 2017 daemon.info hostapd: client0: STA 40:b8:37:ac:e8:4a IEEE 802.11: authenticated
Thu Apr 13 11:27:28 2017 daemon.info hostapd: client0: STA 40:b8:37:ac:e8:4a IEEE 802.11: associated (aid 1)
1 „Gefällt mir“

Na dann fehlt ja nur noch die traceroute um herauszufinden wo die Latenz von 500ms herkommt.
Am schönsten finde ich ja immer die Tabellen von mtr.

1 „Gefällt mir“

traceroute macht nur auf dem Client sinn oder auch vom Router aus? Ich habe das Problem das das anscheinend nicht in der busibox vom Handy drin ist und ich hab gerade keinen anderen Clienten.

P.S. je nachdem mit welchem Gateway ich verbunden bin komme ich nicht per ssh auf das Gerät (Ping geht). mit der IP aus meinem Netzwerk geht es.

Wenn Du die Möglichkeit hast, irgendwo einen Linux mit mtr (irgendeinem hübschen Windows-Dauer-Traceroute, keine Ahnung was es da gibt) laufen zu lassen, dann lasse das mal ein paar Stunden stunden stehen.
Sowohl auf dem Nextnode (v4 oder v6 egal) und einmal für jedes der Gateways und noch einmal zu google.
Und dann schauen, wo sich in der Laufzeit welcher Packetloss (in %) angesammelt hat.

Meine Vermutung geht in zwische auf „eines der 3 gateways ist mindestens zeitweise semi-defekt, hat keine Außenanbindung o.ä.“.
Dann kommst Du mit einem reboot mit etwas Glück (2/3) wieder an ein anderes Gateway…

1 „Gefällt mir“

einmal vom client zu google, einmal aus deinem privatnetz zum supernode
stunden müssen es jetzt nicht sein, aber nach ein paar minuten kommt manchmal schon der loss zum vorschein

500ms halte ich noch für eine akzeptable Latenz für eine Leitung „unter Last“.
Zumindest gibt das nicht das Szenario „keine Daten mehr aus dem Internet“.

Von daher: Es reicht zu warten bis sich der Fehler zeigt.
Aber das kann auch dauern.

Ich bin jetzt auf Node3 (04:ce:ef:ca:fe:3b)

    traceroute to golem.com (23.23.174.132), 30 hops max, 38 byte packets
     1  192.168.178.1 (192.168.178.1)  0.561 ms  0.509 ms  0.464 ms
     2  62.155.244.185 (62.155.244.185)  16.592 ms  16.148 ms  16.386 ms
     3  hh-ea8-i.HH.DE.NET.DTAG.DE (62.154.32.129)  25.760 ms  25.290 ms  23.866 ms
     4  80.150.168.162 (80.150.168.162)  22.704 ms  22.494 ms  22.715 ms
     5  hbg-bb1-link.telia.net (213.155.135.82)  22.564 ms  hbg-bb4-link.telia.net (213.155.135.84)  22.639 ms  hbg-bb1-link.telia.net (213.155.135.80)  22.359 ms
     6  ldn-bb3-link.telia.net (62.115.112.72)  32.045 ms  ldn-bb3-link.telia.net (62.115.115.232)  32.234 ms  ldn-bb3-link.telia.net (62.115.115.234)  32.132 ms
     7  *  ash-bb4-link.telia.net (62.115.124.142)  103.357 ms  ash-bb3-link.telia.net (80.91.246.68)  106.115 ms
     8  ash-b1-link.telia.net (62.115.143.1)  106.391 ms  ash-b1-link.telia.net (213.155.130.59)  107.714 ms  ash-b1-link.telia.net (213.155.136.39)  105.262 ms
     9  vadata-ic-157232-ash-bb1.c.telia.net (62.115.9.66)  130.952 ms  vadata-ic-157229-ash-bb1.c.telia.net (80.239.193.210)  145.109 ms  vadata-ic-157232-ash-bb1.c.telia.net (62.115.9.66)  143.822 ms
    10  *  *  vadata-ic-157234-ash-bb1.c.telia.net (62.115.9.74)  144.262 ms
    11  *  *  *
    12  54.239.110.139 (54.239.110.139)  134.276 ms  54.239.110.177 (54.239.110.177)  134.950 ms  54.239.110.145 (54.239.110.145)  206.028 ms
    13  54.239.108.195 (54.239.108.195)  114.574 ms  54.239.111.53 (54.239.111.53)  118.643 ms  54.239.109.41 (54.239.109.41)  115.902 ms
    14  205.251.244.210 (205.251.244.210)  116.883 ms  205.251.245.189 (205.251.245.189)  113.669 ms  205.251.245.172 (205.251.245.172)  117.495 ms
    15  *  *  205.251.245.174 (205.251.245.174)  118.196 ms
    16  *  *  *
    17  *  *  *
    18  *  *  *
    19  *  *  *
    20  *  *  *
    21  *  *  *
    22  *  *  *
    23  *  *  *
    24  *  *  *
    25  *  *  *
    26  *  *  *
    27  *  *  *
    28  *  *  *
    29  *  *  *
    30  *  *  *
traceroute to google.de (216.58.205.227), 30 hops max, 60 byte packets
 1  gateway (10.228.32.1)  30.395 ms  30.564 ms  30.962 ms
 2  185.66.195.0 (185.66.195.0)  31.252 ms  43.990 ms  44.854 ms
 3  google.ber.ecix.net (194.9.117.34)  59.989 ms  60.138 ms  62.309 ms
 4  108.170.241.194 (108.170.241.194)  64.425 ms 108.170.241.130 (108.170.241.130)  63.757 ms  63.922 ms
 5  216.239.47.100 (216.239.47.100)  64.577 ms 209.85.240.225 (209.85.240.225)  64.249 ms  64.095 ms
 6  108.170.234.11 (108.170.234.11)  73.094 ms 108.170.236.121 (108.170.236.121)  51.616 ms 209.85.244.159 (209.85.244.159)  63.638 ms
 7  108.170.232.180 (108.170.232.180)  63.784 ms 216.239.57.187 (216.239.57.187)  64.099 ms *
 8  72.14.235.79 (72.14.235.79)  62.646 ms  62.324 ms 216.239.47.53 (216.239.47.53)  63.926 ms
 9  * * 216.239.48.45 (216.239.48.45)  63.119 ms
10  fra15s24-in-f227.1e100.net (216.58.205.227)  62.801 ms  62.954 ms *
[stephan@desktop ~]$ traceroute golem.de
traceroute to golem.de (109.68.230.138), 30 hops max, 60 byte packets
 1  gateway (10.228.32.1)  36.078 ms  36.403 ms  36.716 ms
 2  185.66.195.0 (185.66.195.0)  37.241 ms  37.404 ms  37.727 ms
 3  185.66.195.1 (185.66.195.1)  38.078 ms  38.235 ms  38.372 ms
 4  * * *
 5  * * *
 6  * * *
 7  * * *
 8  * * *
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
14  * * *
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *
[stephan@desktop ~]$ traceroute google.com
traceroute to google.com (74.125.143.100), 30 hops max, 60 byte packets
 1  gateway (10.228.32.1)  33.729 ms  34.007 ms  34.275 ms
 2  185.66.195.0 (185.66.195.0)  34.530 ms  34.685 ms  34.860 ms
 3  google.ber.ecix.net (194.9.117.34)  54.256 ms  54.566 ms  54.709 ms
 4  108.170.241.131 (108.170.241.131)  99.629 ms 108.170.241.162 (108.170.241.162)  55.122 ms 108.170.241.195 (108.170.241.195)  54.850 ms
 5  209.85.253.242 (209.85.253.242)  61.326 ms 216.239.43.120 (216.239.43.120)  55.296 ms 209.85.241.49 (209.85.241.49)  55.644 ms
 6  108.170.232.72 (108.170.232.72)  62.714 ms 72.14.238.114 (72.14.238.114)  47.502 ms 72.14.234.214 (72.14.234.214)  49.316 ms
 7  108.170.237.131 (108.170.237.131)  47.114 ms 108.170.237.135 (108.170.237.135)  46.928 ms 108.170.232.7 (108.170.232.7)  49.431 ms
 8  * * *
 9  ed-in-f100.1e100.net (74.125.143.100)  49.570 ms  49.722 ms  55.323 ms
[stephan@desktop ~]$ traceroute forum.freifunk.net
traceroute to forum.freifunk.net (185.66.195.242), 30 hops max, 60 byte packets
 1  gateway (10.228.32.1)  49.791 ms  49.957 ms  50.253 ms
 2  185.66.195.0 (185.66.195.0)  50.416 ms  51.288 ms *
 3  * * *
 4  * forum.freifunk.net (185.66.195.242)  51.738 ms *
[stephan@desktop ~]$ 
traceroute to google.com (2a00:1450:4001:820::200e), 30 hops max, 80 byte packets
 1  2a03:2260:1005::24 (2a03:2260:1005::24)  156.512 ms  156.715 ms  156.876 ms
 2  2a03:2260::1 (2a03:2260::1)  179.700 ms  204.530 ms  204.964 ms
 3  de-cix20.net.google.com (2001:7f8::3b41:0:2)  205.130 ms  205.288 ms  205.446 ms
 4  2001:4860:0:1::2f (2001:4860:0:1::2f)  205.619 ms 2001:4860:0:1::b7 (2001:4860:0:1::b7)  231.702 ms  231.874 ms
 5  2001:4860:0:1::1f99 (2001:4860:0:1::1f99)  179.990 ms 2001:4860:0:1::1f97 (2001:4860:0:1::1f97)  180.140 ms  180.327 ms
 6  fra15s24-in-x0e.1e100.net (2a00:1450:4001:820::200e)  232.024 ms  145.905 ms  283.339 ms
[stephan@desktop ~]$ traceroute -6 heise.de
traceroute to heise.de (2a02:2e0:3fe:1001:302::), 30 hops max, 80 byte packets
 1  2a03:2260:1005::24 (2a03:2260:1005::24)  154.971 ms  155.162 ms  155.327 ms
 2  * * *
 3  * * *
 4  * * *
 5  2a02:2e0:3fe:0:c::1 (2a02:2e0:3fe:0:c::1)  348.702 ms !X  166.661 ms !X *
[stephan@desktop ~]$ traceroute -6 golem.de
traceroute to golem.de (2a00:13c8:f5::f:4b3d:148), 30 hops max, 80 byte packets
 1  2a03:2260:1005::24 (2a03:2260:1005::24)  157.711 ms  157.978 ms  158.145 ms
 2  2a03:2260::1 (2a03:2260::1)  178.839 ms  179.001 ms  202.610 ms
 3  ae1-2.fix5-r1.syseleven.net (2001:7f8::62cb:0:1)  203.017 ms  203.187 ms  203.354 ms
 4  ae6-0.blu1-r1.syseleven.net (2a00:13c8:10:3::)  203.517 ms  203.678 ms  226.279 ms
 5  golem.de (2a00:13c8:f5::f:4b3d:148)  226.685 ms  227.182 ms  227.024 ms
[stephan@desktop ~]$ traceroute -6 forum.freifunk.com
forum.freifunk.com: Der Name oder der Dienst ist nicht bekannt
Cannot handle "host" cmdline arg `forum.freifunk.com' on position 1 (argc 2)
[stephan@desktop ~]$ traceroute -6 forum.freifunk.net
traceroute to forum.freifunk.net (2a03:2260:2000:1::2), 30 hops max, 80 byte packets
 1  2a03:2260:1005::24 (2a03:2260:1005::24)  224.743 ms  225.117 ms  225.472 ms
 2  2a03:2260::1 (2a03:2260::1)  222.553 ms  222.956 ms  223.128 ms
 3  2a03:2260::3 (2a03:2260::3)  223.694 ms  224.154 ms  252.149 ms
 4  forum.freifunk.net (2a03:2260:2000:1::2)  252.329 ms  253.798 ms  253.993 ms
[stephan@desktop ~]$

Wenn du auf einem Knoten was mit IPv4 machst geht das eigentlich immer direkt über WAN raus, der traceroute läuft also über dein Heimnetz. Mesh-Only-Router haben kein IPv4.