RGW: FF_Offline 841ND v9

Hallo,

mein TPL WR841 v9 in der Domäne Ruhrgebiet-West (Duisburg) stellt immer wieder den Dienst ein und wechselt die SSID von „Freifunk“ zu „FF_Offline…“.
Ein Neustart löst das Problem zwar immer, aber nach einiger Zeit (manchmal nur wenige Minuten, spätestens nach ein, zwei Tagen) ist er aber wieder „FF_Offline“.

Hat RGW ein Problem? Hat mein TP-Link ein Problem?
Jemand eine Idee, wie ich das Problem eingrenzen kann?

Der Uplink (Vodafone DSL) ist immer verfügbar, an Reconnects liegt es nicht.

Danke und viele Grüße
Tom

Dir wird vermutlich nichts anderes übrig bleiben als Dich lokal mit einem Rechner (Laptop, Wlan…) per SSH mit dem Router zu verbinden und den Befehl „logread -f“ auf der Kommandozeile offen zu lassen und zu warten, welche Fehlermeldungen dann irgendwann vorbeigescrollt kommen.

Ich tippe mal auf ein Problem mit der DNS-Resolution im Tunneldigger.
Es gab vor ein paar Jahren mal diesbezügliche Issues, die aber gefixt wurden, zumindest habe ich sie bis inkl. Gluon 2018.x noch gesehen, seit 2019.x, spätestens aber gluon2020 habe ich das nicht mehr beobachten können bei uns.
Was es gewesen ist? Keine Ahnung. aber wenn Ihr noch Gluon 2018 oder älter im Einsatz habt, dann könnte man nochmal forschen. So aus Neugier.

Hab nun etliche Male nach einem Neustart „logread -f“ gestartet.
In den meisten Fällen war keine Ausgabe zu sehen, irgendwann ist dann die ssh-Verbindung abgebrochen und der Router hat sich weggehängt oder (selten) neu gestartet.

Ganz selten gab logread folgendes aus, bevor die Verbindung abbrach:

daemon.warn td-client: Tunnel has timed out, closing down interface.
kern.info kernel: [ 1263.384785] batman_adv: bat0: Interface deactivated: mesh-vpn
daemon.notice netifd: Network device ‚mesh-vpn‘ link is down
daemon.notice netifd: Interface ‚mesh_vpn‘ has link connectivity loss

Was mir nicht klar ist:
Die Tatsache, dass sich der Router weghängt, liegt das am „connectivity loss“, oder hat das Dingen eine Macke und ist Schrott?

Danke und viele Grüße
Tom

Ich vermute, der TD-Client/das Gluon ist alt.

Das bestimmt. Die letzte Firmware für „RGW“, die ich gefunden habe, ist „gluon-ff-rgw-0.10.0“ von 2018.
Ich vermute, eine neuere gibt es (für RGW) gar nicht.

Hab nun mal eine aus Düsseldorf geflasht und damit sieht es viel besser aus. Keine Verbindungsabbrüche bis jetzt.

Besten Dank!

Wohl zu früh gefreut. Zu erst sah es gut aus.
Auch mit der aktuellen Düsseldorfer Firmware hängt sich der Router inzwischen nach einer Weile weg (mal früher, mal später).

Mon Feb 7 19:08:09 2022 user.notice root: IPv6 Anycast-IP reachable.
Mon Feb 7 19:13:55 2022 daemon.warn td-client: [kallisto.ffnef.de:20013] Tunnel has timed out, closing down interface.
Mon Feb 7 19:13:55 2022 daemon.notice netifd: Network device ‚mesh-vpn‘ link is down
Mon Feb 7 19:13:55 2022 daemon.notice netifd: Interface ‚mesh_vpn‘ has link connectivity loss
Mon Feb 7 19:13:55 2022 kern.info kernel: [ 3172.508570] batman_adv: bat0: Interface deactivated: mesh-vpn
Mon Feb 7 19:13:55 2022 kern.info kernel: [ 3172.547789] batman_adv: bat0: Removing interface: mesh-vpn
client_loop: send disconnect: Broken pipe

Kann es dann vielleicht doch sein, das die Hardware defekt ist?

Dass Tunnel mal zusammenbrechen, insbesondere wenn die Internetverbindung nicht so stabil ist, das ist relativ normal.
Frage ist: wird die Verbindung dann innerhalb der nächsten Minuten wieder automatisch aufgebaut oder wie lange braucht der Knoten zum recovern?
10 Minuten, eine Minute oder vielleicht genau 70 Minuten?

Ich glaube, den Knoten auf der Map gefunden zu haben. Wenn der das ist, dann ist es wirklich dramatisch.
Der ist danach stundenlang offline, mindestens 3 mal länger offline als online.

Also wirklich ein Hardware Fehler (am Plasterrouter und dessen Kabeln) oder eine vom Provider im - Homegateway aktivierte Toredo-Firewall.

1 Like