Node bleibt nach Zwangstrennung offline in restriktivem (Fritzbox-)Gastnetz

Grashuepfer · 4. März 2020 um 06:31

Hallo zusammen!

Seit dem letzten Wochenende bin ich Freifunker und funke als
FF-DO-GruenerBogen mit TP-Link TL-WR940N v6 und der Firmware 2.0.4 / gluon-v2017.1.8.
Ich habe den Router an meine Fritzbox 7490 angeschlossen, an LAN4 mit Gastzugang und freigeschalteten Ports wie in Freifunk Router am Gastzugang einer Fritzbox | Freifunk Göttingen erklärt.
Erst einmal ist keine Verbindung zustande gekommen, am nächsten Tag funktionierte es dann aber doch. Der Router wurde auch auf der Karte angezeigt als online.
Nun habe ich folgendes Verhalten:
Wenn die FritzBox um 4:11 Uhr eine neue IP-Adresse wegen der Zwangstrennung des Providers (dokom) bekommt, geht der Freifunk-Router zeitgleich offline. Gestern habe ich dann das Duo für 30 Sekunden stromlos geschaltet, danach war alles wieder online. Heute Nacht wurde wieder um 4:11 Uhr die IP-Adresse geändert, nun hilft aber auch ein Neustart von FritzBox und TP Link nichts.
Woran liegt das und was kann ich tun?

Vielen Dank für hilfreiche Vorschläge!
Heinz-Dieter

adorfer · 4. März 2020 um 06:38

Klingt nach „Tunneldigger erkennt nicht, dass der Tunnel gestorben ist“.
Du wirst um ssh-Login auf der Konsole des Routers (auf dessen IPv6, aus dem internen Netz) und

logread -f

nicht herumkommen.
Frage mal bei Deiner Comunity nach, ob es evtl. neuere Firmware gibt. Die muss nicht besser sein, es könnte(!) aber evtl helfen, einen neueren Port des L2TP-Tunneldiggers zu verwenden.

Grashuepfer · 4. März 2020 um 06:39

Vielen Dank für den Hinweis, das werde ich mal auslesen!

efbeff · 4. März 2020 um 16:15

Dortmund ist im Forum nicht sonderlich aktiv. Versuche es besser mit der mailingliste:
https://list.free.de/listinfo/freifunk-do
Oder komm persönlich vorbei: jeden 2. Mittwoch im Monat in Hörde Cafe Aufbruch,
und jeden 3. Freitag im Langen August…
Die Firmware ist ziemlich angestaubt,
https://images.ffdo.de/ffdo_ng/domaenen/domaene05/releases/2.2.3/images/sysupgrade/
sollte es schon sein.

Grashuepfer · 6. März 2020 um 14:00

@adorfer:
Ich habe die Firmware aktualisiert und mal mit ssh logread -f gemacht:

root@FF-DO-GruenerBogen:~# logread -f
Fri Mar 6 14:54:21 2020 daemon.info td-client: Performing broker selection…
Fri Mar 6 14:54:32 2020 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds
Fri Mar 6 14:54:37 2020 daemon.info td-client: Performing broker selection…
Fri Mar 6 14:54:48 2020 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds
Fri Mar 6 14:54:53 2020 daemon.info td-client: Performing broker selection…
Fri Mar 6 14:55:03 2020 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds
Fri Mar 6 14:55:08 2020 daemon.info td-client: Performing broker selection…
Fri Mar 6 14:55:19 2020 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds
Fri Mar 6 14:55:24 2020 daemon.info td-client: Performing broker selection…
Fri Mar 6 14:55:35 2020 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds
Fri Mar 6 14:55:40 2020 daemon.info td-client: Performing broker selection…
Fri Mar 6 14:55:51 2020 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds
Fri Mar 6 14:55:56 2020 daemon.info td-client: Performing broker selection…
Fri Mar 6 14:56:07 2020 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds
Fri Mar 6 14:56:12 2020 daemon.info td-client: Performing broker selection…
Fri Mar 6 14:56:23 2020 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds
Fri Mar 6 14:56:28 2020 daemon.info td-client: Performing broker selection…
Fri Mar 6 14:56:39 2020 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds
Fri Mar 6 14:56:45 2020 daemon.info td-client: Performing broker selection…
Fri Mar 6 14:56:56 2020 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds
Fri Mar 6 14:57:01 2020 daemon.info td-client: Performing broker selection…

adorfer · 6. März 2020 um 14:40

Klingt verdächtig nach diesem Gluon-Issue:

github.com/freifunk-gluon/gluon

Node/Tunneldigger loses external (WAN) DNS resolver

opened 09:54PM - 27 Nov 19 UTC

closed 01:39PM - 14 Dec 20 UTC

RalfJung

0. type: bug 3. topic: tunneldigger

