FlexQoS FlexQoS 1.3.2 - Flexible QoS Enhancement Script for Adaptive QoS

[dave14305]

Does anyone have any ideas for debugging this?

Keep lowering your QoS bandwidth rates until you stop seeing packet loss. Whatever number you settle on is likely the maximum traffic shaping capability of your router.

I was under the impression the AX86U would be fast enough to handle Adaptive QoS fq_codel with FlexQoS on GBit cable. Is this not the case?

There have been many oddities reported with the AX86U, which is why many owners choose to disable flow cache.

 

[panni]

Keep lowering your QoS bandwidth rates until you stop seeing packet loss. Whatever number you settle on is likely the maximum traffic shaping capability of your router.

There have been many oddities reported with the AX86U, which is why many owners choose to disable flow cache.

Oh, I wasn't aware of that. That's too bad.

I can still return this one - is there a modern ASUS router that can handle full speed QoS on 1 GBit? Thank you!

 

[Kingp1n]

I am back on FlexQoS - downgraded my Fiber from gig to 200/200 (cost is less than half) and was having jitter and VoIP problems when Steam updates and Backups kicked in...

For Routers like the RT-AX86 don't forget to set

fc disable

otherwise FlexQoS does not work correctly.... I had mentioned that in an earlier post but had brain freeze and totally forgot about it... No added back in

/jffs/scripts/firewall-start

so it survives reboots...

Thanks again - FlexQoS makes the router so much better for me!!!

Does anyone know if this issue happens with the latest stock firmware as well? Is there a way I can easily check if this issue (with FC enabled) is affecting my AX router?

Can I simply try downloading something thru my Xbox and check the graphs/traffic inside the FlexQoS tab? What should I be looking for?

 

[dave14305]

Does anyone know if this issue happens with the latest stock firmware as well? Is there a way I can easily check if this issue (with FC enabled) is affecting my AX router?

Can I simply try downloading something thru my Xbox and check the graphs/traffic inside the FlexQoS tab? What should I be looking for?

The obvious symptom was traffic modified by a FlexQoS iptables rule was not showing up in the expected class in the graphs, or nowhere near the expected rate. You wouldn’t have either of those on stock firmware.

 

[dave14305]

Oh, I wasn't aware of that. That's too bad.

I can still return this one - is there a modern ASUS router that can handle full speed QoS on 1 GBit? Thank you!

See this discussion.

Router that can do full-speed Gigabit qos?

I have a highly asymmetrical comcast plan that runs at about 920 down and 25 up. I need QoS to manage my upstream bandwidth since I work from home (and have several other home PCs doing things like online backups, cloud uploads, etc.), and I'd like to use QoS to prioritize my work PC...

www.snbforums.com

 

[panni]

See this discussion.

Router that can do full-speed Gigabit qos?

I have a highly asymmetrical comcast plan that runs at about 920 down and 25 up. I need QoS to manage my upstream bandwidth since I work from home (and have several other home PCs doing things like online backups, cloud uploads, etc.), and I'd like to use QoS to prioritize my work PC...

www.snbforums.com

Interesting. So no matter what I buy (apart from _maybe_ the GT-AX6000), Adaptive QoS at nearly full speed is still a no go for GBit connections on home routers?

That's a little sad, router manufacturers. Anyways, with the 1000/50 uplink I have, I don't really need QoS to be honest, but I always loved the approach FlexQoS had and it worked so well on my AX58U (with 500/50, though).

I guess I'll wait another couple of years, then.

Thanks!

 

[asusrunshot]

That would probably be DNS traffic from the router. It won’t show up under Tracked Connections. Watch the counters with:

iptables -t mangle -nvL OUTPUT

I spoke too soon....

The direct_packet_stats still keeps increasing after the catchall filter is implemented.

 

[dave14305]

I spoke too soon....

The direct_packet_stats still keeps increasing after the catchall filter is implemented.

Does it have any successes?

tc -s filter show dev eth0 prio 99

 

[asusrunshot]

Does it have any successes?

tc -s filter show dev eth0 prio 99

Nope. Output is empty.

filter parent 1: protocol all pref 99 u32
filter parent 1: protocol all pref 99 u32 fh 829: ht divisor 1
filter parent 1: protocol all pref 99 u32 fh 829::800 order 2048 key ht 829 bkt 0 flowid 1:14  (rule hit 0 success 0)

 

[dave14305]

Nope. Output is empty.

