Wäre es nicht sinnig einen Reboot alle x Tage als Job einzutragen? Dann würden die aufheben Fall mal neustarten.
Mit freundlichen Grüßen Jens Ellerbrock -------------------- Freifunk Nordwest e.V. Website Unterstütze uns doch mit einer kleinen Spende, oder ganz einfach beim Onlineshoppen (ohne extra Kosten) Von meinem Samsung Galaxy Smartphone gesendet. -------- Ursprüngliche Nachricht --------Von: Simon Kurka via Nordwest nordwest@lists.ffnw.de Datum: 12.01.17 02:29 (GMT+01:00) An: Allgemeine Liste nordwest@lists.ffnw.de Cc: Simon Kurka dev@simon.kurka.cc Betreff: Re: [Nordwest] Neuer Beitrag: Neue Firmware 1.2.1 On 12.01.2017 00:20, Jan-Tarek Butt via Nordwest wrote:
On 01/12/17 00:13, Simon Kurka via Nordwest wrote:
Bei vielen Geräten genügt ein Reboot. Ich konnte bisher nicht nachvollziehen woran es genau hakt.
Mit 1.2.1 hatte das nicht mehr viel zu tun. Es betrifft wohl auch nur die OL Hood und ist gegen 1 Uhr am Samstag aufgetreten. Die Rheinländer haben an dem WE am Backbone gespielt und wir hatten eine Abweichung in der Kernelversion in der OL Hood.
Ein paar Logs von Routern mit direktem physischen Zugriff (Remote geht ja leider nicht) wäre wirklich interessant.
Wieso geht das nicht? Wann meinst du über das lokale WLAN über die linklocal Adresse auf das gerät oder über seriell ?
Weil die Geräte nunmal offline sind...
Ich vermute lokal über WLAN genügt, ansonsten ist seriell natürlich auch interessant.
Diese Möglichkeit fände ich generell eine gute Sache. Evtl. auch im Webconfig vom Routeraufsteller konfigurierbar (z.B. 1x täglich, 1x wöchentlich, 1x monatlich inkl. Uhrzeiteinstellung). Hier und da kann es ja doch mal haken und es wird durch einen Reboot gelöst. Da unsere Router in Weener auch mittlerweile recht weitläufig verteilt sind bzw. werden, spart das auch die ein oder andere Fahrt. Ich persönlich würde meine Router am liebste jede Nacht einmal rebooten lassen und dann geht's wieder frisch ans Werk ;)
Michael
Am 12.01.2017 um 08:13 schrieb Jens Ellerbrock | Freifunk Nordwest e. V. via Nordwest:
Wäre es nicht sinnig einen Reboot alle x Tage als Job einzutragen? Dann würden die aufheben Fall mal neustarten.
Moin,
ich wollte von meiner Seite zu der Problematik auch noch etwas schreiben.
Tatsächlich ist es so, dass es am Freitag Nacht zu 2 Problemen gekommen ist. Wir haben einen Backport 4.8er Kernel auf der OL Hood gefahren, die ein beschädigtes Batman-ADV Modul gefahren hat. Nach Rücksprache mit den Münsterländern haben sich dort auch mehrere Systeme aufgehangen. Für mich steht fest, dass dies der Ausschlaggebende Punkt war. Lange Rede: Kernel wurde downgraded und Problem sollte damit behoben sein.
Ich habe bei vielen Routern geholfen, diese waren alle nach einem manuellen Reboot wieder da. Von Freitag bis heute sind dadurch > 50 Router wieder online gekommen.
VG
Stefan
Am 12.01.2017 um 08:24 schrieb Michael Nolte via Nordwest:
Diese Möglichkeit fände ich generell eine gute Sache. Evtl. auch im Webconfig vom Routeraufsteller konfigurierbar (z.B. 1x täglich, 1x wöchentlich, 1x monatlich inkl. Uhrzeiteinstellung). Hier und da kann es ja doch mal haken und es wird durch einen Reboot gelöst. Da unsere Router in Weener auch mittlerweile recht weitläufig verteilt sind bzw. werden, spart das auch die ein oder andere Fahrt. Ich persönlich würde meine Router am liebste jede Nacht einmal rebooten lassen und dann geht's wieder frisch ans Werk ;)
Michael
Am 12.01.2017 um 08:13 schrieb Jens Ellerbrock | Freifunk Nordwest e. V. via Nordwest:
Wäre es nicht sinnig einen Reboot alle x Tage als Job einzutragen? Dann würden die aufheben Fall mal neustarten.
Nordwest mailing list Nordwest@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/nordwest
Am 12.01.2017 um 08:13 schrieb Jens Ellerbrock | Freifunk Nordwest e. V. via Nordwest:
Wäre es nicht sinnig einen Reboot alle x Tage als Job einzutragen? Dann würden die aufheben Fall mal neustarten.
Das so umzusetzen halte ich für keine gute Lösung.
Die Situation von der wir ausgehen ist doch: Router i.O. > Router nicht i.O.
Stumpf einen Reboot alle n Tage reinzuhauen, mag das Problem bei den Offline Routern zwar lösen. Es sorgt aber gleichzeitig für einen unnötigen Reboot bei 100% aller Geräte die funktionieren. Wozu?
Ich würde etwas bevorzugen in der Richtung...
Teste ob Gegenstelle XY erreichbar. Wenn ja, warte 12 Std. Teste nochmal.
Wenn nein, warte 6 Std. Teste nochmal. Wenn nein, warte 3 Std. Teste nochmal. Wenn nein, warte 3 Std. Teste nochmal. Wenn nein, mache Reboot.
1. Damit werden die Online Geräte nicht angefasst. 2. Es wird insgesamt 12 Std. gewartet bis letztlich der Router sich neustartet. Damit gibt es gleichzeitig auch eine Zeitspanne in der die Gegenseite bei sich Probleme lösen kann. Vielleicht liegt es auch an ihr. 3. Sollte es länger als 12 Std. dauern ist auch dafür gesorgt, weil der Counter nach einem Reboot natürlich wieder von vorne anfängt.
On 01/12/17 08:24, Michael Nolte via Nordwest wrote:
Diese Möglichkeit fände ich generell eine gute Sache. Evtl. auch im Webconfig vom Routeraufsteller konfigurierbar (z.B. 1x täglich, 1x wöchentlich, 1x monatlich inkl. Uhrzeiteinstellung). Hier und da kann es ja doch mal haken und es wird durch einen Reboot gelöst. Da unsere Router in Weener auch mittlerweile recht weitläufig verteilt sind bzw. werden, spart das auch die ein oder andere Fahrt. Ich persönlich würde meine Router am liebste jede Nacht einmal rebooten lassen und dann geht's wieder frisch ans Werk ;)
Bei der reboot Variante schließe ich mich ulf an. Das wäre eine äußerst unschöne Variante. In diesen der mail die ich gestern zu beginn geschickt habe gin es mit um Informationen wo das Problem genau liegt, damit gezielt dieses gelöst werden kann. Finden wir wirklich keine andere alternative wäre ich bei der Reboot Intervall Variante dabei.
vg Tarek
Hi,
ich wollte von meiner Seite zu der Problematik auch noch etwas schreiben.
Tatsächlich ist es so, dass es am Freitag Nacht zu 2 Problemen gekommen ist. Wir haben einen Backport 4.8er Kernel auf der OL Hood gefahren, die ein beschädigtes Batman-ADV Modul gefahren hat. Nach Rücksprache mit den Münsterländern haben sich dort auch mehrere Systeme aufgehangen. Für mich steht fest, dass dies der Ausschlaggebende Punkt war. Lange Rede: Kernel wurde downgraded und Problem sollte damit behoben sein.
Ich habe bei vielen Routern geholfen, diese waren alle nach einem manuellen Reboot wieder da. Von Freitag bis heute sind dadurch > 50 Router wieder online gekommen.
Ok, D.h. betroffene Geräte melden sich via fastd noch beim Server? Magst du da magst du da mal eine Ausgabe schickten?
Melden sich die geräte garnicht mehr via batman-adv ?
vg Tarek
Hi,
Am 12.01.2017 um 09:32 schrieb Jan-Tarek Butt via Nordwest:
Ok, D.h. betroffene Geräte melden sich via fastd noch beim Server? Magst du da magst du da mal eine Ausgabe schickten?
nein, da sie offline sind und einmal rebootet werden müssen.
Melden sich die geräte garnicht mehr via batman-adv ?
Batman hat hier auf den Routern wohl Timeouts, daher wird hier kein Tunnel neu aufgebaut.
VG
Stefan
On 01/12/17 10:04, Stefan via Nordwest wrote:
Hi,
Am 12.01.2017 um 09:32 schrieb Jan-Tarek Butt via Nordwest:
Ok, D.h. betroffene Geräte melden sich via fastd noch beim Server? Magst du da magst du da mal eine Ausgabe schickten?
nein, da sie offline sind und einmal rebootet werden müssen.
Hats du das getestet, das sie sich nicht melden?
Melden sich die geräte garnicht mehr via batman-adv ?
Batman hat hier auf den Routern wohl Timeouts, daher wird hier kein Tunnel neu aufgebaut.
Was hat der tunnel mit batman zuthen ?
vg Tarek
Hi,
Am 12.01.2017 um 10:09 schrieb Jan-Tarek Butt via Nordwest:
Hats du das getestet, das sie sich nicht melden?
jo, hab ich nachgesehen.
Was hat der tunnel mit batman zuthen ?,
Vermutlich steht auf den betroffenen Routern noch ein Batman Gateway in Range. Warum auch immer der Tunnel sich nicht neu aufbaut, hier wird batman das Problem sein. Wie bereits mehrfach gesagt: Kurzer Reboot, und das Problem ist weg.
On 01/12/17 10:12, Stefan via Nordwest wrote:
Hi,
Am 12.01.2017 um 10:09 schrieb Jan-Tarek Butt via Nordwest:
Hats du das getestet, das sie sich nicht melden?
jo, hab ich nachgesehen.
Hm, ok.
Was hat der tunnel mit batman zuthen ?,
Vermutlich steht auf den betroffenen Routern noch ein Batman Gateway in Range. Warum auch immer der Tunnel sich nicht neu aufbaut, hier wird batman das Problem sein. Wie bereits mehrfach gesagt: Kurzer Reboot, und das Problem ist weg.
Der fastd unabhängig von batman-adv und damit auch der Aufbau des Tunnels.
Ich vermute evtl. ein Kernel crash. oder so. wenn es wirklich an einem bug in batman-adv Module liegt. Das kennen wir ja zu genüge von vor 4 Jahren... Allerdings brächte ich dazu Infos ob lokal überhaupt eine Verbindung möglich ist bzw. zusätzlich wie die LEDs blinken.
vg Tarek
Hi,
Am 12.01.2017 um 10:30 schrieb Jan-Tarek Butt via Nordwest:
Ich vermute evtl. ein Kernel crash. oder so. wenn es wirklich an einem bug in batman-adv Module liegt. Das kennen wir ja zu genüge von vor 4 Jahren... Allerdings brächte ich dazu Infos ob lokal überhaupt eine Verbindung möglich ist bzw. zusätzlich wie die LEDs blinken.
ich denke auch in diese Richtung.
Die LEDs blinken wie wahnsinnig....
On 01/12/17 10:34, Stefan via Nordwest wrote:
Hi,
Am 12.01.2017 um 10:30 schrieb Jan-Tarek Butt via Nordwest:
Ich vermute evtl. ein Kernel crash. oder so. wenn es wirklich an einem bug in batman-adv Module liegt. Das kennen wir ja zu genüge von vor 4 Jahren... Allerdings brächte ich dazu Infos ob lokal überhaupt eine Verbindung möglich ist bzw. zusätzlich wie die LEDs blinken.
ich denke auch in diese Richtung.
Die LEDs blinken wie wahnsinnig....
Das hilft mir nicht viel ...
ein video wäre hilfreich oder eine detalierte beschreibung
vg Tarek
-
Jan-Tarek Butt -
Jens Ellerbrock | Freifunk Nordwest e. V. -
Michael Nolte -
Stefan -
Stefan Dunkel
-
Ulf W.