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

[maghuro]

+1 to all this!
I spent ages searching for the new repo link!


Sent from my iPhone using Tapatalk

Or at least @dave14305 should start a new thread for this script for the new firmware version.
Because IMHO Dave should invest their time on the new version, as the "old" version does it job on old firmwares.

Just my two cents

 

[JDB]

Or at least @dave14305 should start a new thread for this script for the new firmware version.
Because IMHO Dave should invest their time on the new version, as the "old" version does it job on old firmwares.

Just my two cents

Yea maybe launch official new thread for the upcoming fw with the new categories. Makes sense, nice a clean start then.


Sent from my iPhone using Tapatalk

 

[dave14305]

@dave14305 3 suggestions:
- you should create a new thread for the new version
- you should hardcode ports 53 and 853 to go to net packet control, because it is DoT.
- as FreshJR won't come for sure, @thelonelycoder should change the repo on amtm to yours.

Thanks!

I have plans for a separate fork thread, but since 384.18 final seems like a long way off, I was still trying to lay low and get feedback from the early adopters.

Hardcoding router DNS/DoT traffic is debatable since you'll never see it on the Classification page to know if it's working. The current hardcoded rule simply exempts DNS, NTP and DoT traffic from being pushed into Downloads (as a VPN client fix). I don't fully understand the implications of playing with this since I don't use a VPN client.

Regarding AMTM, I'm not sure what thelonelycoder would want to do to handle users who haven't upgraded to 384.18, or cannot upgrade to 384.18 because they are on the 384.13 "branch". We'll cross that bridge when we get to it.

Because IMHO Dave should invest their time on the new version, as the "old" version does it job on old firmwares.

Yea maybe launch official new thread for the upcoming fw with the new categories. Makes sense, nice a clean start then.

I'm reasonably close to having a version that handles old and new in the same script. But since the original script also provides support for stock firmware, I'm not sure anymore how to determine if the stock firmware supports old or new QoS, given Asus' version numbering nightmare.

 

[JDB]

Can you look for the existence of the new categories somewhere to determine if you run in legacy or new mode?


Sent from my iPhone using Tapatalk

 

[thelonelycoder]

I have plans for a separate fork thread, but since 384.18 final seems like a long way off, I was still trying to lay low and get feedback from the early adopters.

Hardcoding router DNS/DoT traffic is debatable since you'll never see it on the Classification page to know if it's working. The current hardcoded rule simply exempts DNS, NTP and DoT traffic from being pushed into Downloads (as a VPN client fix). I don't fully understand the implications of playing with this since I don't use a VPN client.

Regarding AMTM, I'm not sure what thelonelycoder would want to do to handle users who haven't upgraded to 384.18, or cannot upgrade to 384.18 because they are on the 384.13 "branch". We'll cross that bridge when we get to it.


I'm reasonably close to having a version that handles old and new in the same script. But since the original script also provides support for stock firmware, I'm not sure anymore how to determine if the stock firmware supports old or new QoS, given Asus' version numbering nightmare.

Give that fork a fresh new name, then I can handle it in amtm.

 

[maghuro]

Regarding dot:
One of my devices is using Android built in DNS privacy option, basically DoT, which send the DNS requests through port 853. And this traffic is being counted as "web traffic", and it must be counted as net control packets.
Not using vpn right now. I manually created a rule where port 53 and 853 traffic goes to net control. And it works as expected, so my suggestion to hard code that rule

 

[Sinner]

I always preferred a less rules is better approach. And Trend might just eventually make that change in the appdb as well. its simple enough to use the ui interface maybe just go with that for now since it seems qos is in the spotlight atm for Asus

 

[QuikSilver]

Give that fork a fresh new name, then I can handle it in amtm.

FreshDaveQos? DaveJRQOS? None have the same ring to it as the original but I sure we will grow to like it.

 

[dave14305]

FreshDaveQos? DaveJRQOS? None have the same ring to it as the original but I sure we will grow to like it.

A general question to the forum at large - what's the right way to fork and rename but still give credit to the original author who did the hard work without looking like a weasel? I didn't intend to rename it at all, but I probably need to PM thelonelycoder to understand how different he prefers it for AMTM logic.

Ideas welcome. Anything from 1QoS (too short) to ASUSWRT-Merlin-QoS (too long).

