What's new

FlexQoS FlexQoS 1.3.2 - Flexible QoS Enhancement Script for Adaptive QoS

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
Edit: Going off-topic here (even further), @SomeWhereOverTheRainBow I'm trying your DNSCrypt build on the AX86 soon, if you remember our multi-page endeavour with the AX58U :)
Well, you mean you will be installing dnscrypt-proxy. And that you hope the binaries works properly for your model router. I hope it does atleast, but I have no control over the binaries development since I am not officially apart of the dnscrypt-proxy development team. I do however maintain an installer that grants you access to using said binaries on you asuswrt-merlin router.

Let us now bring this thread back to topic for those users who wish to talk about FlexQoS usage specifically.
 
Last edited:
Tested the latest version, as always everything is perfect, great job Dave!
I am also concerned about the direction asus is taking.:confused:
 
Okay one last push before I head to sleep.

Procedure:
  1. Withdraw from trend micro
  2. Reboot
  3. Turn on Adaptive Qos

No more misclassified direct packet stats anymore!!!


qdisc htb 1: dev eth0 root refcnt 2 r2q 10 default 0 direct_packets_stat 15
qdisc htb 10: dev eth0 parent 1:10 r2q 10 default 256 direct_packets_stat 0
qdisc htb 11: dev eth0 parent 1:11 r2q 10 default 256 direct_packets_stat 0
qdisc htb 12: dev eth0 parent 1:12 r2q 10 default 256 direct_packets_stat 0
qdisc htb 13: dev eth0 parent 1:13 r2q 10 default 256 direct_packets_stat 0
qdisc htb 14: dev eth0 parent 1:14 r2q 10 default 256 direct_packets_stat 0
qdisc htb 15: dev eth0 parent 1:15 r2q 10 default 256 direct_packets_stat 0
qdisc htb 16: dev eth0 parent 1:16 r2q 10 default 256 direct_packets_stat 0
qdisc htb 17: dev eth0 parent 1:17 r2q 10 default 256 direct_packets_stat 0
qdisc htb 1: dev br0 root refcnt 2 r2q 10 default 0 direct_packets_stat 0
qdisc htb 10: dev br0 parent 1:10 r2q 10 default 256 direct_packets_stat 0
qdisc htb 11: dev br0 parent 1:11 r2q 10 default 256 direct_packets_stat 0
qdisc htb 12: dev br0 parent 1:12 r2q 10 default 256 direct_packets_stat 0
qdisc htb 13: dev br0 parent 1:13 r2q 10 default 256 direct_packets_stat 0
qdisc htb 14: dev br0 parent 1:14 r2q 10 default 256 direct_packets_stat 0
qdisc htb 15: dev br0 parent 1:15 r2q 10 default 256 direct_packets_stat 0
qdisc htb 16: dev br0 parent 1:16 r2q 10 default 256 direct_packets_stat 0
qdisc htb 17: dev br0 parent 1:17 r2q 10 default 256 direct_packets_stat 0

Adaptive QoS without flexqos is working fine as of now. It's just terrible at Net Control Packets thats all.

I am scared to turn on FlexQos.. Will edit this post once I do and see what the direct packets stat say...
Most likely something has gone broken in the firmware (which included the recent firmware for the RT-AC3100). If you have time, you can test this theory by going backwards to an older firmware version. I am only mentioning this because IIRC, there were some concerns about the most recent batch for the RTAC3100.
 
Most likely something has gone broken in the firmware (which included the recent firmware for the RT-AC3100). If you have time, you can test this theory by going backwards to an older firmware version. I am only mentioning this because IIRC, there were some concerns about the most recent batch for the RTAC3100.
Will try it hopefully on the weekend.
 
Will try it hopefully on the weekend.
Tried it already.


ASUS Firmware upstream is broken.
Not an issue with Merlin or FlexQoS.

Putting this direct_packets_stat to rest.