### Bug report **What is the problem?**  We have now several times seen the following effect: a node suddenly drops offline, and when logging in via SSH, the log shows many of these errors: ``` Mon Nov 25 15:02:45 2019 daemon.err td-client: Hostname resolution timed out. Mon Nov 25 15:02:45 2019 daemon.err td-client: Hostname resolution timed out. Mon Nov 25 15:02:45 2019 daemon.err td-client: Hostname resolution timed out. Mon Nov 25 15:02:45 2019 daemon.err td-client: Hostname resolution timed out. ``` However, the internet on the WAN port works fine, and a reboot fixes the problem. Seems like somehow the node "loses" its DNS server? Or maybe just tunneldigger is suddenly unable to resolve DNS names? I have a hard time debugging DNS issues on Gluon devices as there are two dnsmasq running (I suspect one is a client on the WAN and one is the DNS server for nodes in the local mesh), and I don't know which one `nslookup` uses or how to even check the WAN-side DNS config. `/etc/resolv.conf` is not useful either. Is there a guide for debugging Gluon DNS issues? **What is the expected behaviour?** The node should be able to connect to the gateway as it has a working internet connection. **Gluon Version:** Seen with v2018.2.2 and v2019.1. **Site Configuration:** https://git.hacksaar.de/FreifunkSaar/gluon-site/tree/1.8.0-exp20191120 **Custom patches:** None

Dosenfutter · 6. März 2020 um 16:24

Ich kenne Deine Community nicht, daher weiß ich nicht ob diese einen Bug enthält.
Die 2017er Version ist aber schon ziemlich alt, um es Mal „vorsichtig“ auszudrücken auch nicht mehr zu 100% sicher.

Es gibt hier 3 Lösungen:

Deine Community stellt eine neue, sichere verbesserte Firmware bereit.
Du nimmst so lange deine lokale Community keine aktuelle Firmware bereitstellt, vorübergehend die Firmware einer anderen aktiven Community.
Tipp2 bitte nur, wenn du nicht auf das Mesh Netz angewiesen bist.
Du könntest den Router täglich automatisiert neu starten. Sieh Dir dazu Mal den Link hier an:
Freifunk Router kaufen/Empfehlungen, WLAN Hotspot im Auto
Das Problem mit dem Volllaufenden RAM hast du nicht. Aber du kannst den automatischen Neustart trotzdem z. B. um 4:30 Uhr durchführen.

Ich habe den Fritz Box Gastzugang wie folgt freigeschaltet falls du es vergleichen willst:

Wenn aber der Zugang über den Gastzugang funktioniert, kann es eigentlich nicht an der Freigabe liegen.
Oder du hast zu wenig Ports freigegeben.
Beachte dass diese von Community zu Community verschieden sein können.
Worauf ich hinaus will, möglicherweise, versucht der Router nach der Trennung den nächsten Port aus einem Block, den Du nicht freigeben hast.
Möglicherweise hast Du nur den ersten Port freigeben, daher klappt es nach dem Reboot wieder. Auf Letzteres würde ich tippen.

Du kannst das ja auch Mal testen, in dem Du den Router Mal für eine Nacht an einen normalen, nicht Gastport hängst.
Ist er da auch nach der Zwangstrennung offline, oder steht das Netz dann? Wenn er an einem normalen LAN Port (kein Gastnetz) nach einer Zwangstrennung normal online ist liegt es an den Ports Deiner Freigabe.

Grashuepfer · 6. März 2020 um 17:02

Ich habe vergessen zu erwähnen, dass ich schon ein Firmware-Update gemacht hatte:
2.2.6 / gluon-v2018.2.4-1-ga9afea6d

@Dosenfutter
Vielen Dank für die Anleitung!
Ich hatte in der FritzBox wohl zu wenige UDP-Ports (9999 bis 10001) freigegeben.
Nach Erhöhung auf 10010 funktionierte es kurz, ich hatte das WLAN Freifunk.
Dann war der Router wieder offline.
Ich hatte aber mit ssh das Logfile ausgelesen:

OpenWrt 18.06-SNAPSHOT, r7945+25-83ce31d3d8

root@FF-DO-GruenerBogen:~# logread -f
Fri Mar 6 17:51:47 2020 daemon.err td-client: Broker sent us a teardown request, closing tunnel with errorcode 3!
Fri Mar 6 17:51:47 2020 daemon.notice netifd: Network device ‚mesh-vpn‘ link is down
Fri Mar 6 17:51:47 2020 daemon.notice netifd: Interface ‚mesh_vpn‘ has link connectivity loss
Fri Mar 6 17:51:47 2020 kern.info kernel: [12355.003104] batman_adv: bat0: Interface deactivated: mesh-vpn
Fri Mar 6 17:51:47 2020 kern.info kernel: [12355.036943] batman_adv: bat0: Removing interface: mesh-vpn
Fri Mar 6 17:51:47 2020 daemon.err td-client: Connection to snng-dtm02.ffdo.de lost.
Fri Mar 6 17:51:47 2020 daemon.notice netifd: Interface ‚mesh_vpn‘ is disabled
Fri Mar 6 17:51:47 2020 daemon.info td-client: Performing broker selection…
Fri Mar 6 17:51:58 2020 daemon.err td-client: No suitable brokers found. Retrying in 5 seconds
Fri Mar 6 17:52:00 2020 user.notice gluon-offline-ssid: TQ is 0, SSID is Freifunk, change to FF_OFFLINE_FF-DO-GruenerBogen

