Menu
What's new
By:
Filters Better Search

[Release] FreshJR Adaptive QOS (Improvements / Custom Rules / and Inner workings)

  • 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.
solstyce said:
Depends on what you want. I don't know the throughput of the AX88U but most people on gigabit see significant drops in speed when using QoS, e.g. 500-700Mbps. In the past FreshJR has recommended bandwidth allocation per device and Microtik equipment for simple QoS implementations.

I'd try it and see if it works for you.
Click to expand...
i stopped using QOS on 1Gbit/100Mbit as the download speed was limited to 450 Mbit max. now it is around 800 - same router
 
dave14305 said:
I thought it was a no-go until I realized you misspelled dscp in the rule. An interesting idea. Test it out and let us know if it's more reliable than the current methods. FreshJR UI won't show the connections in the right colored category since it has no way to determine the dscp marking from the UI functions. But if it works, you should see it in the correct bucket in the pie charts.
Click to expand...


Finally had a chance to test this. It appears the Asus iptables command doesn't understand the dscp match. When I try the following to match Zoom traffic (56 & 40 up and down):

Code: 
iptables -D POSTROUTING -t mangle -o br0 -m dscp --dscp 56 -j MARK --set-mark 0x80060001
iptables -A POSTROUTING -t mangle -o br0 -m dscp --dscp 56 -j MARK --set-mark 0x80060001
iptables -D POSTROUTING -t mangle -o eth0 -m dscp --dscp 56 -j MARK --set-mark 0x40060001
iptables -A POSTROUTING -t mangle -o eth0 -m dscp --dscp 56 -j MARK --set-mark 0x40060001

iptables -D POSTROUTING -t mangle -o br0 -m dscp --dscp 40 -j MARK --set-mark 0x80060001
iptables -A POSTROUTING -t mangle -o br0 -m dscp --dscp 40 -j MARK --set-mark 0x80060001
iptables -D POSTROUTING -t mangle -o eth0 -m dscp --dscp 40 -j MARK --set-mark 0x40060001
iptables -A POSTROUTING -t mangle -o eth0 -m dscp --dscp 40 -j MARK --set-mark 0x40060001

I get a series of errors

Code: 
iptables: No chain/target/match by that name.

I'm assuming that means it doesn't understand "dscp" as a match since the POSTROUTING chain definitely exists in the mangle target. Not sure how iptables is implemented on Asus, but
Code: 
/usr/lib/xtables/libxt_dscp.so
/lib/modules/2.6.36.4brcmarm/kernel/net/netfilter/xt_dscp.ko
both exist which makes me think it should match.

@Kingp1n have you had any luck with this?
 
solstyce said:
Finally had a chance to test this. It appears the Asus iptables command doesn't understand the dscp match. When I try the following to match Zoom traffic (56 & 40 up and down):

Code: 
iptables -D POSTROUTING -t mangle -o br0 -m dscp --dscp 56 -j MARK --set-mark 0x80060001
iptables -A POSTROUTING -t mangle -o br0 -m dscp --dscp 56 -j MARK --set-mark 0x80060001
iptables -D POSTROUTING -t mangle -o eth0 -m dscp --dscp 56 -j MARK --set-mark 0x40060001
iptables -A POSTROUTING -t mangle -o eth0 -m dscp --dscp 56 -j MARK --set-mark 0x40060001

iptables -D POSTROUTING -t mangle -o br0 -m dscp --dscp 40 -j MARK --set-mark 0x80060001
iptables -A POSTROUTING -t mangle -o br0 -m dscp --dscp 40 -j MARK --set-mark 0x80060001
iptables -D POSTROUTING -t mangle -o eth0 -m dscp --dscp 40 -j MARK --set-mark 0x40060001
iptables -A POSTROUTING -t mangle -o eth0 -m dscp --dscp 40 -j MARK --set-mark 0x40060001

I get a series of errors

Code: 
iptables: No chain/target/match by that name.

