Hallo zusammen,
ist mir bisher nicht aufgefallen, aber aus irgendeinem Grund greift die Bandbreitenbegrenzung nicht,
Ich stelle egress/ingress 5000/5000 ein und kann munter mit 20 MBit/s downloaden.
Aktiviert ist die Einstellung natürlich.
Hat da jemand eine Idee?
Schau mal in diesen Thread.
Denn eigentlich sollte es spätestens nach update der Tunneldigger-Server und 2018.2er-Firmware gelöst sein.
Ich danke dir. Dann werden wir wohl die Gateways updaten müssen.
Ja, mit dem neusten Gluon wird das Download-Limit vom Server erzwungen, was besser geht als das auf dem Client zu machen. Aber dafür muss der Tunneldigger-Broker das auch können.
Ich hatte aber auch den Eindruck, dass hier zumindest ein Bug in der Migration vorliegt… dass also bei Knoten, die vor 2018.2 ein Download-Limit hatten, dieses Limit beim Update verloren geht. Habe bisher nicht die Zeit gehabt, das zu reproduzieren.
Habe jetzt ein neues Gateway mit aktuellem (afaik) Tunneldigger von slovenija aufgesetzt und die Bandbreite beim Knoten begrenzt:
uci set simple-tc.mesh_vpn.enabled='1'
uci set simple-tc.mesh_vpn.limit_ingress='1000'
uci set simple-tc.mesh_vpn.limit_egress='500'
uci commit simple-tc
Auch nach einem Reboot des Knotens wird keine Bandbreite begrenzt. Der Knoten ist auf Gluon 2018.2.1.
Wie kann ich am Gateway eigentlich die Tunneldigger-Version ermitteln?
Und ist die o.g. Syntax noch korrekt?
Mag sein, aber wie wird es benutzt?
Siehe verlinkten Patch: nach uci set tunneldigger.mesh_vpn.limit_bw_down=1000; uci commit und reboot tut’s auf dem „Knoten“:
Sun Apr 7 14:34:03 2019 daemon.debug td-client: Broker usage of gw01.freifunk-owl.de:20001: 63
Sun Apr 7 14:34:03 2019 daemon.debug td-client: Broker usage of gw02.freifunk-owl.de:20001: 63
Sun Apr 7 14:34:03 2019 daemon.info td-client: Selected gw01.freifunk-owl.de:20001 as the best broker.
Sun Apr 7 14:34:04 2019 daemon.info td-client: Tunnel successfully established.
Sun Apr 7 14:34:04 2019 daemon.info td-client: Requesting the broker to configure downstream bandwidth limit of 10000 kbps.
Und der angeschlossene Client hat plötzlich nur noch 10 MBit/sec down:
Selecting best server based on ping...
Hosted by Spacken.net (Hagen) [86.91 km]: 49.676 ms
Testing download speed................................................................................
Download: 8.68 Mbit/s
Testing upload speed......................................................................................................
Upload: 222.83 Mbit/s
Lt. grep hat die FW die entsprechenden Patches drin und sollte das Downstream-Limit via Tunneldigger statt lokal setzen, vgl. cat /etc/config/tunneldigger auf dem Knoten.
Danke, hatte das im Code gesehen, war aber nicht sicher, dass es so anzuwenden ist.
Edit: und jetzt auch getestet, funktioniert gut.
Ich hatte es so verstanden, dass „wenn man sowohl Gluon wie auch Supernode aktualisiert hat“, das „down-limit“ des Knotens seitens des Servers (als egres) geregelt wird und damit dann „exakt“ passt, ohne schlimmes BufferBloat.
Jedenfalls wird in dem Falle der ingress-Bandbreitenwunsch per Tunneldigger dem Gateway signalisiert und in der Folge die Bandbreite vor dem Senden limitiert. Bei fastd oder sonstigen empfängerseitigen Methoden kann eine eingehende Beschränkung ja nur simuliert werden, indem Pakete nach dem Empfang verworfen werden. Insofern sollte eine eingehende Beschränkung nur bei Tunneldigger überhaupt angeboten werden — eine ausgehende macht bei asymetrischen Verbindungen wie xDSL und insbesondere KabelTV-Internet latent Sinn (besser wäre aber auch hier eine Lösung am Upstreamrouter, die allen nicht sonstwie angeforderten Traffic für Freifunk bereitstellt).