Hallo zusammen,
Unten aufgeführt findet ihr Aktuell bekannte Probleme die zu den hier hin und wieder auf tauchenden Mails mit bescheidenen Problemen führen. Um da mal ein bissen Übersicht rein zubringen.
- OOM auf 32MB RAM Geräten.
Seid dem wechsel auf v2017.1.x gibt es einen OOM Bug auf wahrscheinlich nur 32MB RAM Geräten. Dieser Bug ist aktuell schwer bis gar nicht reproduzierbar. Die Ursache ist nach wie vor vollständig unbekannt. Daran wird aktuell viel rumprobiert. Im besten Falle führt dieser Bug zum Reboot des betroffenen Gerätes.
- High Load
Ebenfalls seid dem wechsel auf v2017.1.x gibt das Problem das einige Geräte zeitweise eine hohe load aufweisen. Diese reicht bis zu eine 15er load von 20 und führt zum versagen der Funktionalität aufgrund der hohen load kommt es zu abstürzenden Diensten sowie den dauerhaften versagen (cron, hoodselector, autoupdater ... etc). Dies kann u.a. soweit führen das Interfaces verloren gehen und der Router somit erst nach einem Reboot wieder erreichbar sowie nutzbar wird. Auch dieser Bug ist Aktuell nicht reproduzierbar bis vor ein paar Wochen wurden dieser mit dem OOM assoziiert.
- (Ath9k Bug)
Der Ath9k Bug ist bei uns im Netz einige Jahre nicht mehr gesichtet worden. Und ich kann es aktuell auch nicht 100% bestätigen. Allerdings gibt es seid einigen Monaten dem ATH9k Bug typische Ähnlichkeiten Die vermehrt beobachtet wurden. Diese Ähnlichkeiten Treten wie folgt in Erscheinung: 1. Die link Qualität der WLAN Interfaces singt auf 2-6%. 2. Die WLAN Interfaces verschwinden vollständig. 3. Die WLAN Interfaces sind sichtbar allerdings besteht keinerlei Verbindung Möglichkeit.
Alle o.g. Zustände sind mir und auch Anderen bereits aufgefallen und führen in der Regel zur Funktionslosigkeit des WLANs. Im Falle 1 hilft der wechsel des WLAN states z.b. WLAN scannen oder ein Reset durch das Kommando "wifi". Die anderen beiden Zustände, 2. und 3., konnte ich bisher nur über einen Reboot auflösen. Meine Vermutung für das verstärkte aufkommen ist u.a. der Parallel betrieb von IBSS + 11s der das Phänomen verstärkt. Sowie der hoodselector und/oder dem geolocator, die einen regelmäßigen Änderungszustand des WLANs aufrufen können und somit den vermuteten Ath9k Bug triggern.
- Fastd verbindet sich nach einen Server Reboot manchmal nicht wieder.
Dieses Problem Hab ich u.a. bei dem Router "BrigitteB" im laden meiner Mama untersuchen können. Die Logs des Routers haben keine Fehler aufgewiesen und konnten lediglich keinen erfolgreichen Handshake realisieren. Da diese Problem scheinbar auch nur im ffnw Netz auftritt ist meine Vermutung, das es sich um ein bisher unbekanntes Server seitiges Problem handelt.
- Freifunk IP lose Router.
Hin und wieder kann man auf der Karte Router finden die keine Freifunk v6 Adressen besitzen bzw. nur die linklocal. Hier vermute ich entweder das es sich um ein Resultat des high load bugs handelt oder dieses auf ein Server seitiges Problem rückzuführen ist oder ein Problem was durch den hoodselector entsteht.
- Bootsector pattitions bug bei UniFi AP AC Lite/Pro
Dieser Bug bezieht sich auf die o.g. genannten dual-band Geräte und tritt beim sysupgrade command auf. Dies betrifft nicht alle Geräte, allerdings ist auch nicht abzusehen welches und welches nicht betroffen ist. Der autoupdater für die o.g. Geräte ist aktuell nicht verfügbar. Ein update der Geräte kann nur Manuell durchgeführt werden. Dieser Zustand bleibt bis zum nächsten gluon release so bestehen. Im aktuellen lede und gluon Upstream ist dieses Problem bereits behoben.
- ubiquity Nanostation eth Bug
Dieser Bug ist auf einen hardware Fehler in einigen Ubiquity Geräten zurück zu führen. Er gilt in Lede als behoben und sollte bei uns auch bereits behoben sein. Ich habe ihn hier nur aufgelistet da dies in den letzten Monaten u.a. ein Grund für Router Ausfälle war.
Schöne Grüße Tarek
Hi,
ich gehe auf die beiden Punkte mal ein:
Am 20.03.2018 um 17:10 schrieb Jan-Tarek Butt via Dev:
Dieses Problem Hab ich u.a. bei dem Router "BrigitteB" im laden meiner Mama untersuchen können. Die Logs des Routers haben keine Fehler aufgewiesen und konnten lediglich keinen erfolgreichen Handshake realisieren. Da diese Problem scheinbar auch nur im ffnw Netz auftritt ist meine Vermutung, das es sich um ein bisher unbekanntes Server seitiges Problem handelt.
Dann würden aber auch andere Router ein Problem haben. Wir verwenden hier die aktuellste fastd Version und mehr als das können wir nicht machen. Hier ist alles ready.
Hin und wieder
kann man auf der Karte Router finden die keine Freifunk v6 Adressen besitzen bzw. nur die linklocal. Hier vermute ich entweder das es sich um ein Resultat des high load bugs handelt oder dieses auf ein Server seitiges Problem rückzuführen ist oder ein Problem was durch den hoodselector entsteht.
Punkt 1, das tritt fast nur bei den Routern mit hohem Load auf, und nachdem man diese restartet und es sich beruhigt, haben die Router auch wieder eine IP. Bei radvd kann man nicht viel einstellen, sprich da ist kein Fehler auf unserer Seite.
VG
Stefan
On 03/20/18 17:14, Stefan via Dev wrote:
Hi,
ich gehe auf die beiden Punkte mal ein:
Am 20.03.2018 um 17:10 schrieb Jan-Tarek Butt via Dev:
Dieses Problem Hab ich u.a. bei dem Router "BrigitteB" im laden meiner Mama untersuchen können. Die Logs des Routers haben keine Fehler aufgewiesen und konnten lediglich keinen erfolgreichen Handshake realisieren. Da diese Problem scheinbar auch nur im ffnw Netz auftritt ist meine Vermutung, das es sich um ein bisher unbekanntes Server seitiges Problem handelt.
Dann würden aber auch andere Router ein Problem haben. Wir verwenden hier die aktuellste fastd Version und mehr als das können wir nicht machen. Hier ist alles ready.
Es betrifft ja auch prinzipiell alle fastd VPN Router. Wie oben formuliert ist "BrigitteB" einer der Router an die ich rann konnte als dieser sich in dem besagten Zustand befand.
Hin und wieder
kann man auf der Karte Router finden die keine Freifunk v6 Adressen besitzen bzw. nur die linklocal. Hier vermute ich entweder das es sich um ein Resultat des high load bugs handelt oder dieses auf ein Server seitiges Problem rückzuführen ist oder ein Problem was durch den hoodselector entsteht.
Punkt 1, das tritt fast nur bei den Routern mit hohem Load auf, und nachdem man diese restartet und es sich beruhigt, haben die Router auch wieder eine IP. Bei radvd kann man nicht viel einstellen, sprich da ist kein Fehler auf unserer Seite.
Woran kannst du das reproduzieren?
vg Tarek
Hi,
Am 20.03.2018 um 17:24 schrieb Jan-Tarek Butt via Dev:
Es betrifft ja auch prinzipiell alle fastd VPN Router. Wie oben formuliert ist "BrigitteB" einer der Router an die ich rann konnte als dieser sich in dem besagten Zustand befand.
Aha, und wieso sind dann >2500 Router online wenn ALLE das Problem haben?
Woran kannst du das reproduzieren?
Ich sehe auf der Karte <20 Router die keine v6 IPv6 Adresse haben. v6 Traffic ist ausreichend im Netz. Würde das alles nicht da sein, würde ich die Aussage bestätigen.
On 03/20/18 17:26, Stefan via Dev wrote:
Hi,
Am 20.03.2018 um 17:24 schrieb Jan-Tarek Butt via Dev:
Es betrifft ja auch prinzipiell alle fastd VPN Router. Wie oben formuliert ist "BrigitteB" einer der Router an die ich rann konnte als dieser sich in dem besagten Zustand befand.
Aha, und wieso sind dann >2500 Router online wenn ALLE das Problem haben?
Natürlich tritt dies nicht immer auf und auch nicht bei allen. Es sind aber Ansicht Erstmal alle betroffen da nicht auszuschließen ist das bestimmte Geräte Typen nicht betroffen sind. Dieses Problem tritt nur in Situationen wie Server reboots auf. Und auch nur im FFNW Netz, da zumindest ich aus anderen communitys keine Meldungen über ein solche Phänomen habe und unsere Firmware config identisch zu allen gluon Firmware ist. Ist ein Server seitiges Problem nicht auszuschließen.
Woran kannst du das reproduzieren?
Ich sehe auf der Karte <20 Router die keine v6 IPv6 Adresse haben. v6 Traffic ist ausreichend im Netz. Würde das alles nicht da sein, würde ich die Aussage bestätigen.
Das ist keine Reproduktion des Problems und sagt sowieso erst mal relativ wenig aus. Nur weil ein Router keine V6 adresse hat heißt es nicht das es kein v6 traffic gibt.
vg Tarek
Hi,
Am 20.03.2018 um 17:40 schrieb Jan-Tarek Butt via Dev:
Das ist keine Reproduktion des Problems und sagt sowieso erst mal relativ wenig aus. Nur weil ein Router keine V6 adresse hat heißt es nicht das es kein v6 traffic gibt.
Willst du mich grad veräppeln? Wie sollen Router ohne v6 Adresse Traffic per v6 durchschieben? Naja, egal.
Ich hab mittlerweile eine ziemlich ähnliche Meinung wie Simon... Das Problem ist Firmwareseitig und nichts auf Serverseite. Wenn ein GW rebootet wird kann es vorkommen, dass Tunnel nicht wieder sofort zu stande kommen. Ich sehe hier aber auch den Router, denn danach tauchen nicht mal verbindungsversuche im Log auf -> Router Bug. Das ist nichts was ein Server steuern kann, die Anfrage muss immer vom Client geschehen.
Aber wenn du meinst, dann grab das komplette Setup aus und versuch das zu fixen.
On 03/20/18 17:51, Stefan via Dev wrote:
Hi,
Am 20.03.2018 um 17:40 schrieb Jan-Tarek Butt via Dev:
Das ist keine Reproduktion des Problems und sagt sowieso erst mal relativ wenig aus. Nur weil ein Router keine V6 adresse hat heißt es nicht das es kein v6 traffic gibt.
Willst du mich grad veräppeln? Wie sollen Router ohne v6 Adresse Traffic per v6 durchschieben? Naja, egal.
Also Erstmal finde ich deine Reaktion hier sehr unpassend...
Ich hab mittlerweile eine ziemlich ähnliche Meinung wie Simon... Das Problem ist Firmwareseitig und nichts auf Serverseite. Wenn ein GW rebootet wird kann es vorkommen, dass Tunnel nicht wieder sofort zu stande kommen. Ich sehe hier aber auch den Router, denn danach tauchen nicht mal verbindungsversuche im Log auf -> Router Bug. Das ist nichts was ein Server steuern kann, die Anfrage muss immer vom Client geschehen.
Aber wenn du meinst, dann grab das komplette Setup aus und versuch das zu fixen.
Ofensichtlich hast du meine ausgehende Mail nicht gelesen. Simon hat seine Meinung hier nicht formuliert. Daher kann ich da relativ wenig zu sagen.
Ich breche an dieser stelle mal ab.
vg Tarek
Fühl dich nicht gleich auf den Schlips getreten, aber ich fand das da echt amüsant. V6 Traffic ohne eine IP durchzuleiten.
Wie dem auch sei, wir können das gerne debuggen, nur denke ich finden wir den Fehler eher, wenn die ganzen Firmware Bugs behoben sind. Da sind ja leider momentan eine ganze Menge die diese Probleme verursachen könnten.
Ich streite nicht ab das es auch was anderes sein kann, aber wir sollten das am nächsten liegende erstmal beheben.
So und nun haben wir beiden uns wieder lieb. :p
Von meinem iPhone gesendet
Am 20.03.2018 um 18:58 schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
On 03/20/18 17:51, Stefan via Dev wrote: Hi,
Am 20.03.2018 um 17:40 schrieb Jan-Tarek Butt via Dev: Das ist keine Reproduktion des Problems und sagt sowieso erst mal relativ wenig aus. Nur weil ein Router keine V6 adresse hat heißt es nicht das es kein v6 traffic gibt.
Willst du mich grad veräppeln? Wie sollen Router ohne v6 Adresse Traffic per v6 durchschieben? Naja, egal.
Also Erstmal finde ich deine Reaktion hier sehr unpassend...
Ich hab mittlerweile eine ziemlich ähnliche Meinung wie Simon... Das Problem ist Firmwareseitig und nichts auf Serverseite. Wenn ein GW rebootet wird kann es vorkommen, dass Tunnel nicht wieder sofort zu stande kommen. Ich sehe hier aber auch den Router, denn danach tauchen nicht mal verbindungsversuche im Log auf -> Router Bug. Das ist nichts was ein Server steuern kann, die Anfrage muss immer vom Client geschehen. Aber wenn du meinst, dann grab das komplette Setup aus und versuch das zu fixen.
Ofensichtlich hast du meine ausgehende Mail nicht gelesen. Simon hat seine Meinung hier nicht formuliert. Daher kann ich da relativ wenig zu sagen.
Ich breche an dieser stelle mal ab.
vg Tarek
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
Hi,
On 03/20/18 19:07, Stefan Dunkel via Dev wrote:
Fühl dich nicht gleich auf den Schlips getreten, aber ich fand das da echt amüsant. V6 Traffic ohne eine IP durchzuleiten.
Stefan, ich fühle mich nicht auf den Schlips getreten. Ich fande die Formulierung mit "veräppeln" nur etwas ungünstig. Aber es kann sein das ich es falsch aufgefasst habe. Es geht lediglich um eine Kategorisierung der bekannten bugs um leuten aus der community die Möglichkeit zu geben bei Problemen entsprechende logs oder co. bereit zu stellen.
Bzgl. des v6 die Router sowie Server Routen über batman-adv (Layer 2) spricht wenn du einen VPN Router hast der keine v6 Adresse hat beeinflusst es keine mesh Nachbarn. Es sorgt lediglich dafür das der betroffene VPN Router z.b. nicht updaten kann. Umliegende mesh Nachbarn können natürlich weiterhin v6 Traffic erzeugen. Eine Situation wo ein Router keine v6 bekommen hat muss auch kein permanenter zustand sein.
Wie dem auch sei, wir können das gerne debuggen, nur denke ich finden wir den Fehler eher, wenn die ganzen Firmware Bugs behoben sind. Da sind ja leider momentan eine ganze Menge die diese Probleme verursachen könnten.
Ich streite nicht ab das es auch was anderes sein kann, aber wir sollten das am nächsten liegende erstmal beheben.
Wie ich es in der Ausgangsmail formuliert habe kann es natürlich auch ein Firmware spezifischen Problem sein.
So und nun haben wir beiden uns wieder lieb. :p
Ich hab dich immer lieb mein Teddybär :-*
Schöne grüße Tarek
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.
Schöne Grüße aus dem v6-freien ICE-WLAN ;( Lorenz
Am 20.03.2018 um 17:10 schrieb Jan-Tarek Butt via Dev:
Hallo zusammen,
Unten aufgeführt findet ihr Aktuell bekannte Probleme die zu den hier hin und wieder auf tauchenden Mails mit bescheidenen Problemen führen. Um da mal ein bissen Übersicht rein zubringen.
- OOM auf 32MB RAM Geräten.
Seid dem wechsel auf v2017.1.x gibt es einen OOM Bug auf wahrscheinlich nur 32MB RAM Geräten. Dieser Bug ist aktuell schwer bis gar nicht reproduzierbar. Die Ursache ist nach wie vor vollständig unbekannt. Daran wird aktuell viel rumprobiert. Im besten Falle führt dieser Bug zum Reboot des betroffenen Gerätes.
- High Load
Ebenfalls seid dem wechsel auf v2017.1.x gibt das Problem das einige Geräte zeitweise eine hohe load aufweisen. Diese reicht bis zu eine 15er load von 20 und führt zum versagen der Funktionalität aufgrund der hohen load kommt es zu abstürzenden Diensten sowie den dauerhaften versagen (cron, hoodselector, autoupdater ... etc). Dies kann u.a. soweit führen das Interfaces verloren gehen und der Router somit erst nach einem Reboot wieder erreichbar sowie nutzbar wird. Auch dieser Bug ist Aktuell nicht reproduzierbar bis vor ein paar Wochen wurden dieser mit dem OOM assoziiert.
- (Ath9k Bug)
Der Ath9k Bug ist bei uns im Netz einige Jahre nicht mehr gesichtet worden. Und ich kann es aktuell auch nicht 100% bestätigen. Allerdings gibt es seid einigen Monaten dem ATH9k Bug typische Ähnlichkeiten Die vermehrt beobachtet wurden. Diese Ähnlichkeiten Treten wie folgt in Erscheinung: 1. Die link Qualität der WLAN Interfaces singt auf 2-6%. 2. Die WLAN Interfaces verschwinden vollständig. 3. Die WLAN Interfaces sind sichtbar allerdings besteht keinerlei Verbindung Möglichkeit.
Alle o.g. Zustände sind mir und auch Anderen bereits aufgefallen und führen in der Regel zur Funktionslosigkeit des WLANs. Im Falle 1 hilft der wechsel des WLAN states z.b. WLAN scannen oder ein Reset durch das Kommando "wifi". Die anderen beiden Zustände, 2. und 3., konnte ich bisher nur über einen Reboot auflösen. Meine Vermutung für das verstärkte aufkommen ist u.a. der Parallel betrieb von IBSS + 11s der das Phänomen verstärkt. Sowie der hoodselector und/oder dem geolocator, die einen regelmäßigen Änderungszustand des WLANs aufrufen können und somit den vermuteten Ath9k Bug triggern.
- Fastd verbindet sich nach einen Server Reboot manchmal nicht wieder.
Dieses Problem Hab ich u.a. bei dem Router "BrigitteB" im laden meiner Mama untersuchen können. Die Logs des Routers haben keine Fehler aufgewiesen und konnten lediglich keinen erfolgreichen Handshake realisieren. Da diese Problem scheinbar auch nur im ffnw Netz auftritt ist meine Vermutung, das es sich um ein bisher unbekanntes Server seitiges Problem handelt.
- Freifunk IP lose Router.
Hin und wieder kann man auf der Karte Router finden die keine Freifunk v6 Adressen besitzen bzw. nur die linklocal. Hier vermute ich entweder das es sich um ein Resultat des high load bugs handelt oder dieses auf ein Server seitiges Problem rückzuführen ist oder ein Problem was durch den hoodselector entsteht.
- Bootsector pattitions bug bei UniFi AP AC Lite/Pro
Dieser Bug bezieht sich auf die o.g. genannten dual-band Geräte und tritt beim sysupgrade command auf. Dies betrifft nicht alle Geräte, allerdings ist auch nicht abzusehen welches und welches nicht betroffen ist. Der autoupdater für die o.g. Geräte ist aktuell nicht verfügbar. Ein update der Geräte kann nur Manuell durchgeführt werden. Dieser Zustand bleibt bis zum nächsten gluon release so bestehen. Im aktuellen lede und gluon Upstream ist dieses Problem bereits behoben.
- ubiquity Nanostation eth Bug
Dieser Bug ist auf einen hardware Fehler in einigen Ubiquity Geräten zurück zu führen. Er gilt in Lede als behoben und sollte bei uns auch bereits behoben sein. Ich habe ihn hier nur aufgelistet da dies in den letzten Monaten u.a. ein Grund für Router Ausfälle war.
Schöne Grüße Tarek
Dev mailing list -- dev@lists.ffnw.de To unsubscribe send an email to dev-leave@lists.ffnw.de
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
On 03/20/18 17:10, Jan-Tarek Butt via Dev wrote:
Hallo zusammen,
Da bei dem letzten update scheinbar auch wieder ein paar Router sich nicht zurück gemeldet haben. U.a. weil die sein dem mit sehr hohen loads fahren. Als bsp.: https://map.ffnw.de/friedhof/#/en/map/68725168dd22 https://map.ffnw.de/friedhof/#/en/map/98ded0a783b2
Daher neige ich inzwischen auch zu einem Reboot watchdoog solange bis das Problem gefunden und behoben wurde.
- High Load
Ebenfalls seid dem wechsel auf v2017.1.x gibt das Problem das einige Geräte zeitweise eine hohe load aufweisen. Diese reicht bis zu eine 15er load von 20 und führt zum versagen der Funktionalität aufgrund der hohen load kommt es zu abstürzenden Diensten sowie den dauerhaften versagen (cron, hoodselector, autoupdater ... etc). Dies kann u.a. soweit führen das Interfaces verloren gehen und der Router somit erst nach einem Reboot wieder erreichbar sowie nutzbar wird. Auch dieser Bug ist Aktuell nicht reproduzierbar bis vor ein paar Wochen wurden dieser mit dem OOM assoziiert.
Also da ich bei einigen Geräten bereits Probleme mit den reboot command fest gestellt hatte wäre hier eine Möglichkeit den kernel in panic zu versetzen und somit dein Reboot sicher zu stellen. (echo c > /proc/sysrq-trigger) Das sollte sich bei einer load von 20 besser ausführen lassen. Jetzt ist nur noch die frage was führt es aus. Außer cron sehe ich da nicht viele Möglichkeiten. Da die logs keine Informationen liefern bleibt uns nur den watchdoog anhand von der load zu triggern.
vg Tarek
On 03/25/18 01:11, Jan-Tarek Butt via Dev wrote:
On 03/20/18 17:10, Jan-Tarek Butt via Dev wrote:
Hallo zusammen,
Da bei dem letzten update scheinbar auch wieder ein paar Router sich nicht zurück gemeldet haben. U.a. weil die sein dem mit sehr hohen loads fahren. Als bsp.: https://map.ffnw.de/friedhof/#/en/map/68725168dd22 https://map.ffnw.de/friedhof/#/en/map/98ded0a783b2
Daher neige ich inzwischen auch zu einem Reboot watchdoog solange bis das Problem gefunden und behoben wurde.
- High Load
Ebenfalls seid dem wechsel auf v2017.1.x gibt das Problem das einige Geräte zeitweise eine hohe load aufweisen. Diese reicht bis zu eine 15er load von 20 und führt zum versagen der Funktionalität aufgrund der hohen load kommt es zu abstürzenden Diensten sowie den dauerhaften versagen (cron, hoodselector, autoupdater ... etc). Dies kann u.a. soweit führen das Interfaces verloren gehen und der Router somit erst nach einem Reboot wieder erreichbar sowie nutzbar wird. Auch dieser Bug ist Aktuell nicht reproduzierbar bis vor ein paar Wochen wurden dieser mit dem OOM assoziiert.
Also da ich bei einigen Geräten bereits Probleme mit den reboot command fest gestellt hatte wäre hier eine Möglichkeit den kernel in panic zu versetzen und somit dein Reboot sicher zu stellen. (echo c > /proc/sysrq-trigger) Das sollte sich bei einer load von 20 besser ausführen lassen. Jetzt ist nur noch die frage was führt es aus. Außer cron sehe ich da nicht viele Möglichkeiten. Da die logs keine Informationen liefern bleibt uns nur den watchdoog anhand von der load zu triggern.
Ich sehe aktuell keine Möglichkeiten einen Reboot vernünftig zu triggern... Klar könnten wir sowas bauen das ein Gerät mit einer load von <10 rebootet. Dmit würde aktuell ca. 40 Router rebooten. Bei einer load von <1 währen es knapp 200 Router. Ich sehe da halt die Problematik wenn tatsächlich mal auf Grund von irgend nen Event im Netz dann diverse Router potentiell zum reboot kommen, obwohl es evtl. nicht Notwändig wäre. Anderseits, wenn jemadn mesh neighbours generiert und damit die batman-adv orginator tables voll schreibt und alle router OOM gehen wäre es gleich zu sehen...
vg Tarek
On 03/26/18 15:26, Jan-Tarek Butt via Dev wrote:
On 03/25/18 01:11, Jan-Tarek Butt via Dev wrote:
On 03/20/18 17:10, Jan-Tarek Butt via Dev wrote:
Hallo zusammen,
Da bei dem letzten update scheinbar auch wieder ein paar Router sich nicht zurück gemeldet haben. U.a. weil die sein dem mit sehr hohen loads fahren. Als bsp.: https://map.ffnw.de/friedhof/#/en/map/68725168dd22 https://map.ffnw.de/friedhof/#/en/map/98ded0a783b2
Daher neige ich inzwischen auch zu einem Reboot watchdoog solange bis das Problem gefunden und behoben wurde.
- High Load
Ebenfalls seid dem wechsel auf v2017.1.x gibt das Problem das einige Geräte zeitweise eine hohe load aufweisen. Diese reicht bis zu eine 15er load von 20 und führt zum versagen der Funktionalität aufgrund der hohen load kommt es zu abstürzenden Diensten sowie den dauerhaften versagen (cron, hoodselector, autoupdater ... etc). Dies kann u.a. soweit führen das Interfaces verloren gehen und der Router somit erst nach einem Reboot wieder erreichbar sowie nutzbar wird. Auch dieser Bug ist Aktuell nicht reproduzierbar bis vor ein paar Wochen wurden dieser mit dem OOM assoziiert.
Es gibt wohl noch einen anderen bug der durch androids zu einer hohen load führen könnte. Auffällig ist halt das wir so viele Gerate mit einer hohen load haben.
Ich würde im nächsten release wohl das arp limit pkg mit rein nehmen, damit wir die möglichen Problem Verursacher reduzieren. Das o.g. pkg ist vor kurzen bei gluon hinzu gekommen.
vg Tarek
Hi,
Am 02.04.2018 um 14:37 schrieb Jan-Tarek Butt via Dev:
Ich würde im nächsten release wohl das arp limit pkg mit rein nehmen, damit wir die möglichen Problem Verursacher reduzieren. Das o.g. pkg ist vor kurzen bei gluon hinzu gekommen.
würde es dann nicht Sinn machen, den aktueleln Sign Request abzubrechen und eine neue FW mit diesem zu bauen?
On 04/03/18 14:17, Stefan via Dev wrote:
Hi,
Am 02.04.2018 um 14:37 schrieb Jan-Tarek Butt via Dev:
Ich würde im nächsten release wohl das arp limit pkg mit rein nehmen, damit wir die möglichen Problem Verursacher reduzieren. Das o.g. pkg ist vor kurzen bei gluon hinzu gekommen.
würde es dann nicht Sinn machen, den aktueleln Sign Request abzubrechen und eine neue FW mit diesem zu bauen?
Korrekt, ich wollte vorher den Mechanismus testen.
vg Tarek
On 03/20/18 17:10, Jan-Tarek Butt via Dev wrote:
Hallo zusammen,
Unten aufgeführt findet ihr Aktuell bekannte Probleme die zu den hier hin und wieder auf tauchenden Mails mit bescheidenen Problemen führen. Um da mal ein bissen Übersicht rein zubringen.
- OOM auf 32MB RAM Geräten.
Seid dem wechsel auf v2017.1.x gibt es einen OOM Bug auf wahrscheinlich nur 32MB RAM Geräten. Dieser Bug ist aktuell schwer bis gar nicht reproduzierbar. Die Ursache ist nach wie vor vollständig unbekannt. Daran wird aktuell viel rumprobiert. Im besten Falle führt dieser Bug zum Reboot des betroffenen Gerätes.
Ich denke ein watchdoog hier ist nicht notwendig da bei OOM eh ein reboot getriggert wird.
vg Tarek
On 03/20/18 17:10, Jan-Tarek Butt via Dev wrote:
Hallo zusammen,
- (Ath9k Bug)
Der Ath9k Bug ist bei uns im Netz einige Jahre nicht mehr gesichtet worden. Und ich kann es aktuell auch nicht 100% bestätigen. Allerdings gibt es seid einigen Monaten dem ATH9k Bug typische Ähnlichkeiten Die vermehrt beobachtet wurden. Diese Ähnlichkeiten Treten wie folgt in Erscheinung:
- Die link Qualität der WLAN Interfaces singt auf 2-6%.
- Die WLAN Interfaces verschwinden vollständig.
- Die WLAN Interfaces sind sichtbar allerdings besteht keinerlei Verbindung
Möglichkeit.
Alle o.g. Zustände sind mir und auch Anderen bereits aufgefallen und führen in der Regel zur Funktionslosigkeit des WLANs. Im Falle 1 hilft der wechsel des WLAN states z.b. WLAN scannen oder ein Reset durch das Kommando "wifi". Die anderen beiden Zustände, 2. und 3., konnte ich bisher nur über einen Reboot auflösen. Meine Vermutung für das verstärkte aufkommen ist u.a. der Parallel betrieb von IBSS + 11s der das Phänomen verstärkt. Sowie der hoodselector und/oder dem geolocator, die einen regelmäßigen Änderungszustand des WLANs aufrufen können und somit den vermuteten Ath9k Bug triggern.
Ich bin gerade dabei folgenden workaraound zu versethen [0]. Die Lösung scheint soweit erst mal ohne reboot auszukommen.
https://github.com/tecff/gluon-packages/tree/master/tecff-ath9k-broken-wifi-...
Ich überlege gerade auch ob wir die möglichen watchdoogs die wir jetzt imoh finden können auch ins nächste release mit rein nehmen. Einfach um zu verhindern das weitere Router verschollen gehen.
vg Tarek
On 03/25/18 21:55, Jan-Tarek Butt via Dev wrote:
On 03/20/18 17:10, Jan-Tarek Butt via Dev wrote:
Hallo zusammen,
- (Ath9k Bug)
Der Ath9k Bug ist bei uns im Netz einige Jahre nicht mehr gesichtet worden. Und ich kann es aktuell auch nicht 100% bestätigen. Allerdings gibt es seid einigen Monaten dem ATH9k Bug typische Ähnlichkeiten Die vermehrt beobachtet wurden. Diese Ähnlichkeiten Treten wie folgt in Erscheinung: 1. Die link Qualität der WLAN Interfaces singt auf 2-6%. 2. Die WLAN Interfaces verschwinden vollständig. 3. Die WLAN Interfaces sind sichtbar allerdings besteht keinerlei Verbindung Möglichkeit.
Alle o.g. Zustände sind mir und auch Anderen bereits aufgefallen und führen in der Regel zur Funktionslosigkeit des WLANs. Im Falle 1 hilft der wechsel des WLAN states z.b. WLAN scannen oder ein Reset durch das Kommando "wifi". Die anderen beiden Zustände, 2. und 3., konnte ich bisher nur über einen Reboot auflösen. Meine Vermutung für das verstärkte aufkommen ist u.a. der Parallel betrieb von IBSS + 11s der das Phänomen verstärkt. Sowie der hoodselector und/oder dem geolocator, die einen regelmäßigen Änderungszustand des WLANs aufrufen können und somit den vermuteten Ath9k Bug triggern.
Ich bin gerade dabei folgenden workaraound zu versethen [0]. Die Lösung scheint soweit erst mal ohne reboot auszukommen.
https://github.com/tecff/gluon-packages/tree/master/tecff-ath9k-broken-wifi-...
Ich überlege gerade auch ob wir die möglichen watchdoogs die wir jetzt imoh finden können auch ins nächste release mit rein nehmen. Einfach um zu verhindern das weitere Router verschollen gehen.
Ich hab es nun soweit verstanden. Die Lösung ist sehr gut. Wie in der von lorenz geschriebenen Mail "[Nordwest] Mesh kaputt, iwinfo hilft." reicht es den WLAN State zu ändern. Anstelle von "iwinfo scan" reicht aber schon ein "wifi". So arbeitet auch der watchdoog. Ist auch bereits getestet.
vg Tarek
-
Jan-Tarek Butt -
lrnzo -
Stefan -
Stefan Dunkel