ASUS firmware qos not working

[Ogmax]

Just wondering if there’s any information or fix as to why my firmware qos doesn’t seem to work correctly. The percentages of highest high low or lowest don’t seem to match up with what I select my devices to.

 

[L&LD]

Welcome to the forums @Ogmax.

Which router? Which firmware? Was a full reset ever performed after flashing the latest firmware? What firmware did you upgrade the latest firmware, from?

Can you give a better description of what the issue is? Your last sentence isn't making sense (to me).

 

[Ogmax]

I’m using the ax86u with the merlin 386.3.2. And yeah have done a reset after I set it all up. I updated from the latest standard ASUS firmware.

And yes sorry it’s quite difficult to describe but il give it a go, I’m using the traditional qos mode and when I set devices on “highest” priority it seems that it runs of the percentage that I set for the “lowest” priority, and from what I can see all devices end up speed testing with the same download speed to matter what I change.

Sorry if this is hard to understand it’s fairly difficult to explain, however I have noticed on YouTube and tiger forums that this has been an issue before and for a while.

 

[L&LD]

Are you talking about the RT-AX86U? I don't believe Tradition QoS has worked in a very long time?

Are you certain that you are inputting the up/down speeds correctly? What are your ISP speeds?

 

[Ogmax]

Are you talking about the RT-AX86U? I don't believe Tradition QoS has worked in a very long time?

Are you certain that you are inputting the up/down speeds correctly? What are your ISP speeds?

Yes that’s the one. And oh really and yeah I’m definitely putting the fight speeds in, what qos is recommended, I tried adaptive and that didn’t seem to work well at all.

 

[slidermike]

L&LD is correct, traditional QoS is broke and has been for a long time. Not likely to be fixed either. At least in the near term.

Adaptive QoS should work but it needs more user intervention to get the desired results.
Check out Flex QoS for Adaptive QoS.

FlexQoS - FlexQoS 1.3.2 - Flexible QoS Enhancement Script for Adaptive QoS

FlexQoS Version 1.3.2 - Released 16-Sep-2022 This is just a minor release with an iptables optimization. Nothing exciting or outwardly visible has changed. CHANGED: Split iptables rules into separate upload and download chains to avoid unnecessary rule traversal CHANGED: Tweaked 'debug'...

www.snbforums.com

You could also attempt to use Cake QoS which I believe is experimental state.
It is cpu bound so do not use it for any high speed WAN.

CakeQOS - CakeQoS-Merlin v2.1.1

**** DEVELOP Branch update to v.2.2.1 *** See: http://www.snbforums.com/threads/cakeqos-merlin-v2-1-0.74309/post-717254 Thanks for @dave14305 for this update to the Develop branch. Feedback appreciated. Continue reading for PROD v2.1.1 I am happy to announce CakeQOS v2.1.1 is released. Key...

www.snbforums.com

 

[rlj2]

Alot of us have to disable Flow cache to get the AX86u to behave correctly with qos. This could limit your speed to less then 300Mbit/sec

 

[rlj2]

L&LD is correct, traditional QoS is broke and has been for a long time. Not likely to be fixed either. At least in the near term.

Adaptive QoS should work but it needs more user intervention to get the desired results.
Check out Flex QoS for Adaptive QoS.

FlexQoS - FlexQoS 1.3.2 - Flexible QoS Enhancement Script for Adaptive QoS

FlexQoS Version 1.3.2 - Released 16-Sep-2022 This is just a minor release with an iptables optimization. Nothing exciting or outwardly visible has changed. CHANGED: Split iptables rules into separate upload and download chains to avoid unnecessary rule traversal CHANGED: Tweaked 'debug'...

www.snbforums.com

You could also attempt to use Cake QoS which I believe is experimental state.
It is cpu bound so do not use it for any high speed WAN.

CakeQOS - CakeQoS-Merlin v2.1.1

**** DEVELOP Branch update to v.2.2.1 *** See: http://www.snbforums.com/threads/cakeqos-merlin-v2-1-0.74309/post-717254 Thanks for @dave14305 for this update to the Develop branch. Feedback appreciated. Continue reading for PROD v2.1.1 I am happy to announce CakeQOS v2.1.1 is released. Key...

www.snbforums.com

