Erneut "Mehrminütiger Ausfall im 60 Minuten Takt"

Hallo Zusammen,

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.

  • Hält sie weiterhin an?
    Ja

Was?

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

Gateway?

  • Mit welchem unserer Server das Gerät verbunden, als die Störung auftrat.
    194.113.55.74

DSL-Router?

  • Welches Modell wird als DSL-Router verwendet? Hersteller und Modellname.
    AVM FRITZ!Box 4040 in beiden Standorten

Standort-1

https://map03.4830.org/map02/#!v:m;n:2c3afd2ea285

Standort-2
https://map03.4830.org/map02/#!n:0c7274313e0b

Aufruf der damaligen Kollegen

Ich erwähne euch hier kurz, damit es bei euch aufpoppt. Vielleicht ist es bei euch ja auch wieder so.

@m.bitterlich
@wusel
@MichaelKliewe
@Thomas

Wäre total mega, wenn wir die Probleme wieder zusammen fixen könnten.

Guten Morgen,

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.

Hallo Zusammen,

gibt’s hier neue Erkenntnisse?

Mittlerweile lädt auch die gesamte MAP im Kreis GT nicht mehr.


image

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 zusammen,

Ich schätze du meinst ein FW-Update für die Freifunk-Knoten.
Gibts da ne ungefähre Richtung, wann das verfügbar sein soll?

Das sieht erstmal gut aus. Die Karte läuft bei mir wieder.

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.

Dieses Thema wurde automatisch 10 Tage nach der letzten Antwort geschlossen. Es sind keine neuen Antworten mehr erlaubt.

Moin zusammen,

was ist denn jetzt hiermit?
Gibt’s nen Fahrplan?

Freifunk ist aktuell unbenutzbar.

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:

Dabei fielen Probleme bei 5 Gateways auf, die weiter analysiert werden müssen.

Hallo Kai,

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.

In dem anderen Standort ist es durchschnittlich 30 von 60 Minuten tot.

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.

Moin zusammen,

hat sich noch irgendwas ergeben?
Hier ist das Verhalten weiterhin unverändert.

Hat irgendwer noch Ansätze?

Eine Codeprüfung hat Ende 2024 ergeben, daß der in aktuellen Firmwares verwendete Code nicht zu Problemen führen sollte, falls firmware.ipv6.4830.org nicht erreichbar sein sollte. Insofern diesbezüglich alles auf Anfang.

Wenn alles glattläuft, ist der Server, der u. a. firmware.4830.org beherrbergt, Anfang der Woche an seinem geplanten Platz in einem Rack in Hamburg — auch damit nähern wir und den ›Zielnetz‹.

Wenn wir da sind (und damit den HW-Refresh 2024 endlich abgeschlossen haben), gucken wir uns die verbleibenden ›dornigen Chancen‹ an und suchen, frei nach CL, nach einem Grund, das Mesh zu verlassen — oder so.

Wobei ich konnte auf meinen Knoten umgehen, in dem ich

cat /usr/lib/micron.d/autoupdater-wifi-fallback

15 3 2 2 * /usr/sbin/autoupdater-wifi-fallback

Den Wifi Fallback auf einmal im Jahr gesetzt habe. (Nach dem ändern muss der Knoten oder micron neu gestartet werden) Man könnte ihn auch komplett löschen. Er sollte bei einem Firmwareupdate ja wieder erstellt werden.

Hey das klingt doch nach einer brauchbaren Lösung.

Für mich wäre es durchaus ausreichend, wenn der Cronjob einmal in der Nacht ausgeführt werden würden. Da kann die Kiste dann von mir aus auch die Verbindung verlieren.

Ich habe gerade nur eine Herausforderung.
Die Freifunk-Fritzboxen wurden hier im Haus von jemand anderen eingerichtet, auf denen ich gerade keinen Zugriff habe.

Somit fehlen mir gerade die Login-Daten zur Konsole.
Ich könnte mir aber vorstellen, dass einfach die Standard-Passwörter verwendet wurden, da keine geänderten PW-Daten dokumentiert wurden.

Gibt es Standard-Zugangsdaten im Image oder gibt es da eine Routine, dass beim ersten Login dringend das Kennwort geändert werden muss?

Ich möchte jetzt ungern die Kisten neu aufsetzen müssen.

Status: Server wurde gestern Abend übergeben und soll heute Nachmittag eingebaut werden.

Außer wir ›müssen‹ ein Breaking Update fahren. Was nicht passieren sollte.

Nope.

Edit: im Config-Mode ist passwordloser ssh-Zugang aus dem LAN möglich.

Ok da ich nicht darum komme mich mehr mit der Einrichtung des FF-Knotens zu beschäftigen habe ich ein paar Fragen an euch.
Ich bin mir sicher, dass diese hier im Forum irgendwo schon beantwortet wurden, doch befürchte ich, dass ich danach ewig suchen würde.

  1. Kann ich die Konsole (SSH) nur nutzen, wenn ich im Config-Modus bin oder könnte ich mich an dieser auch dann anmelden, wenn bei der Einrichtung ein SSH-Kennwort vergeben worden wäre?

  2. Falls man jederzeit per SSH auf die Konsole kommt, können auch dann dauerhafte Änderungen vorgenommen werden oder nur, wenn zusätzlich der Config-Mode an ist?