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

[brummygit]

I've been running the script for a few days on the new beta 3 and haven't noticed any problems. All seems to be close to perfect


Sent from my iPhone using Tapatalk

 

[Vexira]

still checking wont hurt, he might need to modify it to support codel and fq-codel, since the original was sfq.

 

[MarioCaires]

still checking wont hurt, he might need to modify it to support codel and fq-codel, since the original was sfq.

Yes, with the new queue disciplines (codel and fq_codel) the "default priority for Unidentified Traffic" is not being changed! The script needs to be updated to meet the new discipline rules.
Using sfq for the time being...

 

[RMerlin]

If you want to ensure that your tc commands aren't reprocessed (when the fq_codel patch is in place), look for the presence of /usr/sbin/realtc. If it exists, use it instead of /usr/sbin/tc. It will always be the real tc command, not the pre-processing faketc script.

This will work starting with beta 4 only - in beta 3 the patch was trying to make its own copy, which could lead to potential endless loop if the patch failed to be properly removed during a QoS configuration change.

 

[FreshJR]

hi fresh will you be updating the script due to the 380.67 beta 3 qos changes?

If it's within my skill I will. I hope asus didn't block off my pathway.

@ everyone else. I promised updates and didn't deliver yet. Had some major issues 4th of July weekend and had no time

 

[MarioCaires]

Good to see you back @FreshJR!

Since the default queue discipline sfq is still working on 380.67 b3, hopefully it just needs a few "cosmetic" changes to work with the new disciplines!

 

[FreshJR]

If you want to ensure that your tc commands aren't reprocessed (when the fq_codel patch is in place), look for the presence of /usr/sbin/realtc. If it exists, use it instead of /usr/sbin/tc. It will always be the real tc command, not the pre-processing faketc script.

This will work starting with beta 4 only - in beta 3 the patch was trying to make its own copy, which could lead to potential endless loop if the patch failed to be properly removed during a QoS configuration change.

Thanks RMerlin for checking in and letting me know! Now I wont have to search for answers.

I will update to account for that change, and also fix it so its not in the firewall-start file anymore either.

 

[Vexira]

If it's within my skill I will. I hope asus didn't block off my pathway.

@ everyone else. I promised updates and didn't deliver yet. Had some major issues 4th of July weekend and had no time

i have fatih in your skills

 

[FreshJR]

Hello guys! I updated to the beta to check the issue out.

I did not see a loop when testing the difference between sending realtc vs tc commands. I did implement the change RMerlin suggested anyway to avoid possible issue.
I will be keeping an eye on a infinite loop.

I also think it may have been a race issue.
The script is set to apply its modification after 10 seconds of starting QOS/FIREWALL. This allows the rules to populate before modifying them.
Now with the realTC changes, it takes longer to populate the rules. I increased the delay to 30 seconds.

See original post for script release version 1.9

Changes:
-use realtc if present
-script run delay after start increased
-custom QOS rule templates (SUPER NICE)
-two custom QOS rules active per default. The rules are for iOS wifi calling & facetime. That network activity is now detected by simple port destination instead of deep packet inspection
-New install instructions. UNINSTALL OLD SCRIPT!

Custom Rule Templates:
--Categorize traffic into QOS container by incoming/outgoing ports
--Categorize traffic into QOS container originating to/from LAN PC by its IP
--Categorize traffic into QOS container originating to/from LAN PC by its MAC
--Categorize traffic into QOS container received from WAN SERVER IP or destined to WAN SERVER IP

When I get time I will be overhauling the original post to explain how to use everything. For now if you can figure it out, sweet. If not, keep waiting.

Upcoming 2.0:
-The last thing i will be trying to do is implement one last custom rule, gaming focused.
Rule: Traffic on a gaming device should be filtered like normal, but any unintended traffic on that device will be sent into the gaming category instead of default/others.


--
I will be repeating the new uninstall instructions twice as they are important.

To uninstall run these two commands in shell terminal using putty:
UNINSTALL OLD SCRIPT! USE THESE COMMANDS

cru d QOS_CHECK
echo "" > /jffs/scripts/firewall-start

