# Verbindungsabbrüche / Fragen zur Meshkonfiguration

**URL:** <https://forum.freifunk.net/t/verbindungsabbrueche-fragen-zur-meshkonfiguration/14766>\
**Category:** Essen\
**Created:** [12. April 2017 um 08:49 UTC](https://forum.freifunk.net/t/verbindungsabbrueche-fragen-zur-meshkonfiguration/14766 "2017-04-12T08:49:57Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![DevilX](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@DevilX](https://forum.freifunk.net/u/DevilX)\
**Post date:** [9. April 2017 um 06:29 UTC](https://forum.freifunk.net/t/verbindungsabbrueche-fragen-zur-meshkonfiguration/14766/1 "2017-04-09T06:29:54Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Handle](https://forum.freifunk.net/user_avatar/forum.freifunk.net/handle/32/7819_2.png) [@Handle](https://forum.freifunk.net/u/Handle)\
**Post date:** [9. April 2017 um 09:13 UTC](https://forum.freifunk.net/t/verbindungsabbrueche-fragen-zur-meshkonfiguration/14766/2 "2017-04-09T09:13:05Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![DevilX](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@DevilX](https://forum.freifunk.net/u/DevilX)\
**Post date:** [9. April 2017 um 09:17 UTC](https://forum.freifunk.net/t/verbindungsabbrueche-fragen-zur-meshkonfiguration/14766/3 "2017-04-09T09:17:36Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![DevilX](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@DevilX](https://forum.freifunk.net/u/DevilX)\
**Post date:** [12. April 2017 um 07:45 UTC](https://forum.freifunk.net/t/verbindungsabbrueche-fragen-zur-meshkonfiguration/14766/4 "2017-04-12T07:45:17Z")

</div>

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 😄

---

<div class="post-metadata">

**Author:** ![PetaByteBoy](https://forum.freifunk.net/user_avatar/forum.freifunk.net/petabyteboy/32/26471_2.png) [@PetaByteBoy](https://forum.freifunk.net/u/PetaByteBoy)\
**Post date:** [12. April 2017 um 08:06 UTC](https://forum.freifunk.net/t/verbindungsabbrueche-fragen-zur-meshkonfiguration/14766/5 "2017-04-12T08:06:02Z")

</div>

> [@Probleme Kompilieren Gluon unter Arch Linux](https://forum.freifunk.net/t/probleme-kompilieren-gluon-unter-arch-linux/14636/59):
>
> Kann es sein das ich mich selber zu Blase Wlan mäßig

-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.

---

<div class="post-metadata">

**Author:** ![DevilX](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@DevilX](https://forum.freifunk.net/u/DevilX)\
**Post date:** [12. April 2017 um 08:37 UTC](https://forum.freifunk.net/t/verbindungsabbrueche-fragen-zur-meshkonfiguration/14766/6 "2017-04-12T08:37:11Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![MPW](https://forum.freifunk.net/user_avatar/forum.freifunk.net/mpw/32/4433_2.png) [@MPW](https://forum.freifunk.net/u/MPW)\
**Post date:** [12. April 2017 um 08:51 UTC](https://forum.freifunk.net/t/verbindungsabbrueche-fragen-zur-meshkonfiguration/14766/7 "2017-04-12T08:51:59Z")

</div>

> [@DevilX](#):
>
> sollten das hier abgespalten werden

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

> [@DevilX](#):
>
> oder per Lan-Mesh

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.

---

<div class="post-metadata">

**Author:** ![DevilX](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@DevilX](https://forum.freifunk.net/u/DevilX)\
**Post date:** [12. April 2017 um 08:59 UTC](https://forum.freifunk.net/t/verbindungsabbrueche-fragen-zur-meshkonfiguration/14766/8 "2017-04-12T08:59:36Z")

</div>

Vielen Dank fürs verschieben 😄

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.

---

<div class="post-metadata">

**Author:** ![PetaByteBoy](https://forum.freifunk.net/user_avatar/forum.freifunk.net/petabyteboy/32/26471_2.png) [@PetaByteBoy](https://forum.freifunk.net/u/PetaByteBoy)\
**Post date:** [12. April 2017 um 10:30 UTC](https://forum.freifunk.net/t/verbindungsabbrueche-fragen-zur-meshkonfiguration/14766/9 "2017-04-12T10:30:54Z")

</div>

@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?

---

<div class="post-metadata">

**Author:** ![DevilX](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@DevilX](https://forum.freifunk.net/u/DevilX)\
**Post date:** [12. April 2017 um 10:53 UTC](https://forum.freifunk.net/t/verbindungsabbrueche-fragen-zur-meshkonfiguration/14766/10 "2017-04-12T10:53:47Z")

</div>

@PetaByteBoy Danke,

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

---

<div class="post-metadata">

**Author:** ![adorfer](https://forum.freifunk.net/user_avatar/forum.freifunk.net/adorfer/32/17910_2.png) [@adorfer](https://forum.freifunk.net/u/adorfer)\
**Post date:** [12. April 2017 um 14:06 UTC](https://forum.freifunk.net/t/verbindungsabbrueche-fragen-zur-meshkonfiguration/14766/11 "2017-04-12T14:06:15Z")

</div>

Wir sind hier wieder bei

> [@Wie Debugge ich einen nicht funktionierenden Node](https://forum.freifunk.net/t/wie-debugge-ich-einen-nicht-funktionierenden-node/4625):
>
> ich habe mal hier einen schäbigen Anfang gewagt: [https://wiki.freifunk.net/Mein\_Freifunk\_funktioniert\_nicht\_mehr](https://wiki.freifunk.net/Mein_Freifunk_funktioniert_nicht_mehr)

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.

> [@DevilX](#):
>
> nscheinend keine Daten mehr übertragen werden

(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.)

---

<div class="post-metadata">

**Author:** ![DevilX](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@DevilX](https://forum.freifunk.net/u/DevilX)\
**Post date:** [13. April 2017 um 07:30 UTC](https://forum.freifunk.net/t/verbindungsabbrueche-fragen-zur-meshkonfiguration/14766/12 "2017-04-13T07:30:08Z")

</div>

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](http://www.google.com) = ~150 ms  
Gerät 2: ping6 2001:4860:4860::8888: = 160 ms  
Gerät 2: ping6 [www.google.com](http://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)

> **[logread\_ffe - Pastebin.com](https://pastebin.com/ytpVUfyL)**
>
> Pastebin.com is the number one paste tool since 2002. Pastebin is a website where you can store text online for a set period of time.

---

<div class="post-metadata">

**Author:** ![DevilX](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@DevilX](https://forum.freifunk.net/u/DevilX)\
**Post date:** [13. April 2017 um 09:39 UTC](https://forum.freifunk.net/t/verbindungsabbrueche-fragen-zur-meshkonfiguration/14766/13 "2017-04-13T09:39:46Z")

</div>

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](http://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)

```

---

<div class="post-metadata">

**Author:** ![PetaByteBoy](https://forum.freifunk.net/user_avatar/forum.freifunk.net/petabyteboy/32/26471_2.png) [@PetaByteBoy](https://forum.freifunk.net/u/PetaByteBoy)\
**Post date:** [13. April 2017 um 09:57 UTC](https://forum.freifunk.net/t/verbindungsabbrueche-fragen-zur-meshkonfiguration/14766/14 "2017-04-13T09:57:20Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![DevilX](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@DevilX](https://forum.freifunk.net/u/DevilX)\
**Post date:** [13. April 2017 um 10:06 UTC](https://forum.freifunk.net/t/verbindungsabbrueche-fragen-zur-meshkonfiguration/14766/15 "2017-04-13T10:06:46Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![adorfer](https://forum.freifunk.net/user_avatar/forum.freifunk.net/adorfer/32/17910_2.png) [@adorfer](https://forum.freifunk.net/u/adorfer)\
**Post date:** [13. April 2017 um 10:14 UTC](https://forum.freifunk.net/t/verbindungsabbrueche-fragen-zur-meshkonfiguration/14766/16 "2017-04-13T10:14:23Z")

</div>

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…

---

<div class="post-metadata">

**Author:** ![PetaByteBoy](https://forum.freifunk.net/user_avatar/forum.freifunk.net/petabyteboy/32/26471_2.png) [@PetaByteBoy](https://forum.freifunk.net/u/PetaByteBoy)\
**Post date:** [13. April 2017 um 10:14 UTC](https://forum.freifunk.net/t/verbindungsabbrueche-fragen-zur-meshkonfiguration/14766/17 "2017-04-13T10:14:31Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![adorfer](https://forum.freifunk.net/user_avatar/forum.freifunk.net/adorfer/32/17910_2.png) [@adorfer](https://forum.freifunk.net/u/adorfer)\
**Post date:** [13. April 2017 um 10:17 UTC](https://forum.freifunk.net/t/verbindungsabbrueche-fragen-zur-meshkonfiguration/14766/18 "2017-04-13T10:17:59Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![DevilX](https://forum.freifunk.net/letter_avatar_proxy/v4/letter/d/cdc98d/32.png) [@DevilX](https://forum.freifunk.net/u/DevilX)\
**Post date:** [13. April 2017 um 10:51 UTC](https://forum.freifunk.net/t/verbindungsabbrueche-fragen-zur-meshkonfiguration/14766/19 "2017-04-13T10:51:36Z")

</div>

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 ~]$

```

---

<div class="post-metadata">

**Author:** ![PetaByteBoy](https://forum.freifunk.net/user_avatar/forum.freifunk.net/petabyteboy/32/26471_2.png) [@PetaByteBoy](https://forum.freifunk.net/u/PetaByteBoy)\
**Post date:** [13. April 2017 um 11:35 UTC](https://forum.freifunk.net/t/verbindungsabbrueche-fragen-zur-meshkonfiguration/14766/20 "2017-04-13T11:35:48Z")

</div>

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.

[Nächste Seite](https://forum.freifunk.net/t/verbindungsabbrueche-fragen-zur-meshkonfiguration/14766.md?page=2)
