Gluon: Broken bandwidth limit setting with tunneldigger

[NeoRaider]

1682 tried to fix the default bandwidth limit settings for tunneldigger. Multiple issues were identified, some of them existing before that PR already:

• fastd and tunneldigger use separate UCI settings; migrating between fastd and tunneldigger does not preserve these settings
• 500-mesh-vpn unconditionally sets limit_ingress to 0 when has_tunneldigger and site.mesh_vpn.bandwidth_limit.enabled are set
• possibly other issues

Both v2018.2.x and master are affected.

[kaechele]

* 500-mesh-vpn unconditionally sets limit_ingress to 0 when `has_tunneldigger` and `site.mesh_vpn.bandwidth_limit.enabled` are set

This is to make sure that we don't use simple-tc for ingress shaping in case the Tunneldigger broker sets up ingress shaping on the remote end. Especially if a simple-tc value was set before.
Alternatively we could ensure that the value is completely absent when Tunneldigger is used.
In any case, there is virtually no reason to use simple-tc ingress shaping when also using Tunneldigger.

[NeoRaider]

* 500-mesh-vpn unconditionally sets limit_ingress to 0 when `has_tunneldigger` and `site.mesh_vpn.bandwidth_limit.enabled` are set

This is to make sure that we don't use simple-tc for ingress shaping in case the Tunneldigger broker sets up ingress shaping on the remote end. Especially if a simple-tc value was set before.
Alternatively we could ensure that the value is completely absent when Tunneldigger is used.
In any case, there is virtually no reason to use simple-tc ingress shaping when also using Tunneldigger.

@kaechele Obviously, there is no reason to use simple-tc with tunneldigger - but 0 sets simple-tc to a limit of 0, meaning that all packets should be dropped. Instead, enabled can be set to false (but I think I would prefer to just delete that UCI section completely when tunneldigger is used).

[NeoRaider]

Ah, I just noticed that tunneldigger doesn't do egress shaping itself. This makes a little more sense now, but 0 is still not the correct value - it must either be absent or - to impose no limit.

[Adorfer]

sorry, but i am unable to get it working.

root@Alfred-Koppel:~# uci show |grep vpn|grep limit

gluon.mesh_vpn.limit_egress='1000'
gluon.mesh_vpn.limit_ingress='131313'
gluon.mesh_vpn.limit_enabled='0'
simple-tc.mesh_vpn.limit_egress='1000'
tunneldigger.mesh_vpn.limit_bw_down='131313'

root@Alfred-Koppel:~# logread |grep 1313
Mon Jun 17 18:35:00 2019 daemon.info td-client: Requesting the broker to configure downstream bandwidth limit of 131313 kbps.

cat /etc/config/tunneldigger

config broker 'mesh_vpn'
        option uuid 'e894f662f35c'
        option group 'gluon-mesh-vpn'
        option broker_selection 'usage'
        option bind_interface 'br-wan'
        option interface 'mesh-vpn'
        option enabled '1'
        list address 'flingern-l.ffdus.de:10000'
        list address 'flingern-m.ffdus.de:10000'
        option limit_bw_down '131313'

(on gluon.mesh_vpn.limit_enabled='1'; uci commit; reboot. Same thing, but then at least "expected behaviour")

[NeoRaider]

@Adorfer You did not answer my last question. How did you set the value of gluon.mesh_vpn.limit_enabled? Just setting the value via uci and committing will not apply the setting, you also need to gluon-reconfigure. The initial defaults from site.conf and config wizard should update everything automatically.

[Adorfer]

i applied the values by rebooting. (i hardly ever use any webui)
the "gluon-reconfigure" i don't use, since i do not do multidomain.

[NeoRaider]

As I wrote before, you need to gluon-reconfigure (and then reboot). Without gluon-reconfigure, the settings will not be applied. This has nothing to do with multidomain.

Also, are the bandwidth limits from old firmwares correctly migrated to gluon.mesh_vpn?

[Adorfer]

1) this gluon-reconfigure was totally new for me in this context, it did not come across that apart from the multidomain-config. Perhaps this needs documentation.

2) after "gluon-reconfigure;reboot": looks to work as expected

migration: did not test yet.

[Adorfer]

tested (starting from sysupgrade-n "clean" each time, or "firstboot", if applicable)

2018.2.x l2tp (with limit enable) -"autoupdater-f"-> master-l2tp: with limit enabled OK
master-fastd (with limit enable) -"autoupdater-f"-> master-l2tp: with limit enabled OK
master-l2tp (with limit enable) -"autoupdater-f"-> master-fastd: with limit enabled OK
sysupgrade -n >"master-l2tp" with configmode "set limit": reboot: limit enabled OK
sysupgrade -n >"master-l2tp-key", enabled limit via shh, gluon-reconfigure, reboot: limit enabled OK

am i missing a scenario?