Gerne, kein Problem. Willst Du sie abholen, oder soll ich sie morgen Abend rüber bringen? Komme erst gegen 19:00h nach Hause, hat sich nix geändert :-)
Abholen ginge auch tagsüber.
So, ich habe das mit dem Debugging jetzt über die Konsole bei mir laufen gehabt und ein paar mal einen Neustart gesehen. Da ist aber im Logging nichts zu erkennen kein Kernel Panic o.ä. - er bootet einfach neu, als ob jemand auf Reset gedrückt hätte. Was auffällt ist die sehr hohe CPU-Auslastung vor dem Neustart. Der Router reagiert kaum noch,auch nicht auf Eingaben über die serielle Schnittstelle. Für mich sieht das so aus, als ob der Watchdog zuschlägt und den Neustart veranlasst.
Mit top ist auch kein Prozess identifizierbar, der die hohe Auslastung verursacht, sondern die “sys”-Last seigt auf >90% (kann man aber kaum noch erkennen, da auch top nur noch sporadisch ein paar Zeilen aktualisiert), Besonders hoch ist sie unmittelbar nach dem Booten (ohne für mich erkennbaren Grund). Falls der Router das überlebt (manchmal bootet er mehrmals gleich hintereinander…) sinkt die Last nach ein paar Minuten. Irgendwann steigt sie wieder (scheint dann davon abzuhängen was er gerade für Aufgaben hat, z.B. viel meshen oder viele Traffic durch Clients oder anderes). Je mehr der Knoten zu tun hat um so früher ist wieder ein Zusatnd erreicht in dem die CPU überlastet wird und der Knoten nicht mehr reagiert ==>> Watchdog schlägt zu, Das ist alles, was ich mit meinen Kenntnissen feststellen kann.
Die 2 Wochen Dauer-Troubleshooting in der Unterkunft in Reilingen werden mir jetzt auch zu viel und ehrlich gesagt fühle ich mich ziemlich im Stich gelassen. Ich weiß dass andere auch am Limit sind, mir ist aber unklar, warum unbedingt ein funktionierendes Setup mit Updates auf instabile Firmwarestände zerstört werden muss. Ich habe mich frühzeitig gemeldet und es wäre sicher möglich gewesen die notwendigen Änderungen bzgl MTU auch in OpenWRT vorzunehemn, statt gleich auf LEDE zu gehen. Nun ich stecke nicht in der Firmwareentwicklung und weiß nicht was genau möglich wäre, sicher ist aber, dass es so unheimlich frustrierend ist und ich wenig Lust verspüre mir das in der Freizeit weiter anzutun. In den letzten 2 Wochen habe ich quasi meine gesamte freie Zeit mit Freifunk verbracht, das war nie so geplant und ich mache das nur aus einer gewissen Verpflichtung die ich gegenüber “meinerr” Installation verspüre. Aber als ein Projekt was Dauerbetreuung erfordert, funktioniert das nicht und vor diesem Hintergrund werde ich Freifunk auch nicht mehr “bewerben” (z.B. für Installationen der Gemeinde).
Momentan sehe ich nur die Lösung wieder die Factory-Images auf die Router zu flashen und den Offloader den Rest machen zu lassen. Es wäre hilfreich, wenn mir jemand, der das schon gemacht hat, sagen könnte was ich am Offloader und am Router einstellen muss (uci-Kommandos am Offloader? Am Router nur SSID setzen,? DHCP für die WAN? Kein DHCP für Funknetz? Sonst noch etwas?).
1 „Gefällt mir“
Hallo @trupf
so wie du das beschreibst, klingt das tatsächlich nach dem Watchdog der da aktiv wird.
Du hast beschrieben das die Probleme an verschiedenen Anschlüssen unterschiedlich auftreten. Bitte beschreibe uns doch mal im Detail wie die verschiedenen Setups aufgebaut sind. Das ist für unsere Einschätzung absolut wichtig. Bitte auch die Logs von der Konsole hier hochladen und dann hier den Link dazu posten. Vielleicht sehen wir ja doch noch was.
Ich verstehe deinen Frust, aber da muss ich dir klar widersprechen. Insgesamt läuft die neue Firmware deutlich besser als die Alte. Die Firmware ist auch nicht generell instabil. Wir haben wirklich lange getestet, vor allem im Experimental Branch, und uns Berichte anderer Communities im Gluon Projekt angesehen. Daher war für uns die Entscheidung das Update auszurollen richtig und gerechtfertigt. Dazu kommt auch, dass die neue Firmware grundsätzlich weniger Ressourcen benötigt als die vorherige Version und daher stabiler sein dürfte. Somit haben wir nicht auf einen instabilen Firmware stand aktualisiert.
Das bei dir und einigen wenigen Anderen nun Probleme auftreten, ist trotzdem normal und passiert leider. Ich möchte daran erinnern, dass Freifunk auch eigentlich ein experimental Netz ist, um an und mit der Technik zu experimentieren. Weniger ein Netz das der reinen und optimalen Internetversorgung dienen soll. Da haben wir dann meist andere Setups z.B. mit den Unifi APs im Einsatz.
Hier muss ich kurz intervenieren. Wir sind nicht einfach so auf LEDE gegangen. Der Schritt war aus vielen Gründen notwendig. Hier hätten wir vielleicht für etwas mehr Transparenz sorgen müssen. Das gleichzeitige MTU Update hat nur ein Problem gelöst, dass schon lange bestand hatte. Dadurch ist das Netz an vielen Stellen merklich schneller geworden.
Ich möchte das hier wirklich nicht neu Anfachen, aber genau das ist unser Problem das wir versucht haben im Klartext Thema anzusprechen, nur das es bei uns seit Jahren so ist.
Das verstehe ich. Für Unterkünfte versuchen wir allerdings auch schon länger nicht mehr die normalen kleinen APs mit unserer Firmware zu nutzen, sondern die teureren, dafür aber zuverlässiger laufenden Unifi APs. Vielleicht wäre das auch hier eine Möglichkeit.
1 „Gefällt mir“
hier die Links zu den hochgeladenen Logs:
https://paste.ffrn.de/?47d3c5d1e96cf508#dDNi/eZrDRET572BKvxzlYfpFteEa5fuQK4KOoEX2r8=
https://paste.ffrn.de/?4f779d0fb5082e6d#VUyoYp0czOCHTRfMbJI/2a+DFc7hAUGekCXQJfwQe/g=
https://paste.ffrn.de/?48039ab2c9dac8e1#gMSBomSpQ+4BS11gghFkLvJDF34J9AEztI9u5naNrg4=
https://paste.ffrn.de/?1dea6846d9c5d491#zA5s/whdBZQdXbCWg1GH3dK78Cj38CnB9SM2t/WshaU=
https://paste.ffrn.de/?9602a7c15fd47671#wHKXqi0Hl/FzPjox7F4k3YNdcSb8ntdu+u7Q795LfOM=
Teilweise habe ich auch noch ein paar Dinge gleichzeitig am Terminal probiert (z.B. Bildschirmgröße von screen anpassen, andere MTU-Einstellungen).
Sorry, aber die helfen nicht wirklich viel. Da sind zu viele Ausgaben von top und so drin. Was wir brauchen ist die reine Ausgabe der seriellen Konsole und zwar nach folgendem Schema:
- Serielle dran.
- Logging starten.
- Einmal Reboot entweder soft per “reboot” Kommando oder noch besser Strom weg.
- Warten bis der Fehler aufgetreten ist.
- Logging beenden.
- Log hier hochladen.
Das unterscheidet sich auch deutlich von meinen Problemen. Während bei @trupf der Router lahmt und dann neu startet, laufen meine 1043 sauber durch. Allerdings hängt sich hin und wieder eben das WLAN ab. Dann hilft ein “wifi” auf der Console oder eben ein Neustart.
Jetzt schau ich mal wann/ob das mit der 1.1.1 passiert. Wenn es wieder auftritt mache ich die notwendigen LOGs. Da der Router ja nicht abstürzt erwarte ich irgendeine Ausgabe, die tatsächlich helfen könnte, Ich kann dann vor beendigung des LOGs ja auch noch dmesg aufrufen, weil da ja noch mal manches drin steht was so nicht über logread ausgegeben wird. Da der Router ja nicht neu startet, sollte der Fehler da evtl auch drin auftauchen.
Und was dieses “allein gelassen” angeht… das kennt jeder, der mit so was mal länger gekämpft hat.
Aber wie damals bei dem mühsam errungenen Workaround und der Entdeckung des Fehlers bei einer Anzahl Einträge in dieser Tabelle… manchmal ist es auch richtig befriedigend, wenn man so was am Ende findet.
Hier ist noch mal ein log ohne top. Ich habe nur einmal nach dem Neutstart noch ein “logread -f” eingegeben, um auch die sonst nicht sichtbaren Logmeldungen mitzuschreiben.
https://paste.ffrn.de/?b412622f05cb952c#tiZRBIKwaOQ9oWQ+b//7EIHLe/OHsyO5Fqba4zNaNWY=
Ich mache noch ein paar weitere.
Klappt mit dem Pasten nicht so ganz, es fehlt der Teil vom Log nach dem Neustart, Da ist ein Sonderzeichen in dem Logfile wo es beim Kopieren und Pasten abgschnitten wird, das habe ich jetzt entfernt. Hier noch mal das komplette Log:
https://paste.ffrn.de/?e6eadca5fed6f6d5#CemzyMJ2Ozx2oZehu7M0rIa4eKhsLP1sqQn4JKprh3o=
Noch mal ein Log:
https://paste.ffrn.de/?c1f63e17c367fdc7#b7tRHW6KpL81KqnLK9uKN7XjqaFPa5/SqbXE9eY7Ync=
Was du mal noch auf einem betroffenen Knoten testen könntest wäre folgendes: Wie verhält er sich wenn er an keinem Uplink hängt? Kommt es dann ähnlich schnell zu diesen Reboots?
Nein, dann kommt es nicht dazu. Den Fall hatte ich jetzt schon öfter. Noch zum Setup:
Es geht um die Knoten Reilingen-ARW01…Reilingen-ARW05 und den Offloader RW-Reilingen-ARW-VPN. Bei den Knoten ist Mesh-on-VPN und Mesh-on-Wireless deaktiviert. Außer dem ARW01 sind alle mit direkter Kabelverbindung zum Offloader verbunden. Der ARW01 hängt per Kabel am ARW03, der als Switch fungiert. Den ARW04 habe ich temporär bei mir zu Hause und dort am Netz hängen. Solange ich Mesh-on-VPN nicht aktiviert hatte (und der Knoten sich folglich auch nicht verbinden konnte) ist er nicht abgestürzt. Ich hatte es auch mal probiert fastd mit einer anderen MTU zu starten, auch dann verbindet er sich nicht und stürzt nicht ab (falls er doch abstürzt dauert es jedenfalls sehr viel länger…). Die Häufigkeit der Neustarts ist bei den einzelnen Knoten auch unterschiedlich, der ARW01 startet vielleicht 1x am Tag, der ARW04 in der Unterkunft min. 2-3x (bei mir zu Hause noch öfter, obwohl praktisch kein Nutzertraffic, dafür aber fastd aktiv).
Ich habe es jetzt auch noch mehrmals gesehen, dass kein Wifi am Knoten aktiv war und der Befehl „wifi“ auch nicht geholfen hat. Da hilft dann nur kompletter Neustart (Fehler bei Initialisierung von ath, schon beim Laden des Moduls), Ich gehe momentan davon aus, dass das eine Folge der Reboots ist.
Soll ich die Knoten noch mal mit der neuen Firmware Experimantal 1.1.1 testen?
Hier ist noch mal ein Log von heute:
https://paste.ffrn.de/?da53f79f2efa973d#ZsUDTtS99Jx9vSo8DW0xs2Kl0ti69ar769B4Zh+8pBg=
Ich habe auch die neue experimental Firmware getestet - im Test-Setup mit laufendem fastd zeigt er bei mir das gleiche Bild. Was mich sehr stark verwundert ist, das der Knoten auch ohne irgendeine Nutzlast nach kurzer Zeit bei über 90% syslast der CPU steht und sehr träge reagiert. Sobald ich den Router vom Uplink trenne oder fastd stoppe geht die syslast in den 1-stelligen Bereich und der Router reagiert wieder normal. Stecke ich das Kabel wieder rein und fastd läuft, geht die Last wieder hoch. Was macht der Router da? Ist das nur das “Meshen” durch den Tunnel, das schon so viel Last erzeugt? Aber dann müßte es ja bei anderen Geräten auch so sein.
Ich habe das Update auch in der Unterkunft eingespielt, dort meshen die Router nur local zum Offloader. Ich kann dort das Meshen nicht abschalten, da ich dann ja die Verbindung verliere, aber auch dort steigt die sys-Last langsam an und der Router scheint sich immer mehr mit sich selbst zu beschäftigen, bis zum Reboot.
Spannend bei mir: Nur die Knoten werfen ihr WIFI weg, die per Kabel meshen oder die tatsächlich selber mit dem Gateway verbunden sind,
Wobei die 1.1.1 bisher noch keinen solchen Fehler zeigt. Aber das hat immer mal wieder ein paar Tage funktioniert, auch mit 1.1.0… also ich warte ab.
So, da es mit der neuen FW auch nicht besser lief habe ich wieder die stock aufgespielt. Ich bin selbst nicht von der Lösung begeistert, da man nichts mehr sieht und auch das Bridgen des Netzwerkes geht nicht, Daher würde ich lieber wieder Gluon aufspielen, wenn es eine Version gibt, mit der auch der TL-WR1043v1 wieder stabil läuft. Ich probiere es gern noch mal, sofern mir jemand dazu die Info gibt.
@ rgr: Deine 842er benötige ich dann jetzt nicht mehr. Sag Bescheid wann ich sie vorbei bringen kann.
@lea: Die Knoten Reilingen-ARW01…Reilingen-ARW05 sind damit offline und können gelöscht werden (oder Du läßt sie drin für einen späteren neuen Versuch. Beim erneuten Flashen wird aber wahrscheinlich ohnehin ein neuer Token und VPN-Schlüssel erzeugt)
Hier ein Gedanke aus der Ferne: Habt ihr in der FFRN-Firmware noch das Package mit den lowmem patches drin?
Wenn ja, deaktiviert (patcht) es direkt auf betroffenen Nodes und rebootet dann für eine Gegenprobe. Wir hatten in Stuttgart nämlich damit ähnliche Probleme seinerzeit während der Tests (siehe alter Thread “ffrn-lowmem-patches”).
2 „Gefällt mir“
Danke für die Erinnerung. Wir bauen gerade eine neue Experimental ohne diese Patches.
1 „Gefällt mir“
Wo ich gerade lese, dass es v1 sind fällt mir ein dass ich gestern https://forum.freifunk.net/t/tipp-stabilitaetsprobleme-beim-tp-link-tl-wr1043nd/12885 gelesen habe. Wäre vielleicht auch ein Versuch wert. Netzteile sind mir schon einige gestorben.
Die 842 kannst einfach irgendwann vorbei bringen und vor die Haustür legen.
Das mit dem Netzteil erklärt die permanent hohe sys-Last nicht, der lowmem-patch scheint mir da wesentlich plausibler. Ich habe jetzt nicht mehr gluon auf den Routern und kann es nicht einfach ausprobieren diesen Teil zu deaktvieren - da müßte ich dann alle Router zurückflashen, denn Mischbetrieb geht auch nicht. Vielleicht kann das ja jemand anderes mit dem gleichen Problem testen?