Oh, so your catchall filter got wiped at some point.

 

[asusrunshot]

Oh, so your catchall filter got wiped at some point.

Spot on!

Did it again and now I have output.

filter parent 1: protocol all u32
filter parent 1: protocol all u32 fh 829: ht divisor 1
filter parent 1: protocol all u32 fh 829::800 order 2048 key ht 829 bkt 0 flowid 1:17  (rule hit 23 success 23)
  match 00000000/00000000 at 0 (success 23 )

Does this catchall filter mean that whatever was not hit in filters before is going to hit here and get classified with lowest priority? Or does this override the Adaptive QoS filter buckets?

I have many other filters on eth0 where (rule hit XXXX success 0). More filter with success 0 than with success a positive number. Is that normal?

 

[dave14305]

Does this catchall filter mean that whatever was not hit in filters before is going to hit here and get classified with lowest priority? Or does this override the Adaptive QoS filter buckets?

This rule is evaluated last (prio 99) and it will only hit if nothing matches above it. Priority is “lowest” only because you chose 17.

I have many other filters on eth0 where (rule hit XXXX success 0). More filter with success 0 than with success a positive number. Is that normal?

The hit count is whether the rule was evaluated. The success is if it matched. Many of them from prio 30 and higher will be 0 and 0, at least in my case.

Try adding this iptables rule temporarily to see if there is any clue to which traffic is missing the filters.

iptables -t mangle -A POSTROUTING -o eth0 -m mark ! --mark 0x40000000/0xc0000000 -j LOG --log-ip-options

The watch the system log. You can delete the rule with:

iptables -t mangle -D POSTROUTING -o eth0 -m mark ! --mark 0x40000000/0xc0000000 -j LOG --log-ip-options

The only traffic I see logged on my router with this rule is ICMP traffic from dnsmasq to my 2 WAN DNS servers.

 

[asusrunshot]

This rule is evaluated last (prio 99) and it will only hit if nothing matches above it. Priority is “lowest” only because you chose 17.

The hit count is whether the rule was evaluated. The success is if it matched. Many of them from prio 30 and higher will be 0 and 0, at least in my case.

Try adding this iptables rule temporarily to see if there is any clue to which traffic is missing the filters.

iptables -t mangle -A POSTROUTING -o eth0 -m mark ! --mark 0x40000000/0xc0000000 -j LOG --log-ip-options

The watch the system log. You can delete the rule with:

iptables -t mangle -D POSTROUTING -o eth0 -m mark ! --mark 0x40000000/0xc0000000 -j LOG --log-ip-options

That is very helpful!

I have hundreds of these ICMP and ICMPv6 in log now

Sep 20 11:41:32 kernel: IN= OUT=eth0 SRC=2001:::fb0e DST=2607:f8b0:4005:0812:0000:0000:0000:200a LEN=249 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=ICMPv6 TYPE=1 CODE=3 [SRC=2607:f8b0:4005:0812:0000:0000:0000:200a DST=2601:::f937 LEN=201 TC=32 HOPLIMIT=57 FLOWLBL=605691 PROTO=TCP SPT=443 DPT=60660 WINDOW=279 RES=0x00 ACK PSH FIN URGP=0 ]
Sep 20 11:41:32 kernel: IN= OUT=eth0 SRC=2001:::fb0e DST=2607:f8b0:4005:0813:0000:0000:0000:200a LEN=249 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=ICMPv6 TYPE=1 CODE=3 [SRC=2607:f8b0:4005:0813:0000:0000:0000:200a DST=2601:::f937 LEN=201 TC=32 HOPLIMIT=57 FLOWLBL=699139 PROTO=TCP SPT=443 DPT=47150 WINDOW=262 RES=0x00 ACK PSH FIN URGP=0 ]
Sep 20 11:41:38 kernel: IN= OUT=eth0 SRC=xx.xx.xx.xx DST=142.250.188.14 LEN=80 TOS=0x00 PREC=0xC0 TTL=64 ID=17952 PROTO=ICMP TYPE=3 CODE=1 [SRC=142.250.188.14 DST=192.168.1.22 LEN=52 TOS=0x00 PREC=0x20 TTL=57 ID=15734 PROTO=TCP SPT=443 DPT=57306 WINDOW=265 RES=0x00 ACK FIN URGP=0 ]
Sep 20 11:41:38 kernel: IN= OUT=eth0 SRC=xx.xx.xx.xx DST=44.202.21.19 LEN=143 TOS=0x00 PREC=0xC0 TTL=64 ID=4461 PROTO=ICMP TYPE=3 CODE=1 [SRC=44.202.21.19 DST=192.168.1.22 LEN=115 TOS=0x00 PREC=0x20 TTL=32 ID=44130 DF PROTO=TCP SPT=443 DPT=52192 WINDOW=133 RES=0x00 ACK PSH FIN URGP=0 ]
Sep 20 11:41:45 kernel: IN= OUT=eth0 SRC=xx.xx.xx.xx DST=142.250.188.14 LEN=80 TOS=0x00 PREC=0xC0 TTL=64 ID=17953 PROTO=ICMP TYPE=3 CODE=1 [SRC=142.250.188.14 DST=192.168.1.22 LEN=52 TOS=0x00 PREC=0x20 TTL=121 ID=15735 PROTO=TCP SPT=443 DPT=57306 WINDOW=265 RES=0x00 ACK FIN URGP=0 ]