I'm learning quickly that I enjoy the learning and the coding. Dealing with you all (i.e. users just like me) is less fun.

 

[dave14305]

Regarding dot:
One of my devices is using Android built in DNS privacy option, basically DoT, which send the DNS requests through port 853. And this traffic is being counted as "web traffic", and it must be counted as net control packets.
Not using vpn right now. I manually created a rule where port 53 and 853 traffic goes to net control. And it works as expected, so my suggestion to hard code that rule

I had to install the 1.1.1.1 App on my phone to see how DoT looks from the LAN. So it's a hardcoded appdb rule to map 1400C5 to Net Control you want? Does it recognize it with that mark for you?

It's quite bizarre that Asus/Trend recognizes it as Web Surfing. I'll consider it for the next update. Once I get through this transition phase, my major rewrite will allow hardcoded rules to be changed/deleted. And you can have a lot of of them. But that's just vaporware as of now. My local git repo is a tangle of half-executed ideas. I will get organized and act like a grownup.

 

[QuikSilver]

A general question to the forum at large - what's the right way to fork and rename but still give credit to the original author who did the hard work without looking like a weasel? I didn't intend to rename it at all, but I probably need to PM thelonelycoder to understand how different he prefers it for AMTM logic.

Ideas welcome. Anything from 1QoS (too short) to ASUSWRT-Merlin-QoS (too long).

I'm learning quickly that I enjoy the learning and the coding. Dealing with you all (i.e. users just like me) is less fun.

I would think your own same DaveQos or something similar with a credit to @FreshJR with the first post AND on the github.

 

[dave14305]

@maghuro I actually see that it's a "feature" in the original script that redirects category 20 (hex 14) to Web Surfing as a way of moving HTTPS out of Net Control. Need to think about it more to see if it's overkill or just a mistake.

 

[AntonK]

I think I've missed something: what happened to @FreshJR?

 

[QuikSilver]

I think I've missed something: what happened to @FreshJR?

He has been absent for some time. With the new firmware coming out alot of us that used his script won't be able to upgrade. That is where @dave14305 has come in to possibly take his original script and make it compatible with the new QOS categories in 384.18.

 

[Kingp1n]

A general question to the forum at large - what's the right way to fork and rename but still give credit to the original author who did the hard work without looking like a weasel? I didn't intend to rename it at all, but I probably need to PM thelonelycoder to understand how different he prefers it for AMTM logic.

Ideas welcome. Anything from 1QoS (too short) to ASUSWRT-Merlin-QoS (too long).

I'm learning quickly that I enjoy the learning and the coding. Dealing with you all (i.e. users just like me) is less fun.

How about:

"DMF_QoS script" = "Dave's QoS Master File", just throwing stuff out there!
D = Dave14305
M = Master (Merlin)
F = File (FreshJR)

I'll keep brainstorming haha!

 

[AntonK]

He has been absent for some time. With the new firmware coming out alot of us that used his script won't be able to upgrade. That is where @dave14305 has come in to possibly take his original script and make it compatible with the new QOS categories in 384.18.

Is this script still compatible with an AC88U running RMerlin 384.17?

 

[QuikSilver]

Is this script still compatible with an AC88U running RMerlin 384.17?

Dave has "tweaked" Fresh's script to work with .17 a couple pages back (it included a couple fixes to the original). The new version (name pending) deals with the new categories (work from home, learn from home...) introduced in .18 by Asus.

 

[AntonK]

Dave has "tweaked" Fresh's script to work with .17 a couple pages back (it included a couple fixes to the original). The new version (name pending) deals with the new categories (work from home, learn from home...) introduced in .18 by Asus.

Thanks @QuikSilver, I appreciate your time and response.

Anton

 

[QuikSilver]

Thanks @QuikSilver, I appreciate your time and response.

Anton

Anytime!

 

[Adamm]

I'm reasonably close to having a version that handles old and new in the same script. But since the original script also provides support for stock firmware, I'm not sure anymore how to determine if the stock firmware supports old or new QoS, given Asus' version numbering nightmare.

Sounds like a good time to trim the fat. While stock firmware support is nice in theory, I couldn’t imagine the userbase would be very large.

Simplifying the code also has the benefit of making it easier for others to contribute, some food for thought