TL-WR841ND mit neuester Freifunk-Firmware - bricht regelmäßig nach ca. 12h zusammen

Hallo:

gerade letzte Woche habe ich einen neuen Knoten in Neuenheim eingerichtet, funktioniert nach Installationsanleitung prima, aber nach ca. 10h muss ich den Router zurücksetzen, weil er nicht mehr antwortet. Auf dem WLAN ist er durchaus noch sichtbar, aber er macht keine Verbindung, auch nicht per Draht.

Grüße
Jörg

Hm, das sollte eigentlich nicht so sein und ist, ohne Zugriff auf den Router während er gerade nicht funktioniert, ziemlich schwer zu analysieren. Um welchen Knoten geht es denn genau?

Wenn du willst können wir aber mal einen Zeitpunkt ausmachen (wenn der Knoten gerade “kaputt” ist), dann gucke ich mal ob ich von deinem Client Pakete auf dem Gateway empfangen kann. Dazu müsstest du mir dann allerdings die MAC Adresse dieses Geräts in einer PM schicken.

Hallo Ben:

der Router hängt wieder seit gestern nachmittag. Ich lasse ihn jetzt so. MAC Adresse habe ich geschickt.

Jörg

öhm, und wohin hast du sie geschickt? Ich hab nix bekommen.

Halt an Deine Returnadresse: forum@ffrn.de. Gibts ne andere?
Jörg

Das ist nur die Adresse unter der das Forum Mails verschickt, nicht meine Adresse.

UPDATE: nachdem bisher niemand eine Idee hatte, wie dem Problem abgeholfen werden kann, habe ich jetzt einfach in den crontab alle 6h einen reboot eingetragen. dann ist er eben um 0h,6h,12h, 18h jeweils für 2 min down, aber jetzt läuft er unbeaufsichtigt (mit seltenen Ausnahmen, wo er schon nach weniger als 6 Stunden den Löffel aus der Hand legt).
Jörg

Mein Router hat sich heute auch zum erstem mal aufgehängt.
Das mit dem automatischen Reboot finde ich keine schlechte Idee.
Wo stell ich das ein?

Kurzanleitung: Du gehst ins Webinterface vom Router und klickst auf “System/Scheduled Tasks”. In den Dialogkasten trägst Du ein

0 0 * * * reboot
0 6 * * * reboot
0 12 * * * reboot
0 18 * * * reboot

und klickst “Submit”.

Erklärung: Dies ist der crontab vom Router. cron ist ein Linux-Prozess, der automatisch Prozesse zu vorgegebenen Zeiten startet. Der erste Wert gibt die Minuten, der zweite die Stunden der Tageszeit an, zu dem etwas passieren soll, die nächsten drei Werte den Tag, den Monat und den Wochentag (hier Sterne, weil wir an jedem Tag rebooten wollen). Danach folgt das Unix-Kommando, das Du ausführen willst.

Weiteres findest Du unter Wiki “cron”.

Grüße
Jörg

Das funktioniert bei dir? Normalerweise ist cron unter OpenWRT nämlich noch deaktiviert. Allgemein sollte man die Hinweise in der OpenWRT Doku zu Cron beachten: http://wiki.openwrt.org/doc/howto/notuci.config

Ja, funktioniert hier. Auch /var/spool/crom existiert, habe ich das vielleicht selbst erzeugt? Weiss ich nicht mehr.
Aber wir haben immer noch das Problem, dass der Router sich so nach ca. 10h selbst aufhängt…
Ich glaube nicht an einen Hardwarefehler, der funzt sonst einwandfrei, direkt nach Kauf bei der Amazone und Installation Eurer Firmware.

Jörg

/var/spool/cron natürlich.

Wie ich in verschiedenen Posts hier schon erwähnt habe, ist das Thema nicht so einfach. Ein direkter HW Fehler ist es wohl nicht, aber vermutlich ein sehr Hardware naher Fehler.