The AX86u definitely doesn't work with custom rules using flex without fc disabled. Anything using standard markings seem to be fine.

 

[KMO]

I've been digging into the traditional QoS code for my RT-N66U, and I'm glad to see this thread saying:

L&LD is correct, traditional QoS is broke and has been for a long time. Not likely to be fixed either. At least in the near term.

I've independently concluded by inspection that it looks like it's broken for anything using kernel 2.6.36 onwards. (It seems to work okay on my RT-N66U with 2.6.22 on the LTS fork).

I've been pecking away at it here and here.

If I'm understanding it correctly, there's at least one fairly simple reason it's fundamentally flawed - kernel 2.6.22 had a hack to add a CONNMARK --set-return option that was used by add_qos_rules() with that kernel.

This was not ported fully to 2.6.36, so it didn't really work. And it wasn't ported at all to later kernels.

So add_qos_rules() instead uses a pair of CONNMARK --set-mark and RETURN rules as a substitute for CONNMARK --set-return with 2.6.36 or later (so all devices on Merlin's tree).

The problem is that this doesn't do the same thing. The --set-return actually did 3 things - it set the current packet mark, and the connection mark, and it returned.

The current substitute only sets the connection mark and returns, it doesn't mark the current packet.

Now, I think that previously you got away with this because the QOSO chain was run at least twice for each packet (from OUTPUT and POSTROUTING). Which meant on the second time through, it restored the connection mark to the current packet.

But these changes optimised the tables to avoid running QOSO multiple times. But that means that many/most output packets don't get marked any more. The rules update the connections, but not the packets.

But I guess at least subsequent packets should get marked? Maybe it's only the first packet on each connection that isn't marked? Every subsequent packet ends up using the mark restored from the previous packet's rules?

The bandwidth limiter rules, on the other hand, switched from CONNMARK --set-return to MARK --set-mark, so are only marking the current packet, but not the connection. But I think that's okay, because it's not using connection tracking at all?

Does anyone with a grasp of QoS want to comment on this analysis? I'm pretty new to the netfilter and iptables machinery, so may have misgrasped something fundamental! And the only box I have access to is the RT-N66U, so this is all inspection.

 

[L&LD]

@KMO, what are your ISP speeds? The RT-N66U has been out of support by Asus and RMerlin for many years now. @john9527's RMerlin fork still supports this model. What firmware are you running and basing your testing on?

[Fork] Asuswrt-Merlin 374 LTS Overview

ASUSWRT-MERLIN 374 LTS This is an LTS (Long Term Service) fork of Asuswrt-Merlin based on 374.43_2. This older code base has a history of being very stable, and some of the older code components may perform better in some environments. It may be a good choice for those who desire a 'set it and...

www.snbforums.com

 

[KMO]

I've not actually tested anything with the mainline code and newer routers (yet) - I've just been working on the QoS (with a 100/10Mbit ISP) on my old RT-N66U, with my own fixes to john's fork.

It's just I've been working through all the iptables+rc+kernel code to figure out why IPv6 QoS didn't work on N66U, so I'm offering input on the problems I've seen by inspecting the source code for newer models.

Reading the code for the newer models made me believe traditional QoS may well have problems on them (whereas it does seem to work on my RT-N66U). So I did a search for complaints about it not working and found this thread.

If anyone wants to fix it, some knowledge exchange may be productive.

I actually just picked up a RT-AX88U today - wasn't intending to, but it was on the shelf with €100 off and I couldn't resist. So I will be able to do some experimentation on it presently.

 

[KMO]

Right, having got the RT-AX88U up, it appears that the LTS fork has much closer to functioning TQoS than Merlin, particularly for IPv6.

IPv6 does not function at all in the Merlin code - all filters are "ip" only, and the ip6tables are not loaded.

The GUI does not show download stats, and I wonder if this is to cover up the fact that it's not working. It's a pretty easy fix to make those stats visible from imq0, and having done so, it's clear that none of the user rules work for download. All packets are either low (default) or highest (due to tc-based ACK etc rules).

First problem is that the connection marks are not being restored to the packets before they reach the imq0 device where shaping happens.

Second problem is that I think there are stray fwmark flags on incoming packets from the Trend Micro(?) stuff. We need to be looking at the bottom bits only.

The stock firmware that I tried very briefly before installing Merlin was using "u32 match mark" filters to look at a masked value, rather than "fw" filters, which look at the entire mark as the Merlin does. Changing over sorts that out.

Total manual fix is something like:

iptables -t mangle -I PREROUTING -j CONNMARK --restore --mask 7
tc filter del dev imq0 pref 10 fw
tc filter add dev imq0 parent 2: pref 10 u32 match mark 1 7 flowid 2:10
tc filter del dev imq0 pref 20 fw
tc filter add dev imq0 parent 2: pref 20 u32 match mark 2 7 flowid 2:20
tc filter del dev imq0 pref 30 fw
tc filter add dev imq0 parent 2: pref 20 u32 match mark 3 7 flowid 2:30
tc filter del dev imq0 pref 40 fw
tc filter add dev imq0 parent 2: pref 20 u32 match mark 4 7 flowid 2:40
tc filter del dev imq0 pref 50 fw
tc filter add dev imq0 parent 2: pref 20 u32 match mark 5 7 flowid 2:50
tc filter del dev imq0 pref 6 fw
tc filter add dev imq0 parent 2: pref 6 u32 match mark 6 7 flowid 2:60

 

[dave14305]

I've been digging into the traditional QoS code for my RT-N66U, and I'm glad to see this thread saying:

I've independently concluded by inspection that it looks like it's broken for anything using kernel 2.6.36 onwards. (It seems to work okay on my RT-N66U with 2.6.22 on the LTS fork).

I've been pecking away at it here and here.

If I'm understanding it correctly, there's at least one fairly simple reason it's fundamentally flawed - kernel 2.6.22 had a hack to add a CONNMARK --set-return option that was used by add_qos_rules() with that kernel.

This was not ported fully to 2.6.36, so it didn't really work. And it wasn't ported at all to later kernels.

So add_qos_rules() instead uses a pair of CONNMARK --set-mark and RETURN rules as a substitute for CONNMARK --set-return with 2.6.36 or later (so all devices on Merlin's tree).

The problem is that this doesn't do the same thing. The --set-return actually did 3 things - it set the current packet mark, and the connection mark, and it returned.

The current substitute only sets the connection mark and returns, it doesn't mark the current packet.

Now, I think that previously you got away with this because the QOSO chain was run at least twice for each packet (from OUTPUT and POSTROUTING). Which meant on the second time through, it restored the connection mark to the current packet.

But these changes optimised the tables to avoid running QOSO multiple times. But that means that many/most output packets don't get marked any more. The rules update the connections, but not the packets.

But I guess at least subsequent packets should get marked? Maybe it's only the first packet on each connection that isn't marked? Every subsequent packet ends up using the mark restored from the previous packet's rules?

The bandwidth limiter rules, on the other hand, switched from CONNMARK --set-return to MARK --set-mark, so are only marking the current packet, but not the connection. But I think that's okay, because it's not using connection tracking at all?

Does anyone with a grasp of QoS want to comment on this analysis? I'm pretty new to the netfilter and iptables machinery, so may have misgrasped something fundamental! And the only box I have access to is the RT-N66U, so this is all inspection.

This is a very interesting observation about the neglect of the nf marks versus ct marks. I suppose the ideal scenario would be for the QOSO chain to set the nf mark with -j MARK --set-mark 0x%s/0x17, then a final rule in POSTROUTING to -j CONNMARK --save-mark --mask 0x17.

 

[KMO]

This is a very interesting observation about the neglect of the nf marks versus ct marks. I suppose the ideal scenario would be for the QOSO chain to set the nf mark with -j MARK --set-mark 0x%s/0x17, then a final rule in POSTROUTING to -j CONNMARK --save-mark --mask 0x17.

I drafted a solution that used a set of 5 chain subroutines containing the mark and connmark like:

MEDIUM
MARK --setmark 0x3/0x17
CONNMARK --setmark 0x3/0x17

And then invoked the appropriate one in each QOSO rule using goto (not jump): -g MEDIUM.

That seemed to achieve the original intent of the set-return - having a single rule that did the packet+connection marks and returned from the QOSO chain, so you only had 1 iptable rule per qos entry in QOSO for the linear search.

But just having a save-mark in the appropriate places as you suggest is a smaller change to the upstream code.