Automatisch regelmäßiger reboot

Ok, danke euch allen. Ich hoffe dann auf die neue Version - bzw, dass die das Problem damit gelöst wird.

Jedwede Konfiguration, Änderung am DSL-Router vor Ort steht für mich nicht zur Debatte. Wenn dann eines Tages irgendetwas am netz in dem Buchladen nicht funktioniert bin ich drann. Das gilt es zu vermeiden. Wenn nur FF nicht geht baue ich schlimmsten Falls eher den FF-Router ab.
… aber wenn 2014.4 mit BB als Basis da Besserung bringt ist ja alles ok.

Evtl. hilft [dieser Artikel][1] hier.

[1]: OpenWrt Router Neustart ohne Dauerschleife - Michis Blog[quote=„adorfer, post:20, topic:2768“]

Aber wenn das Ding alle 10 Tage einen freeze hinlegt, dann hilft Dir auch ein automatischer täglicher Reboot nichts.
[/quote]

Ist der Router nach einem täglichen Neustart nicht wieder frisch? Ich habe einen TP-Link TL-WR1043ND v1 mit einem Atheros AR9132@400MHz unter DD-WRT laufen. Dieser stieg nach einer guten Woche immer aus. Man konnte sich zwar mit dem Gerät verbinden, hat aber sonst komplett gestreikt. Abhilfe hat damals nur Stecker raus und wieder rein gebracht. War aber lästig, da ich jedes Mal eine Leite brauchte … Also habe ich eine „Lebenserhaltung“ Einstellung (ist die deutsche Übersetzung vom Menü :p) aktiviert, die das Gerät täglich um 03:42 neu startet. Das hat das Problem eigentlich gelöst.

Das gleiche Problem, dass der Router TL-WR841N „einfriert“ habe ich jetzt auch. Dabei wird die SSID von Freifunk und dem Mesh ausgestrahlt, jedoch ist eine Anmeldung an dem Gerät nicht möglich. Dies kam bei mir seit dem 19.02.15 zweimal vor. An der Internetleitung kann es nicht liegen, obwohl Unity Media doch sehr unzuverlässig ist, ich konnte über meinen normalen Internetzugang noch surfen. Nach einem Hardreset (Stecker raus/rein) ging die Anmeldung am Freifunk WLAN wieder. Ein Softwarereset habe ich mangels Zeit noch nicht eingestellt.

Bin ich mit dem Problem alleine oder gibt es noch weitere Router die das Verhalten an den Tag legen?

Die Frage hast du dir ja selbst beantwortet :smiley:

Ich würde empfehlen es zu beobachten. Wenn es nochmal passiert eventuell router tauschen - um auszuschließen, dass es am konkreten Gerät liegt.
Falls es dann wieder auftritt - so wie bei meinem Sorgenkind - solltest du prüfen was der Hauptrouter treibt. - eine Fritzbox oder Speedport loggt ja zum Beispiel einiges.
Wenn das der eigene Anschluss ist hast du sicher gute Chancen das zu beheben.

Mir gehört der betroffene Anschluss nicht, deshalb kann ich nicht am DSL-Router lösen.

Um einzugrenzen, ob der Wlan Chipset der Schuldige ist, schliess beim nächsten Auftreten dieses Effekts einen Rechner per Kabel an eine der gelben Buchsen. Dort fällt doch auch Freifunk raus, falls nicht umkonfiguriert.

2 „Gefällt mir“

Wegen übergelaufener Neighbourtables kann es auch sein, dass ein Router schlicht „übers Gateway“ nicht mehr rauskommt. d.h. Netzintern geht noch alles, man kann auch per batctl p Nodes im eigenen Netz erreichen, sogar die Gateways. Aber man bekommt keinen UDP/IP-Traffic mehr übers Gateway hinein/hinaus.
Da hift dann auch nur ein Reboot.
(Da gab’s mal Vorschläge, das per Script zu tun. Wurde aber abgelehnt, da es Seiteneffekte wie „ständig zyklisch neu bootende Nodes“ geben kann, wenn die Gateways streiken sollten. Und dann wären die vielen Internen Dienste der lokalen Freifunkwolke nicht mehr sinnvoll zu gebrauchen von den Nutzerinnen. Ach ja, wer Ironie findet, der/die darf sie behalten.)

Laut Alfred war der Router die ganze Zeit online. Es waren lediglich 0 Clients auf dem Gerät.

Der Hauptrouter ist ein Gerät von Unity Media und der kann fast gar nichts und wird eigentlich nur als Zugangspunkt zum Inet genutzt. Werde heute Abend mal prüfen, ob dieser nicht doch irgendwo etwas protokolliert.

Kannst Du den Node (seine öffentliche IPv6-Adresse) in so einem Fall noch „von draußen“ (also aus dem Internet) erfolgreich anpingen?

1 „Gefällt mir“

Das ist eine gute Frage, leider habe ich noch keinen Anschluss nutzen können, an dem ich eine IPv6 Adresse anpingen konnte. Gibt’s da ggf. eine Webseite, die dies für mich erledigen könnte?

