wie es aussieht, besteht das Problem der konstanten Neustarts der Router von Mai wieder in diesem Bereich »Freifunk Kreis GT«. Ich hoffe, dass Ihr da mit geschultem Auge schnell den Fehler findet.
Siehe Eintrag:
Wo?
Vermutlich wieder der Gesamte Netz »Freifunk Kreis GT«
Wann?
Wann trat die Störung zuerst auf?
Soweit ich das sehen kann seit dem 30.09.2024 ab 15:00. in beiden unser Standorte die beide im KreisGT liegen.
Alle im 60 Minuten-Takt bricht die Verbindung des Freifunk-Routers zum Netzwerk ab.
Nach 10-50 Minuten verbindet sich der Freifunk-Router wieder und funktioniert bis zum Stichzeitpunkt, an dem der erneut nach Updates prüft und dann wieder abstürzt.
Das bedeutet, dass das Freifunk-WLAN die meiste Zeit über nicht verwendet werden kann.
Viel genauer und detaillierter ist es am ende des Forenbeitrages beschrieben.
Die Behebung der Probleme war aber auf jeden Fall, dass die Update-Server, in dem Fall damals unter anderem »firmware.ipv6.4830.org« nicht erreichbar waren.
ich kann es bestätigen. Bin gerade am schauen ob es evtl. zusätzlich noch ein DHCP Problem gibt.
Der Ausfall bzgl. des Update suchens ist Netzwerkweit. Ich konnte es in WD und Rietberg bestätigen. Bzgl. DHCP Versuche ich es gerade noch einzugrenzen.
Die Ausfälle stammen von unsinigem Schwenk in den Fallbackmodus aufgrund der Unerreichbarkeit des Updateservers per IPv6. Das wird in einem FW-Update demnächst behoben.
Das ist Teil der Ursache des erstgenannten Problems, die Anbindung dieses physischen Servers ist z. Zt. wackelig. Ist erstmal so, kann b. a. w. nur dran rumgepatcht werden, bis er physisch umgezogen werden kann.
Moin.
Liegt das an der auf den Knoten installierten Firmware?
Die Client-Ereignisse treten bei 1.4.x und 1.6.x fast zeitgleich auf.
Mit 1.4 und aktivem Autoupdater sind längere WLAN-Sitzungen (Meeting, Remote,…) fast nicht möglich. Bei 1.6 ist mir eine Unterbrechnung nicht so häufig aufgefallen.
Für Mesh 1 (Stadtgebiet Gütersloh) kann ich das nicht bestätigen; testweise 15 Minuten den tagesschau24-Stream von tagesschau.de laufen lassen, tut.
Diese Theorie hat den Blick in den Code nicht überstanden; in der verwendeten Version des WiFi-Fallback-Updaters wird zwar der Firmwareserver angepingt, aber nur ein positives Ergebnis hat eine Auswirkung (nämlich, daß der Knoten als online gesehen wird). Auch der SSID-Changer nutzt den Updateserver nicht als Entscheidungskriterium.
@Cord wies am Donnerstag auf DHCP-Probleme hin (Mesh 1); die kann ich zwar auch nicht nachvollziehen, aber die 300/900-Sekunden-Werte sind zu gering, es wurden entsprechende Änderungen vorgenommen und auf die Gateways gepusht:
Ja das sieht für mich auch so aus, als wenn Mesh01, bzw. der eine Knoten den ich geprüft habe, diese Probleme nicht hat.
Ich habe mir Mal Beispielhaft den Knoten »33330-Stadt-Guetersloh-Rathaus« angesehen. Ja da kann ich die Probleme nicht so wie bei uns nachvollziehen. Wobei es auch dort Auffälligkeiten gibt. Das scheint aber einen anderen Hintergrund zu haben.
In dem Standort wird aber auch keine Fritzbox 4040 eingesetzt.
Ich habe leide auch keinen anderen Knoten im Mesh01 gefunden der Vergleichbar mit unseren Standorten ist und dabei eine Fritzbox 4040 einsetzt.
Für uns ist Freifunk aber weiterhin im Mesh-02 nicht nutzbar.
In einem Standort ist es durchschnittlich 50 Minuten von 60 Minuten offline.
Waagerechte Linien bedeuten, da kam keine Antwort vom DHCP.
Nein, ein Multicore-Desktop-PC mit x GB RAM und SSD aus dem Lager als Ersatz für eine 1043v2 seinerzeit. Mit modifiziertem Gluon2Futro x86-Image draufgebraten, done. Sprich: massiv mehr PS im Vergleich zu einer 4040, aber ansonsten ein 08/15-Image.
Der Knoten bringt nur WLAN per Batman und Tunnel zum Gateway. Mit L2TP ist das nicht mehr exorbitant CPU-lastig, und mit DHCP haben Knoten nix am Hut. Die »Musik« spielt in den Gateways und damit den VMs auf Servern in Rechenzentren.
