Wifimeshrouter baut keinen VPN-Tunnel auf (Router "spinnen" seit kurzem)

Hallo Liste,
hallo @utzer,

habe seit kurzem Probleme mit einigen Router:

Offensichtlich wurde das Problem, dass sich die WLAN-Client nicht ins Internet „einwählen“ können. Sie erhalten einfach keine IP-Adresse vom Router zugeteilt.

Auf der Router-Console (per SSH/IPV6 kann ich alle Router erreichen!) fällt zuerst auf, dass diese kein korrektes Datum haben (12., 14., 23., 26. Januar).
Im logread kann ich dann nachverfolgen, dass die verschiedensten Server abgefragt werden und nicht aufgellöst werden können, z.B.:

daemon.info fastd[1377]: resolving host 'fastd01.ffrek.de' for peer <mesh_VPN_backbone_peer_1>
daemon.info fastd[1377]: resolving host 'fastd01.ffrek.de' failed: Name or service not known

Nacheinander werden so alle hosts durchprobiert, aber keiner gefunden.

Merkwürdig ist, dass manche Router funktionieren und manche leider nicht. Und dies unabhängig davon, ob sie per WAN-Port am Internet sind oder nicht. Auch kann ich den Fehler nicht auf ein Model bzw. eine Rev. einschränken.
Alle haben den identischen FW-Stand, der bislang reibunslos funktionierte.

Hat jemand ähnliche/identische Probleme bzw. was mir viel wichtiger wäre: eine Lösung?

Schönen Abend und einen guten Wochenstart!

ich komme nicht aus eurer comunity : dennoch ein paar ideen

  1. das mit der Uhrzeit ist „logisch“ wenn die keine Connection haben
  2. fastd ist in vielen Comunitys so, das meshende Router da „extra“ failen .da die ja meshen sollen
  3. du schreibst das das auch via WAN-uplink nicht geht:
    dazu:
  4. geht das sonst? also computer oder so klappen an dem Port … mind. die lämpchen leuchten, kein fancy (only trusted) MAC Filter oder sowas?
  5. kannst du ping nach draussen machen? ping auf IP machen? ping auf deine Fritzbox(oder woran der router dann hängt) machen?
ping fastd01.ffrek.de
PING 1.wupper.ffrl.de (151.80.64.188) 56(84) bytes of data.
64 bytes from b01.wupper.ffrl.de (151.80.64.188): icmp_req=1 ttl=57 time=35.5 ms

sieht danach aus das du keinen Uplink hast, warum auch immer … hoffe das sind ideen die dir weiterhelfen

@PetaByteBoy schau Dir das mal an … das DNS spinnt.

Wo liegt denn der DNS-Server für ffrek.de?

Keine Ahnung … ist das nicht so was wie ffgek? Wenn nicht, dann entschuldige das Anstupsen.

zu viele CNAMEs verderben den Brei …

Wurden in den letzten Tagen denn irgendwelche Änderungen insbesondere an den Domains der fastd Server vorgenommen? Bin noch mit dem Zug unterwegs und erst heute Nachmittag zuhause, dann kann ich mir das mal anschauen.

Ich hab ja nur cname auf die fastd von Wupper gesetzt.

Es wurde nichts geändert.

Ich habe gerade keine shell zum graben. Ich glaube ffgek.de liegt bei Andreas. ffrek.de gehört jedenfalls nicht mir. Kann aber sein dass der Nameserver mir gehört - weiß ich nicht.

Edit: ffrek.de hat keine Authority section, liegt also in den Händen des Besitzers.
Die CNAMEs von fastd0x.ffrek.de zu x.wupper.ffrl.de scheinen direkt eingetragen zu sein.
Ich sehe noch nicht so ganz wie der Nameserver haken soll… Bei mir funktioniert das Auflösen von fastd0x.ffrek.de nach CNAME x.wupper.ffrl.de ohne Probleme.

Nur für’s Protokoll:
ffrek.de sagt mir gar nichts. Ich wüsste ohne Nachzuschauen nichteinmal ob es da um Recklinghausen oder den Rhein-Erft-Kreis geht.
ffgek.de liegt bei der nadeshda und dort wird bis Mitte des Monats (April 2016) jemand gesucht, der das übernehmen mag, Das wird wird -wie von Heinz angekündigt für freifunk-gelsensenkirchen.de- seitens der bisherigen Betreibenden zum Monatsende aufgegeben.

