FF3L: Router bekommen reihenweise kein VPN mehr

[Michael Sommer]

Hallo David, 

Ist super! Ich hab natürlich mit logread ins log geschaut, vor und nach dem Neustart. Nur konnte ich mit dem Output noch nichts anfangen, aber ich schau mir das noch mal an.

Grüße
Michael

> Am 15.09.2025 um 17:22 schrieb David Lutz <kpanic at hirnduenger.de>:
> 
> Nur so ein Tipp:
> Wenn man vor dem Neustart mal ins Log schaut (logread), kann man eventuell auch sehen wo es denn hängt. In meinem Fall habe ich gesehen, dass der fastd zwar mit GW4 verbunden war, aber der batman keine Verbindung hatte (TQ = 0) Damit war mir dann sofort klar, dass GW4 der Übeltäter war.
> 
> Wie man das überwachen könnte weiß ich auch nicht. Aber ein Tipp in die richtige Richtung (s.o.) hätte schon früher bei der Problemlösung helfen können.
> 
> Gruß
> David
> 
> 
> On 15.09.25 17:20, Michael Sommer wrote:
>> Hallo Martin,
>> ich beobachte das auch! Ich meine ein Neustart von fastd (/etc/init.d/ fastd restart) behebt das Problem ohne Neustart (ist natürlich keine Lösung, nur zur Info).
>> Grüße
>> Michael
>>> Am 14.09.2025 um 17:34 schrieb ML Privat via ff3l <ff3l at ff3l.net>:
>>> 
>>> Hallo zusammen,
>>> 
>>> zu dem Problem noch einige Ergänzungen:
>>> - es sind geschätzt etwa >10% der ff3l Knoten in meinem Umfeld Schwarzwald-Baar betroffen
>>> - die Router sind auf der Karte offline oder inzwischen "weg".
>>> - das Problem besteht in etwa seit kurz vor den Sommerferien
>>> - es ist völlig gleichgültig, welcher Carrier dahinter hängt - alles ist quer-beet betroffen
>>> - bei Routern mit MESH Nachbarn kann der Fehler nicht erkannt werden, besteht aber vermutlich trotzdem!
>>> - ich war heute wiederholt bei einigen Stationen vor Ort und habe festgestellt:
>>>    - die Router sind online, haben InterNet, senden "Freifunk" als WLAN aus
>>>    - Freifunk kann per WLAN an Mobilgeräten NICHT verbunden werden (keine IP)
>>>    - Freifunk kann am Notebook per WLAN verbunden werden, das Interface sieht dann so aus:
>>> 
>>> falsch im Fehlerzustand:
>>> wlp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
>>> inet6 fe80::26e7:77ee:ac9:941b prefixlen 64 scopeid 0x20<link>
>>> inet6 fdc7:3c9d:ff31:c:181d:571a:3cdd:aa21 prefixlen 64 scopeid 0x0<global>
>>> 
>>> richtig ist es so:
>>> wlp4s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1332
>>> inet 10.119.199.167 netmask 255.255.240.0 broadcast 10.119.207.255
>>> inet6 fe80::26e7:77ee:ac9:941b prefixlen 64 scopeid 0x20<link>
>>> inet6 fdc7:3c9d:ff31:c:181d:571a:3cdd:aa21 prefixlen 64 scopeid 0x0<global>
>>> 
>>> Die User klagen über:
>>> Freifunk keine Verbindung (das sind die, die Freifunk aussenden, aber keinen Connect haben)
>>> Freifunk extrem langsam (das sind vermutlich die Router, die nur noch per MESH Nachbar laufen)
>>> 
>>> Meistens bekommt man die Router wieder per stromlos machen / neu starten wieder "online". (geht nur vor Ort)
>>> Das hält dann aber oft nicht lange - einige Tage, ggf. auch mal 2 Wochen, dann sind sie wieder weg.
>>> 
>>> Ich hatte inzwischen 2 Router, die auch nicht per mehrfachem "Stromlos machen und Neustart" dazu zu bewegen waren,
>>> sich wieder zu verbinden. Bei diesen Routern habe ich die VPN Verbindung auf "schnell" umgestellt (ohne encryption).
>>> Siehe da: Neustart - zack und sie laufen!
>>> 
>>> Mein Fazit:
>>> Es bestehen aktuell enorme Probleme im FF3L VPN bzw. an den Gateways!
>>> Da die Probleme nur vor Ort sichtbar werden, ist es nur schwer per "Karte" erkennbar,
>>> ich kann also aktuell nicht einmal sagen "wo überall Router mit diesem Fehlerstatus laufen".
>>> 
>>> Bitte möglichst bald danach suchen & beheben.
>>> 
>>> -- 
>>> Mit freundlichen Gruessen
>>> Martin Lehmann
>>> I
> 
> 

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 4073 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.ff3l.net/pipermail/ff3l/attachments/20250915/61178d79/attachment.bin>