FlexQoS FlexQoS 1.5.2 - Flexible QoS Enhancement Script for Adaptive QoS

[dave14305]

and OpenVPN download classification/accounting may be inaccurate.

Can you see the download bytes increasing on the 1:2 class on br0? They have to go somewhere, and I’m guessing they end up here because the firmware reporting ignores this class. And adding a new rule would probably not be a good idea.

 

[dave14305]

I wonder now if this VPN thing is the re-incarnation of the ancient “VPN download as upload” issue that used to be handled in the firmware until this reverted it:

libovpn: remove old AdaptiveQoS patch for upload marking that causes … · RMerl/asuswrt-merlin.ng@91d74fb

…the GT-AXE16000 to reboot

github.com

The question would be, do you see traffic going into the br0 qdisc with a 0x40000000/0xC0000000 mark, when it should be an 0x8…?

I hadn’t considered this a possibility because I assumed this was solved for good. But then the crashes came when trying to modify the marks on HND5.04 routers…

Some good history lessons if you search the FreshJR or FlexQoS threads for “0x40000000/0xc0000000”

 

[ExtremeFiretop]

Can you see the download bytes increasing on the 1:2 class on br0? They have to go somewhere, and I’m guessing they end up here because the firmware reporting ignores this class. And adding a new rule would probably not be a good idea.

I did a clean counter reset (service restart_qos) and captured deltas for all br0 classes plus the br0 root qdisc around a full speedtest.

The result was that br0 class 1:2 barely moves (+12 KB / +31 pkts) and no other br0 class increments meaningfully.
But the br0 root qdisc htb 1: increases by ~340 MB / ~296k pkts during the same run.

(I have nothing else connected to this router but my phone and running speedtests through the app)

So the OpenVPN download traffic is definitely going through br0 (root HTB bytes/packets jump), but it’s not being accounted in any HTB leaf class (including 1:2).
This suggests it’s bypassing per-class classification/accounting (unclassified/fastpath/direct), which could explain why firmware/FlexQoS download can show ~0.

Adding a “catch-all unclassified download out br0” rule could classify it, but I agree it may be risky.

The question would be, do you see traffic going into the br0 qdisc with a 0x40000000/0xC0000000 mark, when it should be an 0x8…?

I also did a before/after snapshot of tc mark-hit counters (no counter resets; just deltas).

Test code used:

snap_tc_marks() {
  dev="$1"
  tc -s filter show dev "$dev" 2>/dev/null | awk '
    / mark 0x/ {
      mark=$2; mask=$3; suc=0
      for(i=1;i<=NF;i++) if($i=="(success") { suc=$(i+1); gsub(/\)/,"",suc) }
      printf "%s %s %s\n", mark, mask, suc
    }
  ' | sort
}

diff_tc_marks() {
  awk 'NR==FNR { b[$1 FS $2]=$3; next }
       { k=$1 FS $2; d=$3-(b[k]+0); if(d) printf "%-12s %-12s %+d\n",$1,$2,d }' \
    "$1" "$2" | sort -k3,3nr
}

tcwan="$(cat /sys/module/tdts_udb/parameters/qos_wan 2>/dev/null || nvram get wan_ifname)"
snap_tc_marks br0    > /tmp/m.br0.before
snap_tc_marks "$tcwan" > /tmp/m.tcwan.before
# (speedtest ran here)
snap_tc_marks br0    > /tmp/m.br0.after
snap_tc_marks "$tcwan" > /tmp/m.tcwan.after
diff_tc_marks /tmp/m.br0.before /tmp/m.br0.after
diff_tc_marks /tmp/m.tcwan.before /tmp/m.tcwan.after

Output:

• br0 mark hit deltas: 0x0000/0xC0000000 +53
• tcwan mark hit deltas: 0x0000/0xC0000000 +113313

So on the WAN QoS interface I’m seeing a large amount of traffic hitting the “no direction bits set” bucket (0x0/0xC0000000), and I’m not seeing it counted under an 0x8… download-direction bucket.
That makes it look less like “download marked as upload (0x400…)” and more like “direction bits aren’t present / get cleared” by the time packets reach tcwan (which might also explain why FlexQoS download accounting can go to ~0).