On 03/21/18 17:55, lrnzo via Dev wrote:
Danke für diese coole Zusammenfassung. Wäre es nicht sinnvoll, wir würden einen kleinen watchdog in die firmware einbauen, der regelmäßig nachguckt ob eines der beschriebenen Symptome auftritt, versucht ein logread oder weitere Informationen an (zB an alert@ffnw.de) zu schicken, die beim debuggen helfen? ggf könnte der auch rebooten oder wlan-scan machen.
Die in der mail beschriebenen bugs sind nur die kritischen die eben sowas wir mail notification, autoupdate und co nicht möglich machen. zumindest in den meisten fällen. Es gibt natürlich noch einige mehr die auch bei gluon nicht als issue gelistet sind, so z.b. müssten Cross-Site-Request-Forgery Attaken möglich sein. Die sind im falle der status page nicht extrem kritisch aber eben auch nicht was man belassen will.
Aber zurück zum watchdoog. Ich bin ebenfalls für einen, allerdings sind die o.g. bugs zwar für sich Erstmal kategorisiert, diese aber eindeutig auf einem gerät zu erfassen ist nicht ganz so einfach. Dazu fehlen z.b. logs und test. Z.b. im falle des high load bugs kann man nicht einfach via cron die load überwachen und bei einem wert größer 10 rebooten. Cron funktioniert nicht mehr eben durch die load. Um eine Vorstellung davon zu bekommen. Ich hatte das glück das zuffällig ein dev router von Mir in Vietnam den bug bekommen hat. Der bug lässt sogar das LED Blinken vollständig erlahmen.
Aktuell Arbeite ich an einen Bug den ich bei Ulf in der schule gefunden habe. Diese kann zur Zerstörung der Network conf führen.
Schöne Grüße aus dem v6-freien ICE-WLAN ;( Lorenz
Ich hab mir für solche zwecke einen kleinen daemon geschriben der im hindergrund immer prüft ob ich v6 haben oder nur v4 und dem entsprechend dann ein fastd startet. So hab ich immer public v6 :P