Note echo command will clear out firewall-start, where my script resides, if you have other things in there. Save it, or manually clear out my script yourself using other methods.
--


As for thew new install, the script will now not be residing inside the firewall-start file. Instead from now on it will be called Fresh_QOS and the firewall-start will call Fresh_QOS. This will keep multiple scripts neatly organized.

 

[MarioCaires]

Thanks for the update @FreshJR

So with the new custom rule template can we attribute a port to a specific category for proper identification like IPTV?

I have looked into the original post, however can't seem to find the updated script, I'm assuming you're still updating the post...

 

[FreshJR]

Thanks for the update @FreshJR

So with the new custom rule template can we attribute a port to a specific category for proper identification like IPTV?

I have looked into the original post, however can't seem to find the updated script, I'm assuming you're still updating the post...

Correct on both questions. Still updating posts and that type of filtering has been achieved.

Unfortunately I will not be fully explaining the port mask (used to define range) defining syntax used in the script today. I do not have enough time.

First post will be a little crude. Just wait out a little longer for full explanations.

 

[Vexira]

Correct on both questions. Still updating posts and that type of filtering has been achieved.

Unfortunately I will not be fully explaining the port mask (used to define range) defining syntax used in the script today. I do not have enough time.

First post will be a little crude. Just wait out a little longer for full explanations.

awesome, may i ask how would wan packet over head factor into the script, like how does it affect the scripts abilty to allocate bandwidth.

 

[FreshJR]

awesome, may i ask how would wan packet over head factor into the script, like how does it affect the scripts abilty to allocate bandwidth.

Bandwidth allocation was explained multiple times in this thread. WAN packet overhead should be included.

The gist of it is is that bandwidth allocation will give each category a guaranteed bandwidth but bandwidth from categories not using will NOT be lost.
That unused bandwidth will given to the category that needs it in order of priority. The allocations are really just minimums, and will be exceeded 99% of the time.

 

[bbunge]

Can't seem to find the link to your latest script. Original post just shows ver. 1.4. Can you post it again?

 

[Vexira]

Bandwidth allocation was explained multiple times in this thread. WAN packet overhead should be included.

The gist of it is is that bandwidth allocation will give each category a guaranteed bandwidth but bandwidth from categories not using will NOT be lost.
That unused bandwidth will given to the category that needs it in order of priority. The allocations are really just minimums, and will be exceeded 99% of the time.

So wan packet overhead is factored into the new script that what i was trying to ask, and wanted to know about.
Thank you very much. Kudos. Keep up the good work.

 

[FreshJR]

So wan packet overhead is factored into the new script that what i was trying to ask, and wanted to know about.
Thank you very much. Kudos. Keep up the good work.

No it seems like that change was done by RMerlin currently present in his new beta.

I thought the WAN packet overhead was always included, even in the old versions. In this beta I see there is a WAN overhead drop down toggle, so give credit to him where its due, and those down the line aswell who came up with the codel /fq_codel algorithms, iptables, and traffic control engines. Amazing work all around!

 

[MarioCaires]

I have the script already running with fq_codel and 2 custom rules by port and it really works as expected! Awesome work @FreshJR

 

[Adamm]

@FreshJR Can I suggest an uninstall/install command, I can see users not fully reading the OP and wiping the firewall-start file, here is the basic standard that was suggested.

That way you can handle things like missing shebangs automatically;

        if [ ! -f "/jffs/scripts/firewall-start" ]; then
            echo "#!/bin/sh" > /jffs/scripts/firewall-start
        elif [ -f "/jffs/scripts/firewall-start" ] && ! head -1 /jffs/scripts/firewall-start | grep -qE "^#!/bin/sh"; then
            sed -i '1s~^~#!/bin/sh\n~' /jffs/scripts/firewall-start
        fi

Along with a standardised entry like;

/jffs/scripts/FreshJR_QOS # Added By FreshQOS

 

[eddiez]

Giving it a try. Let's see if it resolves the intermittent WiFi calling issues.

 

[el pescador]

Gonna have to try this as battlefield traffic is mixed between gaming and default.
Might explain why i sometimes get issues in game.
Just noticed it on 380.67 beta 4