I'm assuming that means it doesn't understand "dscp" as a match since the POSTROUTING chain definitely exists in the mangle target. Not sure how iptables is implemented on Asus, but
Code: 
/usr/lib/xtables/libxt_dscp.so
/lib/modules/2.6.36.4brcmarm/kernel/net/netfilter/xt_dscp.ko
both exist which makes me think it should match.

@Kingp1n have you had any luck with this?
Click to expand...
On "older" routers, you have to manually load the module:
Code: 
modprobe xt_dscp.ko

iptables -A POSTROUTING -t mangle -o eth0 -m dscp --dscp 40 -j MARK --set-mark 0x40060001

iptables --line -t mangle -nvL POSTROUTING

Chain POSTROUTING (policy ACCEPT 439 packets, 69318 bytes)
num   pkts bytes target     prot opt in     out     source               destination       
1        0     0 MARK       all  --  *      eth0    0.0.0.0/0            0.0.0.0/0            DSCP match 0x28 MARK set 0x40060001
 
Last edited:
Martineau said:
On "older" routers, you have to manually load the module:
Code: 
modprobe xt_dscp.ko

iptables -A POSTROUTING -t mangle -o eth0 -m dscp --dscp 40 -j MARK --set-mark 0x40060001

iptables --line -t mangle -nvL POSTROUTING

Chain POSTROUTING (policy ACCEPT 439 packets, 69318 bytes)
num   pkts bytes target     prot opt in     out     source               destination     
1        0     0 MARK       all  --  *      eth0    0.0.0.0/0            0.0.0.0/0            DSCP match 0x28 MARK set 0x40060001
Click to expand...

Ah, that explains it. Thanks!

I'm now seeing the rules in my iptables, but they don't seem to be marking any packets. I tried adding the rules manually after Adaptive QoS started which put them at the bottom of the POSTROUTING chain set. To check if the order matters, I added them to the FreshJRQoS script so they were first in the list, but same results, no packets or bytes showing in the iptables output despite running a Zoom meeting.

I know for some iptables actions, e.g. DROP, no further action is taken on the packet. Do MARK actions also stop further actions on the packet? I'm assuming there's a conflict in my POSTROUTING rules that's marking this traffic first

Code: 
admin@RT-AC68U-D088:/jffs/scripts# iptables -nvL -t mangle
Chain PREROUTING (policy ACCEPT 827 packets, 82560 bytes)
 pkts bytes target     prot opt in     out     source               destination
   18  6678 ACCEPT     udp  --  eth0   *       192.168.1.254        0.0.0.0/0            udp spt:67 dpt:68
 118K   21M BWDPI_FILTER  udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0