@dave14305 Thank you! FlexQoS is working great after the catchall filter added to firewall_start. Maybe you could add something like that catchall for upload and download direction with default priority 14(middle of all) to enhance whatever ASUS broke for all other users?
 
Tried it already.


ASUS Firmware upstream is broken.
Not an issue with Merlin or FlexQoS.

Putting this direct_packets_stat to rest.

@dave14305 Thank you! FlexQoS is working great after the catchall filter added to firewall_start. Maybe you could add something like that catchall for upload and download direction with default priority 14(middle of all) to enhance whatever ASUS broke for all other users?
So with the catchall in place, please post a screenshot of your upload graph from FlexQoS. Is all the traffic always in the catchall class?
 
So with the catchall in place, please post a screenshot of your upload graph from FlexQoS. Is all the traffic always in the catchall class?
1663791984598.png


There is traffic in all categories. From my experience the catchall allowed FlexQoS to capture all upload traffic. Most of my upload traffic was going untracked before this catchall but now it is in the web surfing (1:14).
 
There is traffic in all categories. From my experience the catchall allowed FlexQoS to capture all upload traffic. Most of my upload traffic was going untracked before this catchall but now it is in the web surfing (1:14).
Can someone give me a text file output of this command:

Code:
tc filter show dev eth0

I have added the log option in forward chain and here is the output. dave14305 any suggestions?
Sep 21 21:33:39 kernel: IN=br0 OUT=eth0 SRC=192.168.1.36 DST=40.83.247.108 LEN=84 TOS=0x00 PREC=0x00 TTL=127 ID=44679 DF PROTO=TCP SPT=54933 DPT=443 WINDOW=512 RES=0x00 ACK PSH URGP=0 MARK=0x83440084
Sep 21 21:33:39 kernel: IN=br0 OUT=eth0 SRC=192.168.1.36 DST=40.83.247.108 LEN=40 TOS=0x00 PREC=0x00 TTL=127 ID=44680 DF PROTO=TCP SPT=54933 DPT=443 WINDOW=512 RES=0x00 ACK URGP=0 MARK=0x83440084
Sep 21 21:33:44 kernel: IN=br0 OUT=eth0 SRC=192.168.1.253 DST=107.125.50.51 LEN=448 TOS=0x00 PREC=0x00 TTL=253 ID=15413 DF PROTO=UDP SPT=43255 DPT=4500 LEN=428 MARK=0x83440084
Sep 21 21:33:45 kernel: IN=br0 OUT=eth0 SRC=192.168.1.253 DST=107.125.50.51 LEN=112 TOS=0x00 PREC=0x00 TTL=253 ID=15414 DF PROTO=UDP SPT=43255 DPT=4500 LEN=92 MARK=0x83440084
Sep 21 21:33:47 kernel: IN=br0 OUT=eth0 SRC=192.168.1.253 DST=107.125.50.51 LEN=288 TOS=0x00 PREC=0x00 TTL=253 ID=15415 DF PROTO=UDP SPT=43255 DPT=4500 LEN=268
Sep 21 21:33:47 kernel: IN=br0 OUT=eth0 SRC=192.168.1.253 DST=107.125.50.51 LEN=112 TOS=0x00 PREC=0x00 TTL=253 ID=15416 DF PROTO=UDP SPT=43255 DPT=4500 LEN=92
Sep 21 21:33:49 kernel: IN=br0 OUT=eth0 SRC=192.168.1.36 DST=185.199.110.154 LEN=41 TOS=0x00 PREC=0x00 TTL=127 ID=9670 DF PROTO=TCP SPT=60098 DPT=443 WINDOW=512 RES=0x00 ACK URGP=0 MARK=0x83440084
Sep 21 21:33:51 kernel: IN=br0 OUT=eth0 SRC=192.168.1.253 DST=107.125.50.51 LEN=29 TOS=0x00 PREC=0x00 TTL=63 ID=0 PROTO=UDP SPT=43255 DPT=4500 LEN=9 MARK=0x83440084
 
