Qos-scripts actual download limit much lower than configured

I would like to limit bandwidth on a guest wifi. I've set up wifi following Configure a guest WLAN, but for traffic shaping I've used qos-scripts.

The problem is when I set limit 3 Mbps on guest interface and measure download speed, I get 0.22 Mbps instead. Interestingly when I set limits on wan or wlan interface, then messured speeds are about 3 Mbps.

Unfortunately I cannot use sqm-scripts, because there is not enough space on router.

Router: TP-Link TL-WR841N/ND v8.
OpenWrt version: OpenWrt Chaos Calmer 15.05 / LuCI (git-15.248.30277-3836b45)

/etc/config/qos

config interface guest
        option classgroup  "Default"
        option enabled      1
        option upload       250
        option download     3000 
        option overhead     0

Thanks for help.

As this version is very old and unsupported, it will be hard to get any support.
First consider upgrading to a newer version and if the problem persists we'll investigate further.

2 Likes

Try switching the values between these two options, on inward facing devices the meaning of upload and download often is inverted.

P.S.: This is because the traffic shaper actually has no clue what upload and download means all it knows is whether traffic is send by an interface (egress) or received (ingress). On the WAN interface ingress is equal to internet download anf egress equal to internet upload, but on say a LAN interface, the traffic egressing from the interface is send into the LAN and hence internet download, while the traffic ingressing into the interface is in the precess of being uploaded into the internet.
Tl;dr: using upload/download as short hands for egress/ingress only works as expected by (naive) users for outward facing devices, but it avoids having to explain the gory details for this rather common case.

2 Likes

First consider upgrading to a newer version and if the problem persists we'll investigate further.

Yes, that's true. Actually I just did upgrade to 18.06.4, but unfortunatelly I had to revert to 15.05.1, because there was not enough space even for qos-scripts. (18.06.4 must be larger). I understand that 4mb of flash storage on this router is not enough nowadays, but want to give it try before I throw it to the garbage, because apart from qos on this guest wlan, router is working nicely. As workaround I can also live with limits set on WAN, but that will limit my non guest wlan too.

In case it may help, I was in the similar situation with an old tl-wr841v5. I managed to run lede-17.01 on it with circa. 450KB free space for rootfs_data. It's still running quite well.

Here is a summary

  • IPv6 support was disabled
  • opkg, odhcpd, odhcp6c, etc. were stripped
  • Mach files were also stripped to only support tl-wr841v5
  • It has LuCI, wireguard, dnsmasq-full with ipset, iptables-mod-conntrack-extra

Very likely qos-scripts can fit in quite well.

More details can be found at https://github.com/yousong/gists/blob/master/lede/defconfig/wr841v5-yy

1 Like

Awesome. Switching download and upload actually worked! So happy. :slight_smile:
This community is awesome! Thank you guys.

2 Likes

I managed to run lede-17.01 on it with circa. 450KB free space for rootfs_data . It's still running quite well.

Thanks for this. I'll try to build stripped version of 18.06.4 according your gist some time in the future.

Update: Download limits are not applied correctly on boot. It's again 0.22 Mbits instead of 3. I also tried revert back download with upload and do immediate reboot, but it didn't made difference this time.

Could it be problem of service start ordering in rc.d?

lrwxrwxrwx    1 root     root            20 Feb  2  2016 S00sysfixtime -> ../init.d/sysfixtime
lrwxrwxrwx    1 root     root            14 Feb  2  2016 S10boot -> ../init.d/boot
lrwxrwxrwx    1 root     root            16 Feb  2  2016 S10system -> ../init.d/system
lrwxrwxrwx    1 root     root            16 Feb  2  2016 S11sysctl -> ../init.d/sysctl
lrwxrwxrwx    1 root     root            13 Feb  2  2016 S12log -> ../init.d/log
lrwxrwxrwx    1 root     root            14 Feb  2  2016 S12rpcd -> ../init.d/rpcd
lrwxrwxrwx    1 root     root            18 Feb  2  2016 S19firewall -> ../init.d/firewall
lrwxrwxrwx    1 root     root            17 Feb  2  2016 S20network -> ../init.d/network
lrwxrwxrwx    1 root     root            16 Feb  2  2016 S35odhcpd -> ../init.d/odhcpd
lrwxrwxrwx    1 root     root            14 Feb  2  2016 S50cron -> ../init.d/cron
lrwxrwxrwx    1 root     root            18 Feb  2  2016 S50dropbear -> ../init.d/dropbear
lrwxrwxrwx    1 root     root            13 Sep  5 10:05 S50qos -> ../init.d/qos
lrwxrwxrwx    1 root     root            16 Feb  2  2016 S50telnet -> ../init.d/telnet
lrwxrwxrwx    1 root     root            16 Feb  2  2016 S50uhttpd -> ../init.d/uhttpd
lrwxrwxrwx    1 root     root            17 Feb  2  2016 S60dnsmasq -> ../init.d/dnsmasq
lrwxrwxrwx    1 root     root            14 Feb  2  2016 S95done -> ../init.d/done
lrwxrwxrwx    1 root     root            13 Feb  2  2016 S96led -> ../init.d/led
lrwxrwxrwx    1 root     root            17 Sep  5 10:15 S98sysntpd -> ../init.d/sysntpd

Like maybe qos should be started after some other daemons. I know it's highly unlikely, since only daemons started after qos are uhttpd and dnsmasq.

Anyway my workaround is to restart qos service on boot (in rc.local).

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.