Chain INPUT (policy ACCEPT 629 packets, 66045 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 198 packets, 16515 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 MARK       all  --  *      br0     192.168.2.0/24       192.168.2.0/24       MARK xset 0x1/0x7

Chain OUTPUT (policy ACCEPT 728 packets, 786K bytes)
 pkts bytes target     prot opt in     out     source               destination
   18  5904 MARK       udp  --  *      eth0    0.0.0.0/0            0.0.0.0/0            multiport dports  !53,123 MARK set 0x40030001
 2191 2576K MARK       tcp  --  *      eth0    0.0.0.0/0            0.0.0.0/0            multiport dports  !53,123 MARK set 0x40030001

Chain POSTROUTING (policy ACCEPT 926 packets, 802K bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 MARK       udp  --  *      br0     0.0.0.0/0            0.0.0.0/0            multiport sports 500,4500 MARK set 0x80060001
    0     0 MARK       udp  --  *      br0     0.0.0.0/0            0.0.0.0/0            udp dpts:16384:16415 MARK set 0x80060001
    0     0 MARK       tcp  --  *      br0     0.0.0.0/0            0.0.0.0/0            multiport sports 119,563 MARK set 0x80030001
    0     0 MARK       all  --  *      br0     0.0.0.0/0            0.0.0.0/0            mark match 0x40000000/0xc0000000 MARK xset 0x80000000/0xc0000000
    9  7460 MARK       tcp  --  *      br0     0.0.0.0/0            0.0.0.0/0            mark match 0x80080000/0xc03f0000 multiport sports 80,443 MARK set 0x803f0001
    0     0 MARK       tcp  --  *      br0     0.0.0.0/0            192.168.2.48/30      mark match 0x80000000/0x8000ffff multiport sports  !80,433 MARK set 0x80080001
    0     0 MARK       udp  --  *      br0     0.0.0.0/0            192.168.2.48/30      mark match 0x80000000/0x8000ffff multiport sports  !80,443 MARK set 0x80080001
 3586 1043K MARK       all  --  *      br0     0.0.0.0/0            192.168.2.40/30      MARK set 0x80060001
1919K 2836M MARK       all  --  *      br0     0.0.0.0/0            192.168.2.8/30       MARK set 0x80040001
    0     0 MARK       udp  --  *      eth0    0.0.0.0/0            0.0.0.0/0            multiport dports 500,4500 MARK set 0x40060001
    2   135 MARK       udp  --  *      eth0    0.0.0.0/0            0.0.0.0/0            udp spts:16384:16415 MARK set 0x40060001
    0     0 MARK       tcp  --  *      eth0    0.0.0.0/0            0.0.0.0/0            multiport dports 119,563 MARK set 0x40030001
    0     0 MARK       tcp  --  *      eth0    0.0.0.0/0            0.0.0.0/0            mark match 0x40080000/0xc03f0000 multiport sports 80,443 MARK set 0x403f0001
    0     0 MARK       tcp  --  *      eth0    192.168.2.48/30      0.0.0.0/0            mark match 0x40000000/0x4000ffff multiport dports  !80,443 MARK set 0x40080001
    0     0 MARK       udp  --  *      eth0    192.168.2.48/30      0.0.0.0/0            mark match 0x40000000/0x4000ffff multiport dports  !80,443 MARK set 0x40080001
 3434  501K MARK       all  --  *      eth0    192.168.2.40/30      0.0.0.0/0            MARK set 0x40060001
 231K   16M MARK       all  --  *      eth0    192.168.2.8/30       0.0.0.0/0            MARK set 0x40040001
    0     0 MARK       all  --  *      br0     0.0.0.0/0            0.0.0.0/0            DSCP match 0x38 MARK set 0x80060001
    0     0 MARK       all  --  *      eth0    0.0.0.0/0            0.0.0.0/0            DSCP match 0x38 MARK set 0x40060001
    0     0 MARK       all  --  *      br0     0.0.0.0/0            0.0.0.0/0            DSCP match 0x28 MARK set 0x80060001
    0     0 MARK       all  --  *      eth0    0.0.0.0/0            0.0.0.0/0            DSCP match 0x28 MARK set 0x40060001

Chain BWDPI_FILTER (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            udp spt:68 dpt:67
    0     0 DROP       udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0            udp spt:67 dpt:68

Any iptables experts notice anything obvious? I was hoping this would be an easier solution since there's no dependency on my bit manipulation skills but may have to revisit using tc to try to classify this traffic.
 
solstyce said:
Finally had a chance to test this. It appears the Asus iptables command doesn't understand the dscp match. When I try the following to match Zoom traffic (56 & 40 up and down):

Code: 
iptables -D POSTROUTING -t mangle -o br0 -m dscp --dscp 56 -j MARK --set-mark 0x80060001
iptables -A POSTROUTING -t mangle -o br0 -m dscp --dscp 56 -j MARK --set-mark 0x80060001
iptables -D POSTROUTING -t mangle -o eth0 -m dscp --dscp 56 -j MARK --set-mark 0x40060001
iptables -A POSTROUTING -t mangle -o eth0 -m dscp --dscp 56 -j MARK --set-mark 0x40060001

iptables -D POSTROUTING -t mangle -o br0 -m dscp --dscp 40 -j MARK --set-mark 0x80060001
iptables -A POSTROUTING -t mangle -o br0 -m dscp --dscp 40 -j MARK --set-mark 0x80060001
iptables -D POSTROUTING -t mangle -o eth0 -m dscp --dscp 40 -j MARK --set-mark 0x40060001
iptables -A POSTROUTING -t mangle -o eth0 -m dscp --dscp 40 -j MARK --set-mark 0x40060001

I get a series of errors

Code: 
iptables: No chain/target/match by that name.

I'm assuming that means it doesn't understand "dscp" as a match since the POSTROUTING chain definitely exists in the mangle target. Not sure how iptables is implemented on Asus, but
Code: 
/usr/lib/xtables/libxt_dscp.so
/lib/modules/2.6.36.4brcmarm/kernel/net/netfilter/xt_dscp.ko
both exist which makes me think it should match.

@Kingp1n have you had any luck with this?
Click to expand...
I highly doubt these will work but you for testing, can you paste these rules inside the script "legacy method" and test them:

under Download:
iptables -D POSTROUTING -t mangle -o br0 -m dscp --dscp 40,56 -j MARK --set-mark ${VOIP_mark_down} &> /dev/null
iptables -A POSTROUTING -t mangle -o br0 -m dscp --dscp 40,56 -j MARK --set-mark ${VOIP_mark_down}
Click to expand...

under Upload:
iptables -D POSTROUTING -t mangle -o $wan -m dscp --dscp 40,56 -j MARK --set-mark ${VOIP_mark_up} &> /dev/null
iptables -A POSTROUTING -t mangle -o $wan -m dscp --dscp 40,56 -j MARK --set-mark ${VOIP_mark_up}
Click to expand...

UPDATE: Yep, I've just tested and saw the error message with "dscp bad value" in the log.
 
Last edited:
Kingp1n said:
I highly doubt these will work but you for testing, can you paste these rules inside the script "legacy method" and test them:

UPDATE: Yep, I've just tested and saw the error message with "dscp bad value" in the log.
Click to expand...

Same here. I honestly didn't think to try combining DSCP values in the match, but looking at the iptables extensions man page it doesn't look like it accepts multiple values or ranges.

I've taken a deep dive into Wireshark and found the source of my problem. The iptables command works perfectly. However, the Zoom documentation is wrong, or there's a bug in the client. Wireshark is clearly showing Zoom traffic tagged with DSCP 0 and DSCP 27 rather than the 56 and 40 claimed in the documentation. When I tried
Code: 
iptables -D POSTROUTING -t mangle -o br0 -m dscp --dscp 27 -j MARK --set-mark ${VOIP_mark_down} &> /dev/null
iptables -A POSTROUTING -t mangle -o br0 -m dscp --dscp 27 -j MARK --set-mark ${VOIP_mark_down}
and the same for 0, that Zoom traffic started showing up in the VOIP bucket. However, "0" is used for lots of other non-VOIP traffic, at least on my network, so I didn't want to make that all high priority considering "0" is the lowest possible priority in DSCP.

So despite the success of the iptables approach, I decided to go back to ports. Zoom uses primarily 3478, 3479, 8801, and 8802, and according to the docs uses both UDP and TCP although I am only seeing traffic on UDP. Just to be safe, I added all 4 ports, both protocols via the FreshJR web UI as one of the 4 custom rules. The docs mention they sometimes use ports 8803-8810 but I haven't seen any traffic on those ports yet.

I'd recommend we add these ports to the existing pre-defined VOIP ports rule, but I found in my research that several games use 3478 and 3479 as well, and I imagine dedicated gamers would want those ports be classified as Game traffic by default.

Thanks again, to everyone, for all the help! It's great to see all my Zoom traffic getting priority ahead of Netflix, Web, etc.!
 
If someone decides to update this script to handle the recent Adaptive QoS changes, here is the summary of what Asus changed:

- VoIP and Instant Messaging priority has been renamed to Work-From-Home (with the same categories as before - the only change is the description itself)
- The fourth priority is now Learn-From-Home, and handles categories 4 and 13 (meaning these two categories now exist in two separate priority lists)
- Previous priorities 4 through 6 have been shifted down to 5 through 7 (due to the insertion of Learn-From-Home)
- The former priority 7 (Default) no longer exists, it's now Others.
- The Default priority (for untracked traffic) is priority 4.
 
RMerlin said:
If someone decides to update this script to handle the recent Adaptive QoS changes, here is the summary of what Asus changed:

- VoIP and Instant Messaging priority has been renamed to Work-From-Home (with the same categories as before - the only change is the description itself)
- The fourth priority is now Learn-From-Home, and handles categories 4 and 13 (meaning these two categories now exist in two separate priority lists)
- Previous priorities 4 through 6 have been shifted down to 5 through 7 (due to the insertion of Learn-From-Home)
- The former priority 7 (Default) no longer exists, it's now Others.
- The Default priority (for untracked traffic) is priority 4.
Click to expand...
Haha for me..this sounds so complicated ! Where the smart people at?
 
Last edited:
Hi guys,

I am sorry if this has been covered before but I couldn't find any mentions of it in the 216 pages :)

Can this script work if you have more than one bridge?
It looks like every iptables and tc directives are targeting br0.

Do you think it would be as simple as duplicating the directives to all the other bridges or QoS is not compatible with having multiple bridges?

P.S: The reason for the multiple bridges is the creation of VLAN on my AC86U/68U for my home topology.
 
Last edited:
dave14305 said:
Once the AC68U gets a build with the equivalent GPL, I might be able to figure out what needs changing.
Click to expand...
iu
 
dave14305 said:
Cesar Romero was the only Joker in my book. But I had an unhealthy obsession with that TV Series as a kid.
Click to expand...
I'm from the age of Jack Nicolas and Michael Keaton...
iu
 
Michel said:
Hi guys,

I am sorry if this has been covered before but I couldn't find any mentions of it in the 216 pages :)

Can this script work if you have more than one bridge?
It looks like every iptables and tc directives are targeting br0.

Do you think it would be as simple as duplicating the directives to all the other bridges or QoS is not compatible with having multiple bridges?

P.S: The reason for the multiple bridges is the creation of VLAN on my AC86U/68U for my home topology.
Click to expand...
I think you mean multiple interfaces.
 
Hey guys, just did a hard reset on my AC86U (latest Merlin), since it's been a while. I previously had FreshJr's script installed (minimal tweaks in the ui, I'm not that tech savvy), but Asus' own QoS seems to have evolved, too. It does categorize traffic better than before, but does the script still have the advantages it provided a year ago?

Thanks!

Edit: 50/50 mbps, one-to-two users, max 6 devices, hd streaming and game downloads are the heaviest saturators.
 
Last edited:
Status
Not open for further replies.

Similar threads

T
WireGuard and Traditional QOS
2
Replies
24
Views
1K
Tomo123
T
RMerlin
  • Locked
Release Asuswrt-Merlin 3004.388.5 is now available
12 13 14
Replies
260
Views
34K
RMerlin
RMerlin
RMerlin
Release Asuswrt-Merlin 386.13 is now available for AC models
2
Replies
38
Views
5K
Tech9
Tech9
T
A possible bug with QOS traffic classification?
Replies
14
Views
739
Tomo123
T
RMerlin
  • Locked
Beta Asuswrt-Merlin 3004.388.5-beta is now available
2 3
Replies
58
Views
9K
RMerlin
RMerlin
Similar threads
Thread starter Title Forum Replies Date
Viktor Jaep [RELEASE] ECLIPSEMON v0.0.1 - Crazy Complex Solar Eclipse Astronomical Calculator to predict if a Solar Eclipse will appear today! Asuswrt-Merlin AddOns 34
John Fitzgerald Skynet New Skynet 7.5.9 Release Asuswrt-Merlin AddOns 114
vlord amtm AMTM doesn't like scMerlin Beta Release Asuswrt-Merlin AddOns 23
SomeWhereOverTheRainBow AdGuardHome AdGuardHome New Release's 2023 Asuswrt-Merlin AddOns 288

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

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

Members online

Total: 733 (members: 23, guests: 710)
Top