Die neue Firmware ist jetzt per Auto-Update auch auf den TL-WR1043N in Reilingen gelandet (Reilingen-ARW01…Reilingen-ARW05). Seitdem kann ich ständig stark schwankende TQ (zwischen 0% (!) und 100%) und häufige Neustarts der Geräte beobachten (zu sehen an der Zeile “Online seit xxx Minuten”). Der Offloader zeigt diese Probleme nicht, ebensowenig wie die TL-WR842N an einem anderen Standort. Mit der alten Firmware sind diese Probleme auch nicht aufgetreten. Gibt es eine zu ändernde Config-Einstellung oder was wäre z tun?
Noch eine Ergänzung: Die schlecht laufenden router hängen am Telekom-Netz, die gut laufenden an Unitymedia - vielleicht braucht man bei der Telekom eine andere MTU?
Wenn ich auf der Knotenkarte verschiedene Knoten anklicke scheint das Problem mit den häufigen Neustarts deutlich mehr als nur meine Knoten zu betreffen - viele sind erst sein ein paar Minuten oder Stunden online…
ich poste mal noch die Ausgabe von demsg (alles was nach dem Start von eth0 noch kommt) - oder gibt es noch andere hilfreiche Logs zum Posten?
[ 27.095925] eth0: link up (1000Mbps/Full duplex)
[ 27.117961] device eth0.1 entered promiscuous mode
[ 27.123042] device eth0 entered promiscuous mode
[ 27.142548] br-mesh_lan: port 1(eth0.1) entered forwarding state
[ 27.148656] br-mesh_lan: port 1(eth0.1) entered forwarding state
[ 27.223930] device eth0.2 entered promiscuous mode
[ 27.267804] br-wan: port 1(eth0.2) entered forwarding state
[ 27.273571] br-wan: port 1(eth0.2) entered forwarding state
[ 27.333568] IPv6: ADDRCONF(NETDEV_UP): local-node: link is not ready
[ 27.468774] IPv6: ADDRCONF(NETDEV_UP): br-client: link is not ready
[ 27.534477] IPv6: ADDRCONF(NETDEV_CHANGE): local-node: link becomes ready
[ 27.587195] device local-port entered promiscuous mode
[ 27.592857] br-client: port 1(local-port) entered forwarding state
[ 27.599123] br-client: port 1(local-port) entered forwarding state
[ 27.629908] IPv6: ADDRCONF(NETDEV_CHANGE): br-client: link becomes ready
[ 29.139856] br-mesh_lan: port 1(eth0.1) entered forwarding state
[ 29.269801] br-wan: port 1(eth0.2) entered forwarding state
[ 29.623649] br-client: port 1(local-port) entered forwarding state
[ 34.383368] ath: EEPROM regdomain: 0x8114
[ 34.383396] ath: EEPROM indicates we should expect a country code
[ 34.383413] ath: doing EEPROM country->regdmn map search
[ 34.383429] ath: country maps to regdmn code: 0x37
[ 34.383445] ath: Country alpha2 being used: DE
[ 34.383459] ath: Regpair used: 0x37
[ 34.383477] ath: regdomain 0x8114 dynamically updated by user
[ 35.142074] batman_adv: bat0: Adding interface: primary0
[ 35.147469] batman_adv: bat0: Interface activated: primary0
[ 35.157365] 8021q: adding VLAN 0 to HW filter on device bat0
[ 35.196353] device bat0 entered promiscuous mode
[ 35.201187] br-client: port 2(bat0) entered forwarding state
[ 35.206932] br-client: port 2(bat0) entered forwarding state
[ 35.553358] batman_adv: bat0: Interface deactivated: primary0
[ 35.830639] IPv6: ADDRCONF(NETDEV_UP): primary0: link is not ready
[ 35.838838] batman_adv: bat0: Interface activated: primary0
[ 36.334919] batman_adv: bat0: Adding interface: br-mesh_lan
[ 36.340645] batman_adv: bat0: The MTU of interface br-mesh_lan is too small (1500) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem.
[ 36.365288] batman_adv: bat0: Interface activated: br-mesh_lan
[ 36.652674] batman_adv: bat0: Adding interface: br-wan
[ 36.657984] batman_adv: bat0: The MTU of interface br-wan is too small (1500) to handle the transport of batman-adv packets. Packets going over this interface will be fragmented on layer2 which could impact the performance. Setting the MTU to 1532 would solve the problem.
[ 36.682256] batman_adv: bat0: Interface activated: br-wan
[ 37.199825] br-client: port 2(bat0) entered forwarding state
[ 37.757787] batman_adv: bat0: Changing gw mode from: off to: client
[ 37.798451] batman_adv: bat0: hop_penalty: Changing from: 30 to: 15
[ 38.046485] batman_adv: bat0: orig_interval: Changing from: 1000 to: 5000
[ 39.211711] IPv6: ADDRCONF(NETDEV_UP): client0: link is not ready
[ 39.427374] device client0 entered promiscuous mode
[ 39.575046] IPv6: ADDRCONF(NETDEV_CHANGE): client0: link becomes ready
[ 39.581903] br-client: port 3(client0) entered forwarding state
[ 39.587943] br-client: port 3(client0) entered forwarding state
[ 41.339958] random: nonblocking pool is initialized
[ 41.579839] br-client: port 3(client0) entered forwarding state
Es gibt wirklich offenbar global in FFRN Probleme mit der neuen Firmware in Bezug auf die Neustarts. Soweit ich sehen haben 90% der Knoten mit TL-WR841 oder TL-WR1043v1 (d.h. die mit nur 32MB RAM…) eine Laufzeit von unter 10h bis zum Neustart. In meinem Fall oft sogar <1h. Die Probleme treten dann verstärkt auf wenn “viel los ist” (viele Clients, Meshen mit mehreren anderen Knoten, hoher Traffic…). Ich werde mich wirklich bemühen Debuglogs zu erzeugen, bin aber nicht sicher ob ich das hinbekomme und das dauert auch noch eine Weile. Es wäre aber hilfreich, wenn ihr so lange vielleicht zum letzten stabilen Release mit OpenWRT zurückgehen könntet (zumindest für diese beiden Geräte, evtl noch die MTU-Änderung übernehmen). Freifunk ist in der Unterkunft in Reilingen quasi nicht benutzbar, noch dazu hängen sich die Knoten manchmal auch komplett auf, dann hilft nur manueller Neustart. Wahrscheinlich ist das Problem doch auch upstream vorhanden, oder?
Meine Knoten (Experimantal Branch) haben ja auch 1.1.0
Da hängt sich seit langem regelmäßig das WLAN auf … die Knoten selber stürzen nicht wirklich ab. neustarts habe ich aber nicht so oft. Nur der 841 startet öfters mal neu (zwischen 0,5 und 2 Tagen) …
Ich hab hier vier so USB-RS232 Adapter von denen ich drei Stück auch gerne mal verleihen kann…
Danke, USB-Adapter habe ich auch. Mein Problem ist eher wie das ganze vor Ort installiert werden kann und wie es automatisch wieder startet nach einem Neustart. Und ich muss erst mal den RasPi dafür neu aufsetzen. Aber die Indizien die ich habe deuten in Richtung zu wenig RAM. D.h. man müßte versuchen nicht zwingende Prozsse zu stoppen oder besser Geräte mit mehr RAM (d.h. mehr als 32MB) einzusetzen. Ob dein Problem die gleiche Ursache hat kann ich aber nicht beurteilen.
also die 841 haben echt wenig RAM … das kann da schon eine Rolle Spielen. Die starten dann immer mal wieder neu. Der in meiner Straße ist über 2 Ecken per mesh dran und startet so einmal alle 2 Tage neu oder auch 2 mal am Tag.
Die 1043 laufen besser. Die starten normal nicht von alleine neu, aber das WLAN hängt sich einfach auf. Dann geht kein Mesh und man kann sich nicht einwählen. Ein einfaches “wifi” auf der Konsole und es geht wieder. Oder eben mal kurz den Stecker raus, was dann die Leute machen, die keine Ahnung haben wer dieser Hr. Putty ist ;) Das passiert auch manchmal mehrmals am Tag und dann wieder läuft es ein paar Tage Problemlos.
Manchmal kommt das WLAN auch von alleine wieder an den Start. Eine Zeit lang hatte ich ein Skript laufen, was alle 5 Minuten “wifi” ausgeführt hat. DA lief es dann aus Sicht der User ohne Probleme. Seit dem in der FW ein Workarround drin ist, beißt sich das mit dem “wifi”-Script … aber der Workaround ist - obwohl technisch sicher sauberer als meine Lösung - unzuverlässig. Es dauert oft Stunden oder auch mal einen Tag, bis so ein Knoten das WLAN wieder von selber an den Start bringt.
Ich habe den 1043v1, der hat auch nur 32MB RAM, wir der 841 (nur mehr Flash). Mit WLAN, dass sich aufhängt hatte ich mit der alten Firmware keine Probleme. Generell hatte ich auch keine Probleme mit Neustarts mit der alten Firmware. Jetzt starten die Knoten tagsüber und insbesondere am Abend zeitweise in <1h neu.
Der TL-WR1043 hat ja eine USB-Schnittstelle. ich habe da jetzt einen Stick rangesteckt und logge auf dem Stick. Allerdings finde ich da nicht auffallendes in den Logs, außer dass er halt neu startet. Wie kann ich das Log hochladen ins Forum? Muss man das in ein .pdf umwandeln damit es geht? Ist bei einem Log über Konsole mehr zu sehen, evtl. noch die Absturzmeldung oder ist das nicht zu erwarten?
Weiterhin habe ich auf dem Stick eine Swap-Partition eingerichtet und eingebunden. Damit läuft es etwas besser (Neustarts bei den beiden Geräten nicht mehr alle 30 min. sondern alle 4-8h), aber wirklich gelöst ist das Problem damit nicht. Wenn sie nur neu booten würde würde es ja noch gehen, aber jedes 2.-3. Mal hängt sich der Router komplett auf und es hilft nur noch Stecker ziehen…
Ich habe auch noch 3x die Ausgabe von Top kopiert. top.pdf (29,8 KB)
Auffallend ist die hohe sys-Load der CPU. Ich habe festgetellt, dass die CPU-Last langsam ansteigt, der Knoten immer langsamer wird (Login per ssh dann kaum mehr möglich) und kurz danach neu startet.
Gibt es eine Möglichkeit die alte Firmware wieder aufzuspielen? (ich meine es war Gluon 0.6.9-20170621). Oder besser gefragt, kann ich die noch irgendwo runterladen um sie wieder aufzuspielen?
Da muss ich dich leider enttäuschen. Die alte 0.x.x Firmware wir auf absehbare Zeit inkompatibel mit dem Backbone werden. Damit wäre dein Knoten dann abgehängt und könnte sich nicht mehr verbinden. Helfen wird da nur das Debuggen über die Serielle.
Ja, leider sieht man da dann meistens erst wirklich das Problem.
Ich hab mir das gerade mal angeguckt. Es sind eher so 10% dieser Knoten die so stark betroffen sein könnten. Und nochmal 5% bei denen das weniger oft passiert, aber ja es sit ein Problem. Müssen wir beobachten, vielleicht gibt es ja auch schon ein Issue auf Github bei Gluon: Issues · freifunk-gluon/gluon · GitHub
Aufspielen der alten Firmware wäre auch nicht als Dauerlösung gedacht, sondern nur um die Zeit zu überbrücken bis wir eine bessere Lösung haben. Das Debuggen über die Konsole nehme ich dann in Angriff, siehe auch den
Was genau wird benötigt? Die Ausgabe von logread + Ausgabe auf der Konsole? Also z.B. logread -f starten und die ganze Terminalsession mitloggen?
Bei einem Absturz wird oft nur direkt auf der lokalen Konsole etwas ausgegeben, logging auf Massenspeicher oder sogar über Netzwerk ist da oft nicht hilfreich. Diese Logs reißen dann einfach ab bevor es wirklich interessant wird.
Ja, das habe ich verstanden, trotzdem bleibt meine Frage oben. Oder anders gefragt, was genau muss ich machen um auch die sonst verlorenen Log-Meldungen mitzuschreiben? Ein offenes Terminal-Window nützt nicht viel, dann werden die Meldungen nur angezeigt und nicht in eine Datei geschrieben, und wenn ich wieder hinkomme ist nichts mehr zu sehen. In Linux ist es oft so, dass ein kernel-Panic gar nicht in der Log-Datei landet, sondern nur auf der Konsole. Brauche ich dann die Ausgabe von logread überhaupt - oder nur den Output der Konsole? Wie wäre der Befehl in einem RasPi, das alles mitzuschreiben… etwas in der Art „screen /dev/ttyUSB0 115200“ und dann auf dem Terminal noch ein „Ctrl-a H“ (der mit screenrc?) und „logread -f“?
Also @trupf und ich wollen uns das mal vornehmen … sind wir nur zur Zweit oder hat noch jemand Lust? Also das Ergebnis könnte ein Image sein, was auf einem Raspi läuft und alles mitschreiben kann. Und natürlich dann auch die Logfiles der Kisten, die rumzicken. Und ein kleiner Artikel hier und/oder ein Eintrag im Wiki, damit es auch andere machen können. Jemand mit Linux-Erfahrung auf dem Raspi wäre nett …