Last edited:
Can someone give me a text file output of this command:
I have added the log option in forward chain and here is the output. dave14305 any suggestions?
I wouldn’t expect marks with the leading 8 on upload. What iptables command did you to capture these? I can’t recreate it yet on my router.
 

I wouldn’t expect marks with the leading 8 on upload. What iptables command did you to capture these? I can’t recreate it yet on my router.
Here is the command:
Code:
iptables -t mangle -A FORWARD -i eth0 --src 192.168.1.0/24 -m mark ! --mark 0x40000000/0xc0000000 -j LOG --log-ip-options

You can see I have upload mark tagged on these packets and some unmarked packets too. Same issue with IPv6.

When I add any ip6tables rules in mangle table my download is limited to the upload QoS speed. Every other speed test returns the lower upload as download number.

Code:
iptables -t mangle -A FORWARD -o $(nvram get wan0_gw_ifname) --src 192.168.1.0/24 ! --dst 192.168.1.0/24 -m mark --mark 0x80000000/0xc0000000 -j MARK --set-xmark 0x40000000/0xC0000000
ip6tables -t mangle -A POSTROUTING -o $(nvram get wan0_gw_ifname) -m mark --mark 0x80000000/0xc0000000 -j MARK --set-xmark 0x40000000/0xC0000000
 
Here is the command:
Code:
iptables -t mangle -A FORWARD -i eth0 --src 192.168.1.0/24 -m mark ! --mark 0x40000000/0xc0000000 -j LOG --log-ip-options

You can see I have upload mark tagged on these packets and some unmarked packets too. Same issue with IPv6.

When I add any ip6tables rules in mangle table my download is limited to the upload QoS speed. Every other speed test returns the lower upload as download number.

Code:
iptables -t mangle -A FORWARD -o $(nvram get wan0_gw_ifname) --src 192.168.1.0/24 ! --dst 192.168.1.0/24 -m mark --mark 0x80000000/0xc0000000 -j MARK --set-xmark 0x40000000/0xC0000000
ip6tables -t mangle -A POSTROUTING -o $(nvram get wan0_gw_ifname) -m mark --mark 0x80000000/0xc0000000 -j MARK --set-xmark 0x40000000/0xC0000000

These are the results about swapped upload and download:
1663866896968.png


These are the commands on the iptables.

Code:
iptables -t mangle -A FORWARD -o $(nvram get wan0_gw_ifname) --src 192.168.1.0/24 ! --dst 192.168.1.0/24 -m mark --mark 0x80000000/0xc0000000 -j MARK --set-xmark 0x40000000/0xC0000000
ip6tables -t mangle -A FORWARD -o $(nvram get wan0_gw_ifname) -m mark --mark 0x80000000/0xc0000000 -j MARK --set-xmark 0x40000000/0xC0000000
 
Wow, even Steam limited to 40 MBit creates packetloss in TS3 Inbound; about 1% and holds there. Is something really wrong with the RT-AX86U?

To be clear: QoS is off. Steam seems to open a huge amount of connections that it just can't cope with. Weird that it worked with the AX58U.
 
Wow, even Steam limited to 40 MBit creates packetloss in TS3 Inbound; about 1% and holds there. Is something really wrong with the RT-AX86U?

To be clear: QoS is off. Steam seems to open a huge amount of connections that it just can't cope with. Weird that it worked with the AX58U.
There must be more going on - maybe a combination of what your provider does and the router:

I am using the same router and Steam and don't see the problem you are seeing. When I had Gig Fiber I had zero packetloss no matter what I did (Steam, Backblaze etc...) - with 200/200mpbs Fiber I get packetloss when I max out the downstream - likely part of my provider (quantum) traffic shaping... With FlexQoS and fc disable that problem goes away and everything is 100% stable with ping increases <10ms on a fully loaded link...
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top