Augenscheinlich das Routing, sagt meine Glaskugel, und fragt nach traceroutes. Also wo lang geht’s zu 8.8.8.8, 8.8.4.4, 1.1.1.1, 9.9.9.9? Welche externe IP bekommst Du denn „zugeNATet“ (whatismyip.net o. ä.)?
(die 1.1.1.1 habe ich manuell gesetzt, zugeweisen wird die 8.8.8.8)
tracert sagt:
PS C:\Users\Besitzer> tracert 1.1.1.1
Routenverfolgung zu one.one.one.one [1.1.1.1]
über maximal 30 Hops:
1 24 ms 24 ms 24 ms 172.16.0.1
2 * * * Zeitüberschreitung der Anforderung.
3 46 ms 45 ms 46 ms 185.66.195.0
4 55 ms 55 ms 111 ms as13335.berlin.megaport.com [194.9.117.74]
5 55 ms 55 ms 55 ms one.one.one.one [1.1.1.1]
PS C:\Users\Besitzer> tracert 8.8.4.4
Routenverfolgung zu dns.google [8.8.4.4]
über maximal 30 Hops:
1 24 ms 24 ms 24 ms 172.16.0.1
2 * * * Zeitüberschreitung der Anforderung.
3 45 ms 45 ms 45 ms 185.66.195.0
4 63 ms 62 ms 62 ms as15169.berlin.megaport.com [194.9.117.34]
5 63 ms 63 ms 62 ms 108.170.241.161
6 60 ms 60 ms 60 ms 172.253.71.201
7 59 ms 60 ms 60 ms dns.google [8.8.4.4]
Ablaufverfolgung beendet.
PS C:\Users\Besitzer> tracert 8.8.8.8
Routenverfolgung zu dns.google [8.8.8.8]
über maximal 30 Hops:
1 24 ms 24 ms 24 ms 172.16.0.1
2 * * * Zeitüberschreitung der Anforderung.
3 46 ms 46 ms 46 ms 185.66.195.0
4 71 ms 71 ms 72 ms as15169.berlin.megaport.com [194.9.117.34]
5 * * * Zeitüberschreitung der Anforderung.
6 * * * Zeitüberschreitung der Anforderung.
7 * * * Zeitüberschreitung der Anforderung.
8 * * * Zeitüberschreitung der Anforderung.
9 * * * Zeitüberschreitung der Anforderung.
10 * * * Zeitüberschreitung der Anforderung.
11 * * * Zeitüberschreitung der Anforderung.
12 * * * Zeitüberschreitung der Anforderung.
13 * * * Zeitüberschreitung der Anforderung.
14 * * * Zeitüberschreitung der Anforderung.
15 * * * Zeitüberschreitung der Anforderung.
16 * * * Zeitüberschreitung der Anforderung.
17 * * * Zeitüberschreitung der Anforderung.
18 * * * Zeitüberschreitung der Anforderung.
19 * * * Zeitüberschreitung der Anforderung.
20 * * * Zeitüberschreitung der Anforderung.
21 * * * Zeitüberschreitung der Anforderung.
22 * * * Zeitüberschreitung der Anforderung.
23 * * * Zeitüberschreitung der Anforderung.
24 * * * Zeitüberschreitung der Anforderung.
25 * * * Zeitüberschreitung der Anforderung.
26 * * * Zeitüberschreitung der Anforderung.
27 * * * Zeitüberschreitung der Anforderung.
28 * * * Zeitüberschreitung der Anforderung.
29 * * * Zeitüberschreitung der Anforderung.
30 * * * Zeitüberschreitung der Anforderung.
Okay, das geht über den FFRL (Freifunk Rheinland); schön wäre noch ein Trace zum dysfunktionalen 8.8.8.8. (Mein Testsetup für solche Zwecke hat ‚leider‘ den Upstream von FFRL auf FFNW geschwenkt ;))
Warum auch immer 8.8.8.8 über FFRL Berlin nicht funktionieren sollte (dafür wäre der Trace zwecks „Beweis“ hilfreich), lösen/debuggen kann das nur das FFRL NOC. Entweder Du oder, besser, Siegener FF-Admins könnten beim FFRL ein NOC-Ticket aufmachen.
185.66.195.0 dürfte dem Trace nach jedenfalls in Berlin liegen:
root@oelde-testvm:~# traceroute 185.66.195.0
traceroute to 185.66.195.0 (185.66.195.0), 30 hops max, 60 byte packets
1 10.38.0.3 (10.38.0.3) 0.874 ms 0.925 ms 0.919 ms
2 ffnw-b.in-berlin.de (217.197.83.216) 13.998 ms 13.984 ms 14.067 ms
3 185.66.195.0 (185.66.195.0) 13.956 ms 13.942 ms 14.026 ms
Offen bleibt für mich die Frage, warum a) sich sonst niemand aus Siegen (oder anderen FFRL-versorgten Netzen) meldet und b) warum FF SIegen nur 1 DNS-Resolver per DHCP rausgibt — bis zu drei sind möglich, und dann würde ein nicht erreichbarer Resolver schlimmstenfalls zu Verzögerung, aber nicht zur Unbenutzbarkeit führen.
Das finde ich auch komisch, vielleicht hat es ja mit der neuen Firmware für den router zu tun und der scheint hier nicht sehr verbreitet zu sein, hier gibt es fast nur WR1043N…
Ich fahre später mal rum und probiere es an anderen FF Routern in der Nähe aus und berichte. Generell habe ich schon oft Klagen gehört, dass ff hier in der Gegend sehr schlecht funktionieren solle, aber ich habe das nie geprüft.
Mehr als 1 DNS wäre sicher besser, aber das weiss ich leider auch nicht.
Ich habe es an einem anderen Internetanschluss mit einem anderen Router (WA901ND V3.1) (ebenfalls aktuelle Firmware von obigem Link) und einem anderen Endgerät (Windows Notebook) probiert.
Selber Effekt: Nur ein DNS 8.8.8.8 und dieser kann nicht erreicht werden. Wenn ich DNS manuell auf 1.1.1.1 setze geht das Internet, wenn auch etwas träge.
Unser Nachbar (ein paar Häuser weiter) hat einen TP-Link TL-WR1043N/ND v2 mit 202205051826 / gluon-v2021.1.2+ (gleiche Firmwareversion wie meine Router).
Dort bekommt man neben der 8.8.8.8 auch zwei ipv6 DNS server (meine Internetanschlüsse sind reine V4 Anschlüsse, ich nehme an daher gibt bei mir keine V6 DNS server ?)
Vielleicht fällt das Problem daher bei vielen Anschlüssen nicht auf weil alles über V6 läuft?
Ich habe nun mal im Config Interface des Router bei WAN V6 deaktiviert, das hat aber nichts gebracht. Einen Anschluss mit V6 habe ich auf die schnelle nicht zur Hand.
Das problem wurde temporör duch FFFlo durch setzen von 1.1.1.1 als DNS gelöst, aber 8.8.8.8 lässt sich noch immer nicht pingen, hoffentlich wird es da eine dauerhafte Lösung geben.
Sorry, übersehen. Ja, das sieht nach Rückroutenproblem aus, warum auch immer.
Jenseits des Default-Gateways ist – stark vereinfacht – der lokale Knoten außen vor. Also egal, ob TP-Link 841 oder Fritzbox 4040. Unterschied kann das Gateway machen, beim FFRL kam es gelegentlich zu blackholing nur über bestimmte Regionen/Backbonestandorte. Sprich: wenn das Siegener Gateway, mit dem der Siegener Freifunkknoten verbunden ist, nicht über FFRL in Berlin, sondern Frankfurt oder Düsseldorf routet, mag es mit 8.8.8.8 auch tun. Auch ist das Gateway zuständig für die Vergabe der (IPv4-) Resolveradressen; das kann also auch einen Unterschied machen.
Nein, zwei Paar Schuhe. Dein Internetzugang wird verwendet, um – sehr vereinfacht – das Funkmodul Deines Kontens zum Gateway zu bringen. Die 172.16.0.1 ist nicht Dein lokaler Freifunkknoten, sondern die Adresse des Gateways in einem RZ. Was Du im Freifunk-Netz siehst, hat nichts mit dem zu tun, was außerhalb passiert. Im FF-Netz – bei heutigen Gluon-basierten Netzen – hast Du immer IPv6 (aber teilweise nur als fdXX::/64, je nach Community).
Das mag sein, hängt von den Einstellungen der Community in der Firmware bzw. auf den Gateways ab; ULA-Adressen sind auch nur bedingt nützlich für Clients. Woraus ich hinauswollte: die Knoten haben im (Gluon-) Freifunk-Netz nur IPv6-Adressen, darüber wird z. B. die Firmware aktualisiert oder der Kartendienst realisiert. (Und wenn man schon IPv4 über den FFRL macht, wäre ebenso Public-IPv6 darüber zu tun eigentlich eine sehr tiefhängende Frucht; aber das ist natürlich jeder Community überlassen.) Wer oder was ist FFFlo?
Er ist mein Kontakt zum Freifunk der Region, keine Ahnung wie sein Synonym hier im Forum ist, aber er hat geholfen und die DNS IP geändert der der DHCP Server verteilt, seit dem funktioniert das netz für mich mit meinen Routern. Auch hat er ein Ticket wegen der nicht funktionierenden 8.8.8.8 aufgemacht, wird sich hoffentlich klären lassen.