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

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

1 Like

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.

1 Like

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

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.

@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…

Klingt verdächtig nach diesem Gluon-Issue:

1 Like

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:

  1. Deine Community stellt eine neue, sichere verbesserte Firmware bereit.

  2. 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.

  3. 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:
https://ctaas.de/OpenWrt_Freifunk_Router_GL-iNet.htm#Freifunk_Router_am_FritzBox_Gastzugang

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.

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

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.

@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!!!

1 Like

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

2 Likes

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

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.)