Das ist schade.

Das Problem kann ich jetzt bei mir nicht nachvollziehen, kann es eventuell sein, dass der Port 50169 nicht erreichbar ist?

Bei mir kommt das sowas:

Mon Apr  4 21:25:56 2016 daemon.info fastd[1412]: refreshing session with <mesh_vpn_backbone_peer_peer0>
Mon Apr  4 21:25:56 2016 daemon.info fastd[1412]: sending handshake to <mesh_vpn_backbone_peer_peer0>[[2001:41d0:c:95c::176]:50169]...
Mon Apr  4 21:25:57 2016 daemon.info fastd[1412]: received handshake response from <mesh_vpn_backbone_peer_peer0>[[2001:41d0:c:95c::176]:50169] using fastd v17
Mon Apr  4 21:25:57 2016 daemon.info fastd[1412]: [2001:41d0:c:95c::176]:50169 authorized as <mesh_vpn_backbone_peer_peer0>
Mon Apr  4 21:25:57 2016 daemon.info fastd[1412]: new session with <mesh_vpn_backbone_peer_peer0> established using method `salsa2012+umac'.

Sehr seltsam, ich habe da nichts geändert und @phip sagte ja auch er hat nicht geändert.

Jetzt so leider nicht. Sieht denn der irgendwer etwas bei der Domäne, bzw. bei deren Fastd Nodes? Viellleicht etwas im Log?

DNS? Einen eigenen haben wir nicht, aber ich habe cname Records gesetzt, damals mal in Absprache mit Dir @PetaByteBoy

Lieber DNS Einträge auf die IP setzen statt cname?

Hmm ja ich habe jetzt nur mal einen Ping probiert, wenn Du schon sagst das der Teil funktioniert.

Ja genau!

Was kann ich denn noch probieren, bin zwar morgen unterwegs, aber ich kann auf einen Router zugreifen über ein paar SSH hops.

nein, bei Wupper-Servern direkt X.wupper.ffrl.de in die Firmware eintragen, das könnte viele Fehlerquellen sparen … denn wenn es nicht läuft, dann läuft es in ganz Wupper nicht. … aber erst bei der nächsten Firmware-Version.

Das (DNS)-Problem sollte vor Ort beim Threadstarter untersucht werden. IPv6? Lahmer/gesperrter DNS … Gründe, Gründe …

Du hast noch mit mir geschimpft als ich das gemacht habe und gesagt ich soll für gl eigene DNs nehmen, damit man Umbiegen kann…

Wie kommst du darauf es sei ein DNS-Problem?

ich muss wohl an mir richtig arbeiten, um nicht schimpfend zu wirken wenn ich etwas erkläre

Ja, damit Du bei Bedarf umbiegen kannst wenn ich zu Tisch bin und es einen Fehler gibt, denn gl ist eine andere Hausnummer … gl is not amused wenn die FF-Leuchttürme ausfallen … ein CNAME ins Nichts bei einem durchgedrehten Gateway bewirkt Wunder

Auch wenn sich aktuell die Situation an den Routern „normalisiert“ zu haben scheint, sehen die Logfiles nicht „optimal“ aus.

„Haupt-Router“ mit Internet-Uplink (FF-BM-PUL-SDF-1000, TP-Link TL-WR841N/ND v9):

Mon Apr  4 23:26:22 2016 daemon.info fastd[1428]: refreshing session with <mesh_vpn_backbone_peer_peer0>
Mon Apr  4 23:26:22 2016 daemon.info fastd[1428]: sending handshake to <mesh_vpn_backbone_peer_peer0>[151.80.64.176:50169]...
Mon Apr  4 23:26:22 2016 daemon.info fastd[1428]: received handshake response from <mesh_vpn_backbone_peer_peer0>[151.80.64.176:50169] using fastd v17
Mon Apr  4 23:26:23 2016 daemon.info fastd[1428]: 151.80.64.176:50169 authorized as <mesh_vpn_backbone_peer_peer0>
Mon Apr  4 23:26:23 2016 daemon.info fastd[1428]: new session with <mesh_vpn_backbone_peer_peer0> established using method `salsa2012+umac'.`

Sieht alles soweit gut aus - auch das Datum stimmt.

Router auf dem sich die meisten User einwählenn ohne Internet-Uplink (FF-BM-PUL-SDF-1003, TP-Link TL-WR841N/ND v10):

