Moin zusammen,
ich habe hier einen WR3600 mit Gluon 2016.2.1 auf dem die Bandbreitenbegrenzung nicht greift.
uci set simple-tc.mesh_vpn.enabled=1 && uci set simple-tc.mesh_vpn.limit_egress=6000 && uci set simple-tc.mesh_vpn.limit_ingress=1000
mit und ohne commit oF!
Trotzdem noch Download/Upload Raten von >10/>5 Mbit/s.
Hat jemand ne Idee was man tun muss, damit es klappt?
Könnte es sein, dass das erst nach dem nächsten ifdown/ifup (ggf. reboot) aktiv wird?
Teste das nachher und melde mich.
Das müsste so sein, ich erinnere mich an den Fall, dass wir simple-tc zeitgesteuert eingesetzt haben und daher mit den üblichen uci befehlen nicht weiter kamen, da wir sonst jedes mal in den flash schrieben müssten + reboot. Es gibt aber die Möglichkeit mit
gluon-simple-tc mesh-vpn 3000 1000
das ganze im laufenden Betrieb zu tun.
Setzt ihr dafür ein spezielles Paket ein? Bei mir liegt in /usr/bin nichts passendes:
gluon-simple-tc mesh-vpn 3000 1000
-ash: gluon-simple-tc: not found
Hm das war wohl gluon-simple-tc auf gluon 2015, wenn ich das richtig im github sehe, dann gibt es das jetzt nicht mehr einzeln.
So ich habe mir das Ganze nun zu Ende angeschaut. Es ist tatsächlich so, dass man sowohl commiten, als auch den Router neustarten muss.
Ich habe dafür ein issue erstellt:
hast du auch ohne commit ein /etc/init.d/network restart ausprobiert?
Nein.
Nur ein WAN Kabel raus/rein.
dann behaupte bitte nicht, dass ein reboot nötig ist, wenn network restart nicht versucht wurde 
Mir gefällt dein Ton nicht.
Da es afaik nirgends eine debug Anleitung gibt handelte ich nach bestem Wissen und Gewissen.
Ich habe sogar im Forum und IRC um nachgefragt. Ich kann nicht alle Eventualitäten bedenken …
sorry, aber wenn man nicht weiß woran es liegt, sollte man nicht einfach behaupten dass ein reboot nötig wäre.
Man kann das dann so formulieren, dass man es eben nicht weiß, a la „Weiß vielleicht jemand, was man tun muss, damit man nicht den Knoten neustarten muss?“
Laut gluon issue tracker reicht es aus, fastd neuzustarten, meine Vermutung mit network restart war also falsch.
/etc/init.d/fastd restartDas ist nicht korrekt, das habe ich getestet.
ok, dann müssen wir abwarten bis neoraider das debuggen konnte…