Wie hier schon erwähnt tritt der gleiche Fehler genau so un-reproduzierbar auch bei anderen Communitys mit Gluon und einer neueren OpenWRT Version auf. Ein einfaches Update hilft hier also nicht unbedingt. Aktuell liegt die Vermutung nahe, auch Aufgrund verschiedener Issues im OpenWRT Bugtracker, das es sich um einen Fehler in der SoC Firmware oder auf low-Level Ebene der Treiber Module des WLAN Chips in OpenWRT handelt. Insbesondere ist dabei die Ad-hoc Implementierung im Verdacht, bei Störungen im 2,4GHz Bereich den gesamten WLAN Stack mit sich zu reißen. Dieses Argumentation wird auch noch dadurch gefördert, dass das Problem nicht überall sondern nur örtlich begrenzt auftritt.

Leider sind wir bei der Lösung des Problems auf die Entwickler von OpenWRT angewiesen, da mir niemand bekannt ist, der Erfahrungen im Debugen von WLAN Chip Treibern hat. Da kann es allerdings etwas dauern, da die meisten Leute ja WLANs im Ad-hoc Modus nicht nutzen und so die Priorität nicht so hoch ist.

Mein Tipp für dich wäre mal zu gucken ob das Problem mit einem anderen Gerät noch immer auftritt oder ob es noch auftritt, wenn du ihn mal wo anders hinstellst. Evl. sogar in ein anderes Gebäude bringst.

Mein Tipp für dich wäre mal zu gucken ob das Problem mit einem anderen
Gerät noch immer auftritt oder ob es noch auftritt, wenn du ihn mal wo
anders hinstellst. Evl. sogar in ein anderes Gebäude bringst.

Klar, aber dazu habe ich im Moment keine Zeit. Der Standort ist auch gerade an einem Fenster zur Straße hin.

Ich glaube auch, dass es von einem Zusammenspiel interner und externer Faktoren abhängt, weil das Problem mit der Gesamtlaufzeit des Geräts zusammen hängt (Speicherleck?). Auf jeden Fall habe ich die crontab jetzt so modifiziert, wie in Deinem Link beschrieben (ich sehe die Logik ein, obwohl das bei mir nicht zu einer Endlosschleife geführt hat):

0 0 * * * sleep 70 && touch /etc/banner && reboot
0 6 * * * sleep 70 && touch /etc/banner && reboot
0 12 * * * sleep 70 && touch /etc/banner && reboot
0 18 * * * sleep 70 && touch /etc/banner && reboot

Grüße
Jörg

Das ist ärgerlich aber gut zu wissen. Da ich teilweise mehrfach pro Woche Router resetten darf, bin ich dazu übergegangen Zeitschaltuhren mit auszuliefern, die mir die Dinger einfach nachts um vier Uhr stromlos machen. Das ist besonders bei schwer zugänglichen Routern ratsam.

OK.

Also bei mir verliert der Router mittlerweile auch öfter den Uplink over WLAN und hängt sich auf.
Hab daher auch mal den Self-Reboot eingetragen.

Da wie schon beschrieben das Problem auch in neueren Firmware-Versionen wohl nicht gelöst sein wird, wäre eventuell zu überlegen, ob es möglich ist, eine Self-Reboot Funktion schon fest als optionales feature mit in die Benutzereinstellungen einzubauen.

Off
every 2h
every 3h
every 12h
every 24h

Der Benutzer kann dann direkt auswählen, ob er den Router automatisch in bestimmten Intervallen rebooten will.

Vielleicht kann mir mal jemand von den Betroffenen nach dem Crash folgendes pasten:
cat /sys/kernel/debug/crashlog

Ich habe zwei Knoten. Der eine läuft durchgehend stabil. Der andere zeigt ebenfalls das o.g. verhalten.

Der eine hat einen Uplink und der andere ist nur per mesh verbunden?
Und die Problematik tritt nur bei dem per mesh verbundenen auf?

@hdvalentin Exakt so war meine Konfiguration. Wegen des Fehlers habe ich angefangen wild und unkoordiniert am Meshrouter (Leutershausen03) herumzuspielen. Dadurch habe ich ihn komplett fehlkonfiguriert. Mußte ihn daher vom Netz nehmen, weil gar nichts mehr ging. Ich hatte vor, ihn einfach nochmal zu flashen, sobald der Fehler behoben wurde.