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