Es gibt massive DNS-Probleme. Das interne FF-Netz wird sauber angezeigt und scheint auch zu arbeiten. Wenn ich mit dem Tablet über den offiziellen WLAN des Speedport Pro Plus einen Namen aufgelöst habe, kann ich die Domain anschließend auch über das FF-Mesh erreichen. (Domainname <-> IP ist noch im Cache). Neue Namen werden nicht aufgelöst.
Wie kann ich nun (mit dem Linux-Lappi) feststellen, ob es es an
Firewall des Speedport (Tunnel arbeitet nicht sauber…)
DHCP vom FF
DNS vom FF
irgendein Mischmaschproblem
liegt?
Kann man die Firewall des Speedport Pro Plus konfigurieren? Gibt es da einen speziellen Modus?
Hier ist mir nicht klar, ob du mit Mesh einen Client direkt am AP mit VPN Uplink, Client an entferntem Knoten, einen entfernten Knoten oder das Tablet nach einem wechsel vom Netz des Speedports ins Freifunk Netz meinst.
Da die Knoten selbst seit einigen Jahren keinen DNS Cache bereitstellen vermute ich mal letzteres - Ist das Problem auf dieses eine Endgerät beschränkt? Welchen DNS server bekommst du über DHCP / RA zugewiesen?
Diese Zuweisung sollte nicht die Nexthop Adresse sein, da die Site deiner Community keine DNS Server für die Knoten konfiguriert.
Hallo,
ich versuche es nochmal.
Ich muss von zuhause immer erst eine Gerätekette aufbauen, damit ich Zugriff zur passenden Domain habe. Die wurden im harz.freifunk.net getrennt, damit das Netz nicht abkotzt. Mobil habe ich da noch keine Lösung gefunden. Also WAN-Anschluss, Uploader mit passender Domain, per LAN ans Lappi ran, denn per WLAN geht es ja nicht sicher wegen gleichlautender SSID für alle Domains.
Also die Uploader Freifunk Harz - loading... und Freifunk Harz - loading... hängen beide an LAN-Schnittstellen desselben Telekom Speedport Pro Plus Hybrid (DSL + LTE).
Leider hatte ich jetzt in der Aufbauphase schon mehrmals keine Namensauflösung in den beiden FF-Mesh-Netzen. Ich muss nun prüfen, woran das liegt. Geht schon der DHCP-Service des Telekom-Speedport nicht, oder streikt der DHCP-Client auf den Uploadern?
Sind die VPN-Tunnel ok? Oder darf man nicht mehrere VPN-Tunnel gleichzeitig zu den Freifunk-Gateways über einen einzigen DSL-Anschluss aufbauen?
Wie kann ich das möglichst alles per SSH prüfen?
Zur Zeit komme ich von zuhause drauf auf alle FF-Router des Systems.
Welche Tools per SSH haben wir da für Gluon-Systeme?
DNS-Test (host, ping, …) auf der Node zu einer beliebigen Domain
Speedtest ins kommerzielle Internet
interner Speedtest von einer FF-Node zu einer anderen
Schwierig das nachzuvollziehen, was da überhaupt Fakt ist. Mit dem Tablet komme ich nicht an die Daten. Ins betroffene Objekt komme ich auch nur schwierig rein. Sind alles Ferienwohnungen. Keiner da.
Ich habe jetzt zuhause einen Stack aufgebaut:
DSL-Zugang Kabel → Router mit der betroffenen Domain → Per LAN ans Laptop.
WLAN ist ausgeschaltet, weil sich der mit meinen FF-Nachbarn in meiner Domain zuhause beißen würde.
Zuhause habe ich aber eine Fritzbox 7590 und einen 1&1-Vertrag.
Gegen 13:00 Uhr kann ich heute ins Haus. Was müsste ich denn in welcher Reihenfolge anschließen und feststellen, um den Fehler einzukreisen?
Mit SSH komme ich nur auf die FF-Router, wenn die einen funktionierenden Tunnel aufbauen konnten und eine IP bezogen haben. Oder gibts eine Möglichkeit, einen Offline-Router per SSH zu erreichen?
Wie werden denn DHCP und DNS überhaupt bedient? Geschieht das über den VPN-Tunnel? Oder sind dafür die lokalen Einstellungen des Speedport Pro zuständig?
Wofür sind in der Node-Konfiguration die Datenfelder für zusätzliche Nameserver? Gehen die durch den Tunnel, oder daran vorbei auf den DSL-Anschluss?
Ich habe die starke Vermutung, dass es weder ein Problem vom Speedport-Pro-Plus ist, noch eines „nur mit DNS“, sondern dass da viel mehr irgendwie nicht richtig funktioniert. (Es also nicht helfen würde, „nur DNS“ zu fixen. Oder festzustellen: „DNS ist nur als Folgefehler defekt. Case/Ticket closed“)
Also, Deine FF-Archer-C7 nutzten vom Speedport dessen DHCP-Server (Zuweisung einer lokalen IPv4-Adresse), bekommen darüber den zu nutzenden DNS-Server — und das war’s. Jeder C7 baut dann zu [1-8].4.gw.harz.freifunk.net, Port 10401 (1.4.gw…) bis 10408 (8.4.gw… — 4.4.gw… bis 8.4.gw… gibt’s derzeit schein’s nicht), per UDP eine Verbindung auf.
Sofern die C7 also auf der Karte auftauchen, klappt diese Ebene, und der Speedport ist raus.
Wenn Dein Client im (Harzer, generell aber jedem Gluon-basierten) Freifunk-Netz ist, bekommt dieser seine IPv4-Adressen vom Freifunk-DHCP-Server und darüber auch die (IPv4-) Nameserver. IPv6-Adressen (und v6-DNS-Server) bekommt der Client ebenfalls aus dem Freifunk-Netz, allerdings indirekt — Stichwort SLAAC.
Sprich: Wenn Du im Freifunk-Netz DNS-Probleme hast, liegen die im internen Freifunk-Netz – zwischen Deinem Knoten und dem Freifunk-DNS-Server – oder jenseits davon – zwischen dem Gateway- bzw. DNS-Server und dem Internet –, nicht jedenfalls auf Ebene des Zugangsrouters (hier: Speedport Pro).
Tja, doof; 127.0.0.53 ist systemd-Unfug, mußt Du gucken, was systemd-resolvd tatsächlich abfragt. Oder schmeiß’ den systemd-resolvd-Mist vom System oder nimm’ Windows/Android zum Debuggen …
So in etwa, nur mit Adressen aus 10.4.0.0/16 statt 10.234.0.0/16 und mit eher welchen aus fd0e:8db3:d504::/64 statt 2001:bf7:1310:128::/64 für IPv6-Resolver, sollte das bei Android aussehen.
Entweder tut einer/tun alle der in „Freifunk Harz West“ an den Client übermittelten DNS-Server nicht, was sie sollen (Rekursivität aus dem FF-Netz nicht erlaubt?), oder aber Dein Linux-Test-Laptop tut schlicht nicht, was er soll?
Die Beispiel-dig-Aufrufe zeigen allerdings, daß die DNS-Auflösung funktioniert?
Das ist dann auch zuhause hinter einem FritzBox/1&1-Anschluss.
Beim betroffenen Netz konnte ich das noch nicht im Fehlerfall ermitteln.
Das Probleme ist: schalte ich beim Speedport die LTE-Unterstützung ab, funktioniert alles ganz normal (wie gewünscht). Schalte ich sie ein, können über den fastd-Tunnel (…) sofort keine Namen mehr aufgelöst werden.
Die Telekom hat aber vermutlich Kenntnis von dem Problem. Man hat der Wandlung des Vertrages in 2x 50/10 ohne LTE sofort zugestimmt. Da haben wir dann zwar immer noch nicht die gewünschten 40MBit/s Upload, aber es ist besser als mit einer 50/10-Leitung.
Das ist technisch AFAICS nicht möglich: der Speedport Pro kann bestenfalls Pakete des fastd-Tunnels nicht über die Mobilfunkverbindung schicken, nicht aber DNS-Pakete im fastd-Tunnel erkennen und blockieren. Bei L2TP wäre das denkbar, nicht aber bei verschlüsselten Verbindungen wie bei fastd.
EDIT: Soll heißen: falls die Hybrid-Technik das Problem wäre, dürfte mit aktiviertem »LTE-Booster« Freifunk gar nicht mehr funktionieren (und nicht nur DNS im Freifunk nicht).
Das klingt nach einem MTU-Problem.
d.h. aus irgendeinem Grund die Pakete nicht mehr richtig fragmentiert werden auf einem der Layer dieses Stacks (ich spare mir jetzt die Aufzählung, weil spekulativ, kenne die site.conf der FF-Firmware nicht) was nicht mehr „durchpasst“.
Ich weiss zwar nicht, wo es da konkret beissen könnte, da müssen evtl. Leute mit Admin-Login auf den Supernodes helfen und mal tcpdumpen.
grundsätzlicherweise scheint mit dem dem SpeedportProPlus und L2TP jedoch zu funktionieren, wie unser Gerät hier seit bald 3 Wochen tut. VDSL synced auf rund 12MBit/s, die restliche Bandbreite kommt via LTE, d.h. das mit dem Offloading funktioniert auch bei Speedtests „im Freifunk“ bei über 50MBit/s.
(Und ja, die User in der Unterkunft nutzen auch DNS-Auflösung, also nur um es explizit zu erwähnen.)
An der site.conf ist wirklich nix besonders, wir haben für die Telekom-Hybrid-Nutzung nichts angepasst, weder in Firmware noch auf den Supernodes (die nach Münsteraner Ansible-Rollen aufgesetzt sind.)
Dies sollte sich durch einen „tracepath 1.4.gw.harz.freifunk.net“ vom Linux-Client am Speedport klären lassen (notfalls nach Ziehen der DSL-Verbindung)?
Es gibt vermutlich unterschiedliche Szenarien sowohl für Supernode-Verbindung IPv4 vs Supernode-Verbindung IPv6. Und FF-payload ipv4 versus ipv6 payload (und kombinationen)
Evtl. gibt es aber auch eine race condition in der batman fragmentation wie damals bei batman-adv-v15: double fragmentation issue (formerly: mow/mol issue) · Issue #435 · freifunk-gluon/gluon · GitHub, die z.B. ssh-sessions vom/zum knoten immer wieder hat stallen lassen, ist aber nur bei IPv6 aufgefallen. (tcp payload wurde irgendwo verworfen bei bestimmter Paketgröße, tcp keepalives gingen aber noch durch, so dass der ssh sich nicht zu helfen wusste → stall)
(In diesem Fall schonmal Glückwunsch für’s Aufspüren!)
Welche Paket-mtu produziert denn der fastd, wenn man in der gluon-site.conf keine mtu-size für das meshvpn spezifiert?
Abgesehen davon sieht es zumindest über einen speedport-pro-plus zumindest für 1500er MTU o.k. aus bei uns.
Und auch für gemäß FAQ angeommene worst-case (und garantiert suboptimale) 1566/1586 (also 1500 plus header) oder gar 1580/1600 (batman-mtu1500 plus fastd etc) funktioniert es ebenfalls über den SPpro+.
root@camp-lindung-pforte-erx-2607:~# ping -6 -c 3 -s 1500 1.4.gw.harz.freifunk.net
PING 1.4.gw.harz.freifunk.net (2a01:4f8:211:f741::2): 1500 data bytes
1508 bytes from 2a01:4f8:211:f741::2: seq=0 ttl=56 time=93.510 ms
1508 bytes from 2a01:4f8:211:f741::2: seq=1 ttl=56 time=97.540 ms
1508 bytes from 2a01:4f8:211:f741::2: seq=2 ttl=56 time=303.929 ms
--- 1.4.gw.harz.freifunk.net ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 93.510/164.993/303.929 ms
root@camp-lindung-pforte-erx-2607:~# ping -4 -c 3 -s 1500 1.4.gw.harz.freifunk.net
PING 1.4.gw.harz.freifunk.net (148.251.123.111): 1500 data bytes
1508 bytes from 148.251.123.111: seq=0 ttl=56 time=76.525 ms
1508 bytes from 148.251.123.111: seq=1 ttl=56 time=50.719 ms
1508 bytes from 148.251.123.111: seq=2 ttl=56 time=73.258 ms
--- 1.4.gw.harz.freifunk.net ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 50.719/66.834/76.525 ms
root@camp-lindung-pforte-erx-2607:~# traceroute -4 1.4.gw.harz.freifunk.net
traceroute to 1.4.gw.harz.freifunk.net (148.251.123.111), 30 hops max, 38 byte packets
1 192.168.2.1 (192.168.2.1) 1.652 ms 0.728 ms 1.505 ms
2 * * *
3 * * *
4 195.145.92.86 (195.145.92.86) 54.093 ms 195.145.92.110 (195.145.92.110) 66.384 ms 60.246 ms
5 d-sb1-i.D.DE.NET.DTAG.DE (62.154.43.77) 78.755 ms 81.952 ms 64.152 ms
6 217.5.113.242 (217.5.113.242) 58.616 ms 217.5.114.18 (217.5.114.18) 41.549 ms l-sc1-i.L.DE.NET.DTAG.DE (62.154.0.162) 46.995 ms
7 n-sb4-i.N.DE.NET.DTAG.DE (217.5.88.54) 50.871 ms n-sb4-i.N.DE.NET.DTAG.DE (62.154.2.254) 41.263 ms n-sb4-i.N.DE.NET.DTAG.DE (62.154.0.250) 75.996 ms
8 ex9k1.dc12.fsn1.hetzner.com (213.239.203.174) 73.586 ms 44.796 ms 36.205 ms
9 * * *
[..]
30 * * *
root@camp-lindung-pforte-erx-2607:~# traceroute -6 1.4.gw.harz.freifunk.net
traceroute to 1.4.gw.harz.freifunk.net (2a01:4f8:211:f741::2), 30 hops max, 64 byte packets
1 2a0f:b507:ff02:100::3 (2a0f:b507:ff02:100::3) 49.616 ms 64.662 ms 62.338 ms
2 ffnw.in-berlin.de (2001:67c:1400:2250::1) 75.379 ms 66.823 ms 78.314 ms
3 decix2-gw.hetzner.com (2001:7f8::616c:0:2) 61.364 ms 72.454 ms 75.972 ms
4 core24.fsn1.hetzner.com (2a01:4f8:0:3::116) 62.818 ms 64.333 ms 68.243 ms
5 ex9k1.dc10.fsn1.hetzner.com (2a01:4f8:0:3::12e) 64.904 ms ex9k1.dc12.fsn1.hetzner.com (2a01:4f8:0:3::13a) 62.985 ms 65.416 ms
6 2a01:4f8:211:f700::2 (2a01:4f8:211:f700::2) 61.767 ms 61.736 ms 83.147 ms
7 2a01:4f8:211:f741::2 (2a01:4f8:211:f741::2) 62.071 ms 85.419 ms 62.033 ms