Tue Jan 12 07:19:47 2016 daemon.info fastd[1384]: resolving host `fastd06.ffrek.de' for peer <mesh_vpn_backbone_peer_peer6>...
Tue Jan 12 07:19:47 2016 daemon.info fastd[1384]: resolving host `fastd06.ffrek.de' failed: Name or service not known
Tue Jan 12 07:19:47 2016 daemon.info fastd[1384]: resolving host `fastd00.ffrek.de' for peer <mesh_vpn_backbone_peer_peer0>...
Tue Jan 12 07:19:47 2016 daemon.info fastd[1384]: resolving host `fastd00.ffrek.de' failed: Name or service not known

Kann es sein, dass Router ohne Internet-Uplink die fastdXX-Server nicht auflösen können und können müssen?
Dann war das vielleicht die falsche Fährte.
Doch die richtige Zeit sollten sie trotzdem bekommen, oder??

Unabhängig davon können sich die Handys nun wieder ins Freifunk-Netz einwählen (bekommen auch eine IP-Adresse zugewiesen), was kürzlich nicht ging :frowning:

Auf der einen Seite liebe ich ein selbstheilendes Netzwerk, aber auf der anderen Seite mag ich kein Netzwerk, was ab und an nicht zuverlässig funktioniert.

Ich werde es weiter beobachten und mich bei erneuten Problemen wieder melden.
Vielen Dank an alle, die sich auf die Fehlersuche gemacht haben!

Oh je :facepalm: ich bin unfähig Endnutzer zu betreuen, wenn ich zu wenige Informationen erhalte …

das müssen sie nicht … das ist Freifunk. Sie kommunizieren über ein vermaschtes Ad-Hoc-WLAN miteinander. Sorge dafür, dass die Funkstrecke gut ist und es wird alles gut.

Ja, es fehlte die Information, dass es sich nicht um einen Uplink-Knoten handelte

Nicht wenn utzer keinen NTP-Server in der Freifunk-Wolke betreibt. Ist aber für derer Funktion auch nicht so wichtig.

das sind endlich gute Nachrichten

war die WLAN-Verbindung der Freifunkknoten untereinander nicht optimal? Hatte ein Nachbar die Übertragung mit seinem Datenverkehr „gestört“?

Das ist Freifunk … Du musst vor Ort selbst alles richtig machen und für gute verbindung der Geräte untereinander sorgen. Wenn die Gateways ausfallen und es keinen Internet im Freifunk mehr gibt, dann habe ich Schuld.

Viel Spaß mit Freifunk und alles Gute

Hallo @phip,

eigentlich wollte ich schon lange im Bett sein, schlage mich mit den Router rum (um den Fehler zu finden bzw. einzukreisen) und nun bin ich auch noch angefressen :frowning:

Als „unfägigen Endnutzer“ möchte ich mich nicht bezeichnen…

Ich versuche hier im Dorf Freifunk (auch wegen den Flüchtlingen) voranzubringen, höre dann, dass sich die Handys nicht in die Router einwählen können, teste das bei meinen eigenen Routern und stelle fest, dass ich mich mit dem Handy auch nicht einwählen kann. Für mich kein Problem, da ich ja noch mein eigenen Netz habe. Aber die Flüchtlinge und die, denen ich Router gegeben habe, sind frustiert.

Da begebe ich mich ersteinmal selbst auf die Suche, schaue mir die Logfiles an und stelle zunächst fest, dass die meisten ein falsches Datum / eine falsche Uhrzeit haben, was in einem echten Netzwerk schon mal gar nicht gut ist…
Dann sehe ich im logread, dass dieser von Meldungen zugemüllt werden, so wie ich geschrieben habe…

Und dann habe ich ja auch deutlich geschrieben:

Eigentlich schade, dass die Fehlersituation aktuell nicht mehr besteht…

Gute Nacht!

du hast mich falsch verstanden, ich schrieb

da steht deutlich „ich“, also nicht Du … es ist aber auch wirklich spät und ich kontaktiere wohl nicht

ich find’s gut, dass nun alles läuft.

Das Problem ergibt sich daraus, dass der TS mit Informationen gegeizt hat.
(keine FW-Version, eine Node-ID, und keine Info zum Betriebsmodus)

Und hier niemand gefragt.
Da wir ja unhöflich erscheinen, wenn wir jeden Fragenden erstmal mit Gegenfragen bombardieren.

1 Like