Bei mir geht aktuell fast gar nichts mehr, alle Knoten auf dauerreboot :-( Könnte es daran liegen, dass ich aktuell einen 0.5.13er und 3 0.6.0er laufen habe, und die sich gegenseitig abschießen?
Habe auf der seriellen Schnittstelle gerade folgendes gesehen:
[ 72.020000] br-client: Multicast hash table chain limit reached: bat0
[ 72.020000] br-client: Cannot rehash multicast hash table, disabling snooping: bat0, 381, -22
Ist das normal?
Gerade einen Crash mitgeschnitten:
odhcp6c invoked oom-killer
https://paste.ffrn.de/?751dff5db93f680f#IvK3oqpB7SvvXqq3NUB9CfoXJN1nUhvjfnbab/yYdjQ=
Ich werde IPv6 WAN mal deaktivieren, mal schauen ob das was bringt.
Ich habe gerade Version 0.6.1 der Firmware als Ergänzung im Experimental Branch veröffentlicht. Bei der Version 0.6.0 hat ein Paket gefehlt das seit 2016.2 enthalten ist und für Verbesserungen bei IPv6 Multicast sorgt. Solltet ihr einen Switch mit IGMP/MLD Snooping benutzten, werft bitte mal kurz einen Blick hier auf die Doku: https://gluon.readthedocs.io/en/v2016.2/package/gluon-ebtables-segment-mld.html
Ich habe die Doku gelesen und habe einen Switch, der IGMP/MLD Snooping kann. Verstanden habe ich aber trotzdem nicht, was der eigentliche Zweck des Paketes ist, und in welchem Anwendungsszenario man nun den Switch umkonfigurieren müsste. Über den Switch geht ja nur Fastd traffic, und der ist Unicast (oder?). Oder betrifft einen das erst dann, wenn man Mesh-over-Ethernet macht?
Mit der 0.6.1 laufen meine Knoten aktuell sehr viel stabiler, es ist allerdings aktuell auch kaum Traffic drauf.
Genau das ist der Fall :) Wie es sich mit Client-Netz über den Switch verhält weiß ich leider nicht
Da müsste ich glaube ich @NurticVibe widersprechen. Das Mesh ist schon gekapselt, daher funktionieren die Operationen darauf nicht. Von daher vermute ich eher, dass es um das Client Netz geht. Am besten man fragt nochmal bei den Gluon Leuten im IRC nach.
Da bin ich ja schon mal froh, dass ich nicht der einzige bin, der den Text nicht im Detail verstanden hat. Relativ sicher bin ich mir, dass es Auswirkungen im Private-WLAN-Modus hat, denn da gibt es ja wirklich jede Menge Szenarien mit Multicast. Wenn ich mal Zeit habe, frage ich mal nach.
Meine Knoten laufen mittlerweile (zum ersten Mal seit Monaten) stabil:
Seitdem laufen 2 Knoten seit 2,5 Tagen ohne Neustart, der dritte ist nur neu gestartet weil ich meine Verkabelung umgestellt habe. Ich werde das noch einige Tage beobachten und dann schrittweise die beiden Änderungen oben rückgängig machen.
Auch wenn die 0.6.1 ziemlich stabil läuft, beobachte ich gerade ein Phänomen:
Kann jemand diese zyklischen Lastspitzen erklären? Sehe gerade, dass es genau 42 Minuten sind.
Nop, die sind uns am Wochenende auf dem FFHessen Meetup aber auch aufgefallen. Allerdings ist uns das alte Issue da nicht mehr eingefallen. Das könnte wirklich eine Regression in dieser Richtung sein. Von den Zeiten her könnte es passen.
Also was ich beobachten kann ist, global gesehen, das wir auf 24 Stunden 21,5 Stunden an Uptime-Zuwachs haben. Das deutet an, dass seit dem Update auf 2016.1.6 und der Umstellung auf 802.11s schon viele Knoten deutlich stabiler als vorher laufen. Auch die aktuellste 0.6.1er Version läuft bei mir inzwischen deutlich besser. Irgendwie hat es da einen harten Reboot (Strom ganz weg) gebraucht, damit sich der Knoten einkriegt. Einzig die regelmäßigen Load Peaks stören da noch das Bild.
Ich glaube es könnte sein, dass wir so langsam auf dem richtigen weg sind. Ich bin mal ganz gespannt darauf was passiert, wenn du deine Änderungen wieder aktivierst.
Das wäre ein toller Wert, wobei ich den aus dem Grafana nicht ableiten kann. 21,5 Stunden in 24 Stunden wäre ca. 0,9 Tage pro Tag, ich sehe maximal 0,7 Tage pro Tag.
Kann man in Grafana mal die Ableitung der über eine Stunde gemittelten Uptime zeichnen lassen? Aktuell mache ich das immer so mit Kopfrechnen und Schätzen :-/
Es gibt mal wieder etwas neues:
Meine Knoten laufen in den letzten Tagen absolut stabil, alle Reboots sind erklärbar weil ich an meiner Infrastruktur rumgebastelt habe.
In Lorsch hatten wir in der Firma mal einen Knoten testweise auf die 0.6.1 geflashed, und der hat immer nur wenige Minuten Uptime geschafft (alle anderen Knoten noch auf 0.5.13). Wenn ich bei dem Knoten das WLAN abgeschaltet habe, lief er zumindest einige Stunden stabil, und wenn Kanal 11 ausgewählt wurde lief er sogar mit aktivem WLAN stabil.
Diesen Knoten habe ich nun testweise mit nach Hause genommen (Kanal wieder auf 6) und nur per Mesh eingebunden. Schon nach wenigen Minuten ist mein erster Knoten neu gestartet, eine Stunde später ein anderer. Es liegt also wahrscheinlich am Mesh, dass die Knoten oft neu starten.
Bei allen Knoten war IPv6 am WAN disabled (das scheint bei Knoten mit wenig RAM schon öfters ein Problem gewesen sein, vielleicht sollten wir das für Knoten mit wenig RAM generell deaktivieren).
Bei mir zeigt sich das gleiche Verhalten wie bei tobox. Der 841v9-Knoten mit 0.6.1 (wird über mesh vorsorgt) startet alle paar Minuten bis Stunden neu. Mit 0.5.13 lief er, ebenfalls im mesh, stabil. Bei mir tritt auch der regelmäßige load-Peak auf, jedoch scheint dieser nicht mit den Neustarts zusammen zu hängen.
Ich habe den Eindruck dass bei mir die Router vor allem dann rebooten, wenn sie NEUE oder MEHR ALS EINEN Mesh-Partner in ihrer Umgebung haben.
Nodes die keine Mesh-Partner sehen haben so gut wie keine Reboots. Nodes die nur einen Partner sehen sind hier ebenfalls stabil, während ihre Partner (die 2-3 andere Knoten sehen) ständig rebooten.
Alles WR841 mit stable Firmware.
Insgesamt ist es aber wesentlich besser als vor 0.5.12.
ja - schöne beobachtung - dann tritt das in Freiburg zumindest auch vermehrt auf …
ich verweise nochmal auf diese Bug Hinweise …
(ich les hier quer weil ich einige Dinge hier erfahren hab zu den großen batman tables … und eben auch prbleme mit aktuellem gluon 2016.2 hab (auch schon mit .1.6 und .1.5)
gluon im Master hat einen Patch der zumindest in Freiburg tut, und das Problem löst. Wenn dies das „gleiche“ ist - happy here you go
(es ist NICHT der TAG 2016.2 sondern Master, wird wohl 2016.2.1 werden)
Ìch habe aus Versehen die Experimental Version auf einem TL-WR1043ND Version 1.2 installiert.
Der Name ist HD-Hendesse-01 falls ihr meine Probleme debuggen wollt.
Fehler/Problem: Er startet immer mal wieder neu und bleibt dann mit einer aktiven Power LED stehen. Nach einem Stromlosmachen rennt er wieder eine Zeit lang bis er wieder hängen bleibt. Grafana sieht nicht gut aus.
Frage: Wie bekomme ich die stabile Version auf die Kiste? Muss ich hier etwas beachten?
Die Sysupgrade Firmware Stable nehmen und den Haken raus bei “Einstellungen übernehmen”.
Dann mit dem Token den VPN Key aktualisieren.
Wenn das nicht geht dann TFTP
Hat geklappt mit dem Sysupgrade und dem “Haken raus”. Die Kiste schnurrt mit der 0.5.13 weitgehend gut:
http://s.ffrn.de/dashboard/db/nodes?var-Node=HD-Hendesse-01&from=now%2Fw&to=now-1m