edit
Hier kann man pingen

Ist der Nodename denn so geheim, dass Du ihn hier nicht verraten magst?

Nein :slight_smile: FF-RE-DAT-Meckinghoven-01

Aber nach einem Hardreset heute morgen läuft er wieder

Also ggf einen Ping
(ping6 2a03:2260:50:1:c66e:1fff:febd:773a, respektive ping -6 2a03:2260:50:1:c66e:1fff:febd:773a)
versuchen „aus dem Internet“.

Das ganze ist dann konkret hier beschrieben:

https://news.hamburg.freifunk.net/article.php?id=147&group=freifunk.de.hamburg

Zur Einrichtung dieses Cron Jobs musst Du Dich mit dem Knoten per ssh

verbinden und 1 Zeile in eine neu Datei schreiben. Auf der Kommandozeile:
   
# echo '5 3 * * * /sbin/reboot > /dev/null' > /etc/crontabs/root
   

   
Dieser Cron Job bootet Deinen Knoten Nachts um 03:05 Uhr jeden Tag.

Es muss also

5 3 * * * /sbin/reboot > /dev/null

in die Datei

/etc/crontabs/root

geschrieben werden.

2 „Gefällt mir“

Die beschriebene Lösung funktioniert und lindert das Problem!

Es ist allerdings nach dem EIntragen wie oben beschrieben ein Neustart fällig. Ohne (mit vorher leerer Crontab) ging es erstmal nicht.

Jetzt startet der Router nachts um 1:20 neu.
Es gab einmal den Fall, dass der Router von Speedport gegen 16 Uhr wieder blocked wurde und dann nachts wieder kam - also genau das was ich erreichen wollte.

Geiler wäre eventuell ein Script, dass irgendwo hin einen Ping macht (Gateway) und bei nicht Verfügbarkeit direkt neu startet. Das dann wieder als Cron-Job alle 15min oder so.

Aber wie geschreiben - der oben genannte Reboot per cronjob tuts schonmal.

vielen Dank

1 „Gefällt mir“

Es reicht auch: /etc/init.d/gluon-cron restart

1 „Gefällt mir“

Auch wenn das Thema etwas älter ist:

Ich würde sogar vor dem Neustart die aktuelle Uhrzeit in eine Datei sichern

und nach dem Neustart versuchen die Uhrzeit über ntp zu aktualisieren (falls das nicht ab werk erfolgt).

zum einen wird die Uhrzeit per ntp synchronisiert.
Das wegsichern von dynamischen Daten im Flash ist jedoch ein sehr zweischneides Schwert, zumal „kurz vor einem Reboot“.

Mein Hintergedanke ist dass der Router so nicht in eine Bootschleife kommen sollte.
Allerdings müsste man 5 Minuten beim auslesen addieren sonst kommt es in meinem Fall auch zur Bootschleife.

Das ist derzeit bei meinen Builds eher rustikal gelöst:
Wöchnentlicher Reboot Donnerstags nachts zwischen 3 und 5 (banales Random. Wobei der Job der das Random delay macht um eine feste Zeit startet, eben damit er nicht zufällig mehrmals in der Nacht bootet mit etwas Pech)

Und ich weiss, dass die Uhrzeit nach dem Boot (vor dem ntp-sync aus der ravd/rdns-Wolke) irgendein Freigtag nacht vor 2h irgendwann Mitte 2015 ist…

Ich nehme aber gern noch Pullrequest in

2 „Gefällt mir“

Tägliche Neustarts haben wir in Leipzig seit mehreren Jahren auf den meisten Nodes und es hat uns schon so einige manuelle Neustarts bzw. Hausbesuche gespart. Leider, waren es auch mehrere Probleme, die man damit (zumindest grob) umgeht (kaputte bridges, abgestürzte routingprotokolle, kaputtes wlan,…) Aber Freifunk funktioniert dann jeden Tag „wie neu gestartet“ :smile:

Das o.g. Kommando zum Neustarten hat diverse Nachteile, besonders oft habe ich schon das Kernel-module batman-adv gesehen, was beim "entladen hängt und der Router nicht neustartet:

  • reboot

Besser ist ein nachhaltigerer Befehl, den auch wir verwenden:

  • reboot -f

Selbst da habe ich schon einige Freifunk-Nodes erlebt, die damit NICHT neustarten, besonders, wenn die Hälfte vom Node sowieso nicht mehr funktioniert. Noch sichererer Neustart geht dann mit:

  • echo b > /proc/sysrq-trigger

p.s. Vorsicht mit der Uhrzeit (wenn Node zb keine bekommen sollte. Sauberer wäre, nur neuzustarten, wenn der Node zb mindestens 12h uptime hatte… Wir hatten schon verrückte Reboot-Loops!

Hier ein Statistik Bild eines instabilen Nodes (Testfirmware), der dann jeweils nachts wieder on ist durch diesen Neustart:

3 „Gefällt mir“