adorfer · 6. März 2020 um 17:08

Dann schau mal, ob Du in der Firewall mal den Teredo-Filter ausschalten kannst.
Und Du sollest den Knoten mal testweise ins normale Lan hängen. („am Gastnetz“ kann man sich in diversen Arten ins Knie schiessen. Weil nicht alle Communities immer klar dokumentieren, dass sie nicht noch Supernodes mit völlig anderen UDP-Portnummern betreiben.)

Für Dortmund finde ich da z.B:

			'snng-dtm01.ffdo.de:200{{ "%02d" | format(domain_id) }}',
			'snng-dtm02.ffdo.de:200{{ "%02d" | format(domain_id) }}',
			'snng-ber01.ffdo.de:200{{ "%02d" | format(domain_id) }}',
			'snng-ber02.ffdo.de:200{{ "%02d" | format(domain_id) }}',

hmm, ich denke mal, Du hast Dir mit dem „Gastnetz“ selbst ins Knie geschossen.

Grashuepfer · 6. März 2020 um 17:26

@adorfer
Ich hatte den Teredo-Filter ausgeschaltet, kein Erfolg.
Dann habe ich den Gastzugang von LAN4 deaktiviert,nun scheint es zu passen:
root@FF-DO-GruenerBogen:~# logread -f
Fri Mar 6 18:21:57 2020 daemon.notice hostapd: client0: AP-STA-DISCONNECTED cc:af:78:ba:1f:eb
Fri Mar 6 18:21:59 2020 daemon.info hostapd: client0: STA cc:af:78:ba:1f:eb IEEE 802.11: authenticated
Fri Mar 6 18:21:59 2020 daemon.info hostapd: client0: STA cc:af:78:ba:1f:eb IEEE 802.11: associated (aid 1)
Fri Mar 6 18:21:59 2020 daemon.notice hostapd: client0: AP-STA-CONNECTED cc:af:78:ba:1f:eb
Fri Mar 6 18:22:51 2020 daemon.info hostapd: client0: STA 94:0e:6b:31:0d:0b IEEE 802.11: authenticated
Fri Mar 6 18:22:51 2020 daemon.info hostapd: client0: STA 94:0e:6b:31:0d:0b IEEE 802.11: associated (aid 2)
Fri Mar 6 18:22:51 2020 daemon.notice hostapd: client0: AP-STA-CONNECTED 94:0e:6b:31:0d:0b
^Croot@FF-DO-GruenerBogen:~#

Ich werde jetzt mal wieder den Teredo-Filter einschalten und schauen, ob alles stabil bleibt und auch noch nach der Zwangstrennung klappt.

Erst einmal vielen Dank an Euch für die Unterstützung!!!

Grashuepfer · 6. März 2020 um 17:33

Ich habe den Teredo-Filter wieder eingeschaltet, sofort war die Verbindung wieder weg.
Fazit für FritzBox 7490:
kein Gastnetz einschalten
kein Teredo-Filter aktivieren

silson · 11. März 2020 um 06:59

Moin…

soweit ich das sehe verwenden wir in Dortmund die UDP Ports 20001-20011 (je nach Domäne). Die Tatsächlichen Daten laufen dann aber über einen anderen UDP ab 20012 oder so. Aktuell gibt es Verbindungen zwischen 20205-20821.

Entsprechend wäre es wohl einfacher IPs mehr oder weniger komplett frei zu geben statt einzelne Ports für alle IPs.

Das die Firmware und auch die Infrastruktur nicht besonders aktuell sind ist uns schmerzlich bewusst. Wir arbeiten dran so gut es geht… Von daher ist das Admin Team in Dortmund über jede Unterstützung dankbar. Bei Interesse am besten auf der obigen Mailingliste melden.

Gruß,
SilSon/Stefan

adorfer · 11. März 2020 um 09:47

Der Fehler ist seitens der Knotenauffstellende, überhaupt irgendwelche abgehenden UDP-Filter zu aktivieren.
Keine Community kann garantieren, dass sie ihre Infrastruktur nicht umbauen muss oder es sich schlicht durch Wechsel (von aus auch immer) so ergibt.
Und wenn einmal irgendwo (womöglich andere Communties) Setup-Anleitungen herumfliegen, dann schiessen sich Leute entweder sofort in den Fuß oder stolpern erst Jahre später über die Fußangel.
(Und sage jetzt bitte niemand „Ja selbst schuld, wenn man bei Freifunk nur halbherzig mitmacht und die Mailinglisten nicht aufmerksam liest“: Wie schlecht das selbst bei „aktiven Leuten“ funktioniert sieht man jedes Jahr bei der Organisation der Freifunk-Assembley auf dem Congress, so trotz x facher Info auf so so ziemlich allen Kanälen trotzdem Leute feststellen, ‚sie hätten nichts mitbekommen‘, obwohl sie zuvor durchaus nicht unterm Stein gelebt haben.)