The IP addresses are my laptop and pixel 6.

So ICMP is not being classified correctly and is going to the FIFO (default) queue of htb parent 1?


Alright just to be sure this is the procedure I performed and I am still getting the packets that go straight to FIFO.

1. Install new FW
2. Reset everything
3. Make a new Wifi SSID and Password so none of the old devices connect automatically
4. Only use my laptop

With 1 device connected I am still at 1000+ packets which sneaked past QoS and went straight to direct packets.

The system log is empty even after adding the log options.

 

[dave14305]

So ICMP is not being classified correctly and is going to the FIFO (default) queue of htb parent 1?

I don’t see it happening on my router. I get the log messages for icmp, but no increase in direct_packets_stat, so it’s hard to say what is really happening.

 

[asusrunshot]

I don’t see it happening on my router. I get the log messages for icmp, but no increase in direct_packets_stat, so it’s hard to say what is really happening.

I tried the manual QoS and it worked perfectly! direct_packets_stat was not increasing once the QoS was active.

I tried Adaptive QoS without FlexQoS and the direct_packets_stat kept increasing.

I tried Adaptive QoS with FlexQoS and the direct_packets_stat kept increasing.

I am going to conclude that that the issue lies with Trend Micro engine and ASUS AC3100. For some reason the TM engine isn't classifying upload correctly no matter what I do.

To circumvent this problem for now I have added this code at the end of firewall_start in /jffs/scripts

tc filter add dev eth0 protocol all prio 99 u32 match u32 0 0 flowid 1:14

I'd be happy to perform any tests with developmental code/commands that others may have to solve this problem at the root instead of using catchall as a workaround.

Thank you dave14305 for all your help so far! You rock!! (y)

 

[dave14305]

For some reason the TM engine isn't classifying upload correctly no matter what I do.

Does the FlexQoS GUI Upload stats show believable counters?

 

[BreakingDad]

Does the FlexQoS GUI Upload stats show believable counters?

Been testing the new update for 5 days, not one spike. Impressive with my kids online.

 

[asusrunshot]

Does the FlexQoS GUI Upload stats show believable counters?

Without the catchall filter graph does not show believable rates.

With the catchall filter the graph has believable upload.

I may have found another bug. When I upload the speed is actually listed in the download graph of bandwidth.

 

[dave14305]

Without the catchall filter graph does not show believable rates.

With the catchall filter the graph has believable upload.

I may have found another bug. When I upload the speed is actually listed in the download graph of bandwidth.
View attachment 44325

This is reminiscent of the VPN download as upload issues of the past.

Try a new iptables rule without the catch all.

iptables -t mangle -A POSTROUTING -o eth0 -m mark --mark 0x80000000/0xc0000000 -j MARK --set-xmark 0x40000000/0xC0000000

 

[asusrunshot]

This is reminiscent of the VPN download as upload issues of the past.

Try a new iptables rule without the catch all.

iptables -t mangle -A POSTROUTING -o eth0 -m mark --mark 0x80000000/0xc0000000 -j MARK --set-xmark 0x40000000/0xC0000000

I have no VPN in the entire house. I have 3 Google home minis that are setup with some wifi LED bulbs.

The only IPSEC VPN I can think of is my ATT cell phone wifi calling.

Anyhow, that command did not the upload/download mischaracterization in the QoS bandwidth monitor. After reboot the problem is back.

However, without the catchall direct_packets_stat keep on rising indefinitely.