RT-AC68U Traditional QoS UL/DL limit values are broken?

[Mr Solis]

I've recently dirty flashed 386.5 over 386.4 and noticed my download speed had deteriorated (~102mbps reduced to ~18mbps via Ookla) but the built in WebUI Internet Speed test is giving me expected results (102mbps/19mbps). I have Traditional QoS enabled with CTF disabled and this was previously working as intended but it seems to have broken with 386.5.

Thinking it was an issue with incompatible configurations between firmware revisions, I flashed 386.5_2 over 386.5 and performed a hard reset (reset button and again with WPS button) but am still experiencing the same issues. Everything else is working fine.

I've noticed that my download speed and upload speed are the same since 386.5. The issue seems to be related to the upload limit under Traditional QoS because when I increase its value, my download speeds increase accordingly.

Is anybody else experiencing this issue or is able to shed some light on a solution?

Cheers!

QoS configuration:

386.5_2 Traditional QoS enabled:

386.5_2 QoS disabled:

 

[ColinTaylor]

There were numerous changes to traditional QoS in 386.5. Sounds like one of them broke something. @RMerlin?

rc: tQoS fixes from upstream · RMerl/asuswrt-merlin.ng@0bc048f

Third party firmware for Asus routers (newer codebase) - rc: tQoS fixes from upstream · RMerl/asuswrt-merlin.ng@0bc048f

github.com

Merge pull request #800 from kjbracey/tqos-fixes · RMerl/asuswrt-merlin.ng@773782d

rc: Assorted TQoS fixes

github.com

 

[dave14305]

I’m always a sucker for a QoS mystery. What’s the output of:

/tmp/qos status
cat /tmp/qos
iptables -t mangle -nvL
ip6tables -t mangle -nvL

 

[Mr Solis]

I’m always a sucker for a QoS mystery. What’s the output of:

/tmp/qos status
cat /tmp/qos
iptables -t mangle -nvL
ip6tables -t mangle -nvL

Here you go!

 

[dave14305]

Here you go!

I couldn’t reproduce this issue on an AC68U running 386.5_2 with 102/19 bandwidth and 19 overhead.

Was this a wired or wireless test? Was the client used one of the MAC addresses in the QoS rules?

 

[Mr Solis]

I couldn’t reproduce this issue on an AC68U running 386.5_2 with 102/19 bandwidth and 19 overhead.

Was this a wired or wireless test? Was the client used one of the MAC addresses in the QoS rules?

I actually hadn't tried the wireless devices as I assumed they'd exhibit the same issue but it seems they don't.

Wired w/ QoS rule: speed issue
Wired w/o QoS rule: speed issue

Wireless w/ QoS rule: no issue
Wireless w/o QoS rule: no issue

So it seems the wired connections are affected when QoS is enabled, regardless of their inclusion in the QoS rules.

CLI output

I should also mention that disabling QoS altogether doesn't exhibit any issues (other than buffer bloat!)

 

[Wade Coxon]

I've noticed that my download speed and upload speed are the same since 386.5. The issue seems to be related to the upload limit under Traditional QoS because when I increase its value, my download speeds increase accordingly.

Have you checked to see if the U/L and D/L fields haven't simply been flipped around?

What happens if you set the QoS D/L limit to something like 10Mbps? Does your tested U/L speed correspondingly drop to 10Mbps?

 

[dave14305]

Have you checked to see if the U/L and D/L fields haven't simply been flipped around?

No, it's correct in the screenshot in post #1, and in the underlying tc configuration.

 

[Mr Solis]

Have you checked to see if the U/L and D/L fields haven't simply been flipped around?

What happens if you set the QoS D/L limit to something like 10Mbps? Does your tested U/L speed correspondingly drop to 10Mbps?

I thought I'd test it anyway and it seems it's using the U/L value for both only if the U/L < D/L


i.e.

UL:5 & DL:10 would give me 5mbps for both U/L and D/L.

UL:10 & DL:5 would give me 10mbps U/L and 5mbps D/L


The plot thickens.

 

[Wade Coxon]

No, it's correct in the screenshot in post #1, and in the underlying tc configuration.

I didn't mean to suggest that he had entered them incorrectly, rather the firmware was applying them the wrong way around for some reason.

However, given their reply, the plot does indeed thicken.

 

[RMerlin]

Are you using a VPN? It can mess up with QoS.

 

[Mr Solis]

Are you using a VPN? It can mess up with QoS.

I use the built-in OpenVPN.

I just tried disabling OpenVPN and enabling Traditional QoS but its still exhibiting the same issue unfortunately.

 

[dave14305]

I use the built-in OpenVPN.

I just tried disabling OpenVPN and enabling Traditional QoS but its still exhibiting the same issue unfortunately.

I've reproduced this issue with a wired LAN connection. I'll see if I can understand what's happening later tonight.

 

[dave14305]

All the download traffic is definitely being seen by the eth0 qdisc. Since it only affects wired devices, I’m speculating that it’s a vlan1 issue, but my vlan-foo is very very feeble. Wireless interfaces are in the bridge and unaffected. This is why I assume it’s the physical ports in vlan1.

Maybe @ColinTaylor can brainstorm some ideas with us. He knows everything.

A speedtest using 20MB of data in each direction shows 20MB sent on br0 and 40MB sent on eth0 (20 down, 20 up).

 

[dave14305]

Downgrading to 386.4 restores normal download behavior. Just need to figure out if it was the GPL or the tQoS changes now. I'll try to transfer the /tmp/qos and iptables mangle rules from 386.4 to 386.5_2 as a test.

Edit: using 386.4 /tmp/qos on 386.5_2 also restores expected download throughput. So there is some regression in @KMO changes. More analysis required.

 

[RMerlin]

Downgrading to 386.4 restores normal download behavior. Just need to figure out if it was the GPL or the tQoS changes now. I'll try to transfer the /tmp/qos and iptables mangle rules from 386.4 to 386.5_2 as a test.

View attachment 40637

Edit: using 386.4 /tmp/qos on 386.5_2 also restores expected download throughput. So there is some regression in @KMO changes. More analysis required.

Unlikely to be tied to a GPL merge itself, most likely either from the changes I merged from kjbracey, or the supplemental changes Asus provided me following me forwarding them these changes for review.

I'll let you look at it, since you are more familiar than me with tc. Plus I got my hands full at the moment as last night's long list of commits to github indicate (that`s also why I haven`t had time to review any of your current PR, sorry).

 

[dave14305]

Unlikely to be tied to a GPL merge itself, most likely either from the changes I merged from kjbracey, or the supplemental changes Asus provided me following me forwarding them these changes for review.

I'll let you look at it, since you are more familiar than me with tc. Plus I got my hands full at the moment as last night's long list of commits to github indicate (that`s also why I haven`t had time to review any of your current PR, sorry).

Yes, seems like the Asus change is to blame in the upload tc filter for 802.1q.

rc: tQoS fixes from upstream · RMerl/asuswrt-merlin.ng@0bc048f

Third party firmware for Asus routers (newer codebase) - rc: tQoS fixes from upstream · RMerl/asuswrt-merlin.ng@0bc048f

github.com

Going back to u32 match u32 0 0 flowid 1:60 fixes the download traffic. Haven’t figured out if the rest of the commit is good or bad yet.

 

[RMerlin]

Between the original fixes from a few years ago from a contributor, KMO's own fixes and Asus's own fixes (all mixed with my own changes to add overhead and fq_codel support), the current state of qos.c might be of a mess. It might need a thorough cleanup, and deciding whether to stick to upstream code, or stick to contributed code - but not both.

I even considered at one point scrapping the whole t.QoS implementation, and re-importing the original QoS code from Toastman, since that one is known to work very well (I have a VoIP customer for whom I run Tomato on an RT-N66U because Asuswrt's QoS simply didn't work). That might introduce other issues however...

A starting point would probably be to look at the code with KMO's original PRs without any of the following Asus or GPL changes, and see if that runs properly as a basepoint. If it does, then consider this as being "forked away from Asus" (like my OpenVPN code) and no longer merge subsequent changes by Asus unless they make clear sense in our context.

 

[dave14305]

For @Mr Solis you can try this workaround until a fix is made:

Create this script with nano /jffs/scripts/qos-start

#!/bin/sh

. /usr/sbin/helper.sh

if [ "$1" = "init" ]; then
        pc_replace " mark 6 0x3f " " u32 0 0 " /tmp/qos
fi

Then run:

chmod 755 /jffs/scripts/qos-start
service "restart_qos;restart_firewall"

 

[dave14305]

What we saw happening was exactly one of the issues Cedric was trying to solve 4 years ago. But Asus reverted his change.

(RT-AC88U) Traditional QoS fully fixed (I believe)

EDITED: applies to 384.4.beta1 Looking closely at the output of the various tc -s ... commands when downloading/uploading files, I have discovered that the ingress (ffff:) qdisc on the eth0 interface behaves very strangely: downloaded/ingress traffic DOES appear on the ingress (ffff:) qdisc...

www.snbforums.com