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

[FreshJR]

/jffs/scripts/FreshJR_QOS -appdb "Let Encrypt"

gives me

Lets Encrypt
Cat: Net Control
Mark: 0x801400c2 0xc03fffff
Prio: 22

but I notice that the traffic under "QOS Statistics" when downloading, that it is showing up for that machine classified as "Web Surfing".

Appreciate the dedication!! I will update the first post stating that reading the first three posts and last few pages in this thread is sufficient!

The reason that above situation happens is that appdb gives the original destination of traffic per the Asus default unmodified setup.

After installing the script with default settings, it redirected most of "Net Control" into Web Surfing. This is because most https + other encrypted traffic was sorted into "Net Control" and I didn't agree with that priority level!

If you have more questions, dont hesitate to ask! Hope this explanation was clear.

EDIT: You can still redirect it into any category you desire with the above mark & prio!

( Maybe I should remove the "Cat: " field to reduce future confusion or rename it "Original QOS Cat before script:" ?? )

 

[morden]

QOS + VPN Client fix via custom rules.

Custom Rules for when Router is acting as a VPN Client

Spoiler: VPN Client

These custom rules fix tunneled traffic from being zero-rated (whitelisted) or have traffic in the wrong section (reversed) when using QOS.

Download:
iptables -D POSTROUTING -t mangle -o br0 -d 192.168.2.100/32 -j MARK --set-xmark 0x80000000/0xC0000000  &> /dev/null
iptables -A POSTROUTING -t mangle -o br0 -d 192.168.2.100/32 -j MARK --set-xmark 0x80000000/0xC0000000

"Incoming/download" traffic is being whitelisted/reversed on the download interface since Asus is marking "download" traffic with an "upload" mark.
The rule above switches the "upload" mark back into a "download" mark.
Since the original mark is preserved, download traffic will remain correctly identified by traffic type.

192.168.2.100/32 should be changed to match the iprange of your tunneled devices​

Upload:
iptables -D OUTPUT -t mangle -o $wan ! -s 192.168.2.1 -p udp --dport 25000 -j MARK --set-mark ${Downloads_mark_up} &> /dev/null
iptables -A OUTPUT -t mangle -o $wan ! -s 192.168.2.1 -p udp --dport 25000 -j MARK --set-mark ${Downloads_mark_up}

The upload mark assigned to upload traffic is completely lost after entering the VPN tunnel.
As a result, we have to lump ALL upload vpn traffic into a fixed user defined category.

192.168.2.1 should be changed to the IP of your router

-p udp --dport 25000 should be changed to the protocol and port of your VPN host/provider.​

Enjoy!

192.168.2.100/32 should be changed to match the iprange of your tunneled devices

@FreshJR I have a question regarding iprange, what does the /32 represent? and how do I know what the IP range of my tunneled devices is? Sorry for the newb question!

EDIT: Never mind, I googled it and got the answer! LOL

 

[GxlactusDa]

Appreciate the dedication!! I will update the first post stating that reading the first three posts and last few pages in this thread is sufficient!

The reason that above situation happens is that appdb gives the original destination of traffic per the Asus default unmodified setup.

After installing the script with default settings, it redirected most of "Net Control" into Web Surfing. This is because most https + other encrypted traffic was sorted into "Net Control" and I didn't agree with that priority level!

If you have more questions, dont hesitate to ask! Hope this explanation was clear.

EDIT: You can still redirect it into any category you desire with the above mark & prio!

( Maybe I should remove the "Cat: " field to reduce future confusion or rename it "Original QOS Cat before script:" ?? )

FreshJr can you help me prioritize my game packets on traditional QoS specifically in the section ‘User Defined QoS Rules’. Can’t use Adaptive QoS since Adaptive QoS won’t identify them and there’s a routing issue with the upload speed on 86u ‘adaptive QoS’, the game is Black Ops 4. I use Merlin Firmware (384.7_2) and have an 86u.

 

[JohnSmith]

Appreciate the dedication!! I will update the first post stating that reading the first three posts and last few pages in this thread is sufficient!

The reason that above situation happens is that appdb gives the original destination of traffic per the Asus default unmodified setup.

After installing the script with default settings, it redirected most of "Net Control" into Web Surfing. This is because most https + other encrypted traffic was sorted into "Net Control" and I didn't agree with that priority level!

If you have more questions, dont hesitate to ask! Hope this explanation was clear.

EDIT: You can still redirect it into any category you desire with the above mark & prio!

( Maybe I should remove the "Cat: " field to reduce future confusion or rename it "Original QOS Cat before script:" ?? )

Thanks for the response FreshJR. As I have one machine that I would like to redirect to the "File Transferring" category, do I need to do the following:

1. Create a TC Filter for this APP in the "tc_redirection_down_rules"
2. Create a TC Filter for this APP in the "tc_redirection_up_rules"
3. Create an iptables -D & - A in the "DOWNLOAD (INCOMING TRAFFIC) CUSTOM RULES START HERE" section for this specific machine
4. Create an iptables -D & - A in the "UPLOAD (UPLOAD TRAFFIC) CUSTOM RULES START HERE" section for this specific machine

 

[strangeluck]

After installing the script with default settings, it redirected most of "Net Control" into Web Surfing. This is because most https + other encrypted traffic was sorted into "Net Control" and I didn't agree with that priority level!

I recently started using stubby for DNS over TLS and noticed that DNS requests were no longer going into "Net Control". I have added the following custom rules for Cloudflare DNS to correctly route this traffic. I believe this should cover all traffic to the DNS servers be it standard DNS, DNS over TLS, or DNS over HTTPS.

#DOWNLOAD

           iptables -D POSTROUTING -t mangle -o br0 -s 1.1.1.1/32 -j MARK --set-mark ${Net_mark_down} &> /dev/null
           iptables -A POSTROUTING -t mangle -o br0 -s 1.1.1.1/32 -j MARK --set-mark ${Net_mark_down}
           iptables -D POSTROUTING -t mangle -o br0 -s 1.0.0.1/32 -j MARK --set-mark ${Net_mark_down} &> /dev/null
           iptables -A POSTROUTING -t mangle -o br0 -s 1.0.0.1/32 -j MARK --set-mark ${Net_mark_down}
           ip6tables -D POSTROUTING -t mangle -o br0 -s 2606:4700:4700::1111 -j MARK --set-mark ${Net_mark_down} &> /dev/null
           ip6tables -A POSTROUTING -t mangle -o br0 -s 2606:4700:4700::1111 -j MARK --set-mark ${Net_mark_down}
           ip6tables -D POSTROUTING -t mangle -o br0 -s 2606:4700:4700::1001 -j MARK --set-mark ${Net_mark_down} &> /dev/null
           ip6tables -A POSTROUTING -t mangle -o br0 -s 2606:4700:4700::1001 -j MARK --set-mark ${Net_mark_down}

#UPLOAD

           iptables -D POSTROUTING -t mangle -o $wan -d 1.1.1.1/32 -j MARK --set-mark ${Net_mark_up} &> /dev/null
           iptables -A POSTROUTING -t mangle -o $wan -d 1.1.1.1/32 -j MARK --set-mark ${Net_mark_up}
           iptables -D POSTROUTING -t mangle -o $wan -d 1.0.0.1/32 -j MARK --set-mark ${Net_mark_up} &> /dev/null
           iptables -A POSTROUTING -t mangle -o $wan -d 1.0.0.1/32 -j MARK --set-mark ${Net_mark_up}
           ip6tables -D POSTROUTING -t mangle -o $wan -d 2606:4700:4700::1111 -j MARK --set-mark ${Net_mark_up} &> /dev/null
           ip6tables -A POSTROUTING -t mangle -o $wan -d 2606:4700:4700::1111 -j MARK --set-mark ${Net_mark_up}
           ip6tables -D POSTROUTING -t mangle -o $wan -d 2606:4700:4700::1001 -j MARK --set-mark ${Net_mark_up} &> /dev/null
           ip6tables -A POSTROUTING -t mangle -o $wan -d 2606:4700:4700::1001 -j MARK --set-mark ${Net_mark_up}

I have noticed that after adding these rules, in QoS statistics I still see very little "Net Control" data in Download. I do see "Net Control" data increasing for Upload however.

 

[FreshJR]

@morden

192.168.1.100 should be changed to the local ip address of the device that is going to be directed through the VPN tunnel

/32 means 1 device, see CIDR calculator section in the initial posts

Thanks for the response FreshJR. As I have one machine that I would like to redirect to the "File Transferring" category, do I need to do the following:

1. Create a TC Filter for this APP in the "tc_redirection_down_rules"
2. Create a TC Filter for this APP in the "tc_redirection_up_rules"
3. Create an iptables -D & - A in the "DOWNLOAD (INCOMING TRAFFIC) CUSTOM RULES START HERE" section for this specific machine
4. Create an iptables -D & - A in the "UPLOAD (UPLOAD TRAFFIC) CUSTOM RULES START HERE" section for this specific machine

You only need to perform steps 3 & 4 if want to categorize all traffic from a specific machine into "File Transferring".

In fact rule template #2 within the scripts header description does exactly what you seek to accomplish.


@strangeluck

DNS responses will follow a different path through iptables depending if stubby is installed on the router or on the PC.

Eg.
If Router makes the request.  The DNS response  will follow this path. PREROUTING -> INPUT  (this is higher priority than net control as this traffic bypasses QOS limiting entirely).
If the PC makes the request.  The DNS response will follow this path. PREROUTING -> FORWARD -> POSTROUTING

If stubby is installed on the PC try either of these two sets of rules to visually see via the system log if your iptable rule is hitting correctly.

iptables -D POSTROUTING -t mangle -o br0 -s 1.1.1.1 -j LOG
iptables -A POSTROUTING -t mangle -o br0 -s 1.1.1.1 -j LOG

iptables -D POSTROUTING -t mangle -o br0 -s 1.1.1.1 -m limit --limit 1/s -j LOG
iptables -A POSTROUTING -t mangle -o br0 -s 1.1.1.1 -m limit --limit 1/s -j LOG

the first set of rules logs every matching packet.
the second set of rules is the same as the first but it rate limits entries into system log as to not freeze up the router or spam the log if there are too many simultaneous entries.

If your rule is not hitting at all, then you can log all br0 traffic destined to a very low traffic, stubby enabled, PC and pick out DNS resposes.
You can then try to visually see why your rule wasn't hitting correctly with the original fields specified.

 

[strangeluck]

DNS responses will follow a different path through iptables depending if stubby is installed on the router or on the PC.

Eg.
If Router makes the request.  The DNS response  will follow this path. PREROUTING -> INPUT  (this is higher priority than net control as this traffic bypasses QOS limiting entirely).
If the PC makes the request.  The DNS response will follow this path. PREROUTING -> FORWARD -> POSTROUTING

Thank you for the response. Stubby is running on the router and the higher priority must be why I am not seeing much net control traffic in the monitor. Appreciate the info. Not that it would likely affect performance, but it makes me feel better knowing that secure dns queries aren't being lumped in with web surfing.

 

[JohnSmith]

You only need to perform steps 3 & 4 if want to categorize all traffic from a specific machine into "File Transferring".

In fact rule template #2 within the scripts header description does exactly what you seek to accomplish.

Thanks for the response FreshJR.

So I added the following lines to my "DOWNLOAD CUSTOM RULES" - "IP address is valid, just removed for security, and NO quotes in actual line"

iptables -D POSTROUTING -t mangle -o br0 -d "IP Address"/32 -j MARK --set-mark ${Downloads_mark_down} &> /dev/null

iptables -A POSTROUTING -t mangle -o br0 -d "IP Address"/32 -j MARK --set-mark ${Downloads_mark_down}

The traffic still wants to go into the "Web Surfing" Category. I thought that with the above command, basically all traffic being downloaded to this IP address should go to the "File Transferring" Category now. Any idea why it does not?

 

[Kingp1n]

@FreshJR , is there a rule I can create to add to the script for my Nest Hello doorbell? It seems when I set the video quality to "high" it seems it drops the wifi more often than when it's set to normal quality. According to some forums, this can be a problem with Nest however, I was trying to test out a specific rule I may be able to add to your script. It's currently connected to my 2.4 wifi and I have not tried the 5G at this time. Thanks!

 

[FreshJR]

@JohnSmith

Are you sure you are using the correct IP?? I just retested the rule and it still works.

Send me the output of

iptables -vL -t mangle

Don't worry about posting the IP. The IP in the rule is your local LAN ip, not your public internet facing IP.

Everyone has the same range for the local IP's and they contain no identifiable information.

@Kingp1n

you can stick it into netcontrol and see if it improves.

Either the wifi is flakey on it, or your upload speed is not sufficient enough for high quality.

 

[JohnSmith]

@JohnSmith

Are you sure you are using the correct IP?? I just retested the rule and it still works.

Send me the output of

iptables -vL -t mangle

Don't worry about posting the IP. The IP in the rule is your local LAN ip, not your public internet facing IP.

Everyone has the same range for the local IP's and they contain no identifiable information.

Here you go...


ASUSWRT-Merlin RT-AC3100 384.8-alpha1-g9ac9c80d7 Tue Oct 23 04:17:59 UTC 2018
admin@XXXXXXXX:/tmp/home/root# iptables -vL -t mangle
Chain PREROUTING (policy ACCEPT 9576K packets, 9907M bytes)
pkts bytes target prot opt in out source destination

Chain INPUT (policy ACCEPT 289K packets, 40M bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 9224K packets, 9846M bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 227K packets, 65M bytes)
pkts bytes target prot opt in out source destination

Chain POSTROUTING (policy ACCEPT 9451K packets, 9911M bytes)
pkts bytes target prot opt in out source destination

Chain BWDPI_FILTER (0 references)
pkts bytes target prot opt in out source destination

 

[FreshJR]

Here you go...

There weren't more entries in the chains?

As it stands neither the script nor QOS seem to be enabled from the above entries.

Does system log show the following?

Oct 30 12:14:40 adaptive QOS: Applying - Iptable Down Rules
Oct 30 12:14:40 adaptive QOS: Applying - Iptable Up   Rules (eth0)
Oct 30 12:14:40 adaptive QOS: TC Modification Delayed Start (5min)
Oct 30 12:19:44 adaptive QOS: Applying  TC Down Rules
Oct 30 12:19:44 adaptive QOS: Applying  TC Up   Rules
Oct 30 12:19:44 adaptive QOS: Modifying TC Class Rates

 

[JohnSmith]

There weren't more entries in the chains?

As it stands neither the script nor QOS seem to be enabled from the above entries.

that is weird, as I just tried it again, and it came back with the same result.

Using the command:

/jffs/scripts/FreshJR_QOS -debug

I get:

admin@XXXXXXXX:/tmp/home/root# /jffs/scripts/FreshJR_QOS -debug
adaptive QOS: Undf Prio: 2
adaptive QOS: Undf FlowID: 1:13
adaptive QOS: Classes Present: 8
adaptive QOS: Down Band: 184320
adaptive QOS: Up Band : 14336
adaptive QOS: ***********
adaptive QOS: Net = 1:10
adaptive QOS: VOIP = 1:11
adaptive QOS: Gaming = 1:12
adaptive QOS: Others = 1:13
adaptive QOS: Web = 1:14
adaptive QOS: Streaming = 1:15
adaptive QOS: Downloads = 1:16
adaptive QOS: Defaults = 1:17
adaptive QOS: ***********
adaptive QOS: Downrates -- 9216, 36864, 27648, 18432, 18432, 55296, 9216, 9216
adaptive QOS: Downbursts -- 11197b, 44789b, 22394b, 11195b, 7994b, 6386b, 3197b, 3197b
adaptive QOS: DownCbursts -- 225Kb, 225Kb, 225Kb, 225Kb, 225Kb, 225Kb, 225Kb, 225Kb
adaptive QOS: ***********
adaptive QOS: Uprates -- 716, 2867, 2150, 4300, 1433, 1433, 716, 716
adaptive QOS: Upbursts -- 3198b, 3198b, 3198b, 3198b, 3198b, 3198b, 3198b, 3198b
adaptive QOS: UpCbursts -- 17593b, 17593b, 17593b, 17593b, 17593b, 17593b, 17593b, 17593b

Also, the System Log only shows the following:

Oct 30 08:29:02 adaptive QOS: Scheduled Persistence Check -> Reapplying Changes
Oct 30 08:29:05 adaptive QOS: Applying  TC Down Rules
Oct 30 08:29:05 adaptive QOS: Applying  TC Up   Rules
Oct 30 08:29:05 adaptive QOS: Modifying TC Class Rates
Oct 30 08:29:05 kernel: HTB: quantum of class 10011 is big. Consider r2q change.
Oct 30 08:29:05 kernel: HTB: quantum of class 10012 is big. Consider r2q change.
Oct 30 08:29:05 kernel: HTB: quantum of class 10013 is big. Consider r2q change.
Oct 30 08:29:05 kernel: HTB: quantum of class 10014 is big. Consider r2q change.
Oct 30 08:29:05 kernel: HTB: quantum of class 10015 is big. Consider r2q change.

and that was only after issuing the following command, as FreshJR QOS does not seem to start on its own:

/jffs/scripts/FreshJR_QOS -check

Here is what I got on a cold reboot this morning in the System Log:

Oct 30 08:25:50 rc_service: httpd 347:notify_rc restart_qos;restart_firewall
Oct 30 08:26:05 BWDPI: fun bitmap = 1ff
Oct 30 08:26:06 A.QoS: qos_count=0, qos_check=0
Oct 30 08:26:06 A.QoS: qos rule is less than 22
Oct 30 08:26:06 A.QoS: restart A.QoS because set_qos_conf / set_qos_on / setup rule fail
Oct 30 08:26:07 A.QoS: qos_count=0, qos_check=1
Oct 30 08:26:10 A.QoS: qos rule is less than 22
Oct 30 08:26:10 A.QoS: restart A.QoS because set_qos_conf / set_qos_on / setup rule fail
Oct 30 08:26:11 A.QoS: qos_count=1, qos_check=1
Oct 30 08:26:14 A.QoS: qos rule is less than 22
Oct 30 08:26:14 A.QoS: restart A.QoS because set_qos_conf / set_qos_on / setup rule fail
Oct 30 08:26:15 A.QoS: qos_count=2, qos_check=1
Oct 30 08:26:16 A.QoS: qos rule is less than 22
Oct 30 08:26:16 A.QoS: restart A.QoS because set_qos_conf / set_qos_on / setup rule fail
Oct 30 08:26:16 miniupnpd[29449]: shutting down MiniUPnPd
Oct 30 08:26:16 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
Oct 30 08:26:16 custom_script: Running /jffs/scripts/firewall-start (args: eth0)
Oct 30 08:26:16 miniupnpd[31674]: HTTP listening on port 54876
Oct 30 08:26:16 miniupnpd[31674]: Listening for NAT-PMP/PCP traffic on port 5351
Oct 30 08:26:17 admin: /jffs/scripts/firewall-start: Configuring wl0.1

 

[FreshJR]

that is weird, as I just tried it again, and it came back with the same result.

Im stumped.

The TC portion of the modifications is working correctly.
The iptable portion of modifications is non existant.

These are the results for a more or less vanilla configuration.

admin@RT-AC68U:/tmp/home/root# iptables -vL -t mangle
Chain PREROUTING (policy ACCEPT 219K packets, 702M bytes)
 pkts bytes target     prot opt in     out     source               destination
 1170  484K BWDPI_FILTER  udp  --  eth0   any     anywhere             anywhere
Chain INPUT (policy ACCEPT 196K packets, 698M bytes)
 pkts bytes target     prot opt in     out     source               destination
Chain FORWARD (policy ACCEPT 22684 packets, 3793K bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 MARK       all  --  any    br0     192.168.2.0/24       192.168.2.0/24       MARK xset 0x1/0x7
Chain OUTPUT (policy ACCEPT 352K packets, 55M bytes)
 pkts bytes target     prot opt in     out     source               destination
Chain POSTROUTING (policy ACCEPT 375K packets, 59M bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 MARK       udp  --  any    br0     anywhere             anywhere             udp spt:4500 MARK set 0x80060001
    0     0 ACCEPT     udp  --  any    br0     anywhere             anywhere             udp spt:4500
    0     0 MARK       udp  --  any    eth0    anywhere             anywhere             udp dpt:4500 MARK set 0x40060001
    0     0 ACCEPT     udp  --  any    eth0    anywhere             anywhere             udp dpt:4500
    0     0 MARK       udp  --  any    br0     anywhere             anywhere             udp spt:500 MARK set 0x80060001
    0     0 ACCEPT     udp  --  any    br0     anywhere             anywhere             udp spt:500
    0     0 MARK       udp  --  any    eth0    anywhere             anywhere             udp dpt:500 MARK set 0x40060001
    0     0 ACCEPT     udp  --  any    eth0    anywhere             anywhere             udp dpt:500
    0     0 MARK       udp  --  any    br0     anywhere             anywhere             udp dpts:16384:16415 MARK set 0x80060001
    0     0 MARK       tcp  --  any    br0     anywhere             anywhere             mark match 0x80080000/0xc03f0000 tcp spt:www MARK set 0x803f0001
    0     0 MARK       tcp  --  any    br0     anywhere             anywhere             mark match 0x80080000/0xc03f0000 tcp spt:https MARK set 0x803f0001
    0     0 MARK       udp  --  any    eth0    anywhere             anywhere             udp spts:16384:16415 MARK set 0x40060001
    0     0 MARK       tcp  --  any    eth0    anywhere             anywhere             mark match 0x40080000/0xc03f0000 tcp spt:www MARK set 0x403f0001
    0     0 MARK       tcp  --  any    eth0    anywhere             anywhere             mark match 0x40080000/0xc03f0000 tcp spt:https MARK set 0x403f0001
Chain BWDPI_FILTER (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DROP       udp  --  eth0   any     anywhere             anywhere             udp spt:bootpc dpt:bootps
    3   984 DROP       udp  --  eth0   any     anywhere             anywhere             udp spt:bootps dpt:bootpc

 

[JohnSmith]

Im stumped.

The TC portion of the modifications is working correctly.
The iptable portion of modifications is non existant.


[/code]

Thanks for the output FreshJR so I can see what it should look like.

Two possible things in my setup could be accountable for this issue that I can think of so far:

1. Currently using the latest Merlin Alpha version of ASUSWRT-Merlin as per my signature, which may be a culprit.

2. I also have a guest wireless network setup, that uses a "firewall-start" file as well. I noticed your script tries to add "FreshJR_QOS" info in there to start, but my "firewall-start" file does not have that in it. Wondering if this could have anything to do with it?

 

[FreshJR]

2. I also have a guest wireless network setup, that uses a "firewall-start" file as well. I noticed your script tries to add "FreshJR_QOS" info in there to start, but my "firewall-start" file does not have that in it. Wondering if this could have anything to do with it?

That is exactally the issue I am seeing from your cold boot system log.
The firewall-start entry for FreshQOS is missing so the script never runs.

When you run the initial

./FreshJR_QOS -install command line, it does a few to create a firewall-start file

If firewall-start exists and has a correct header
--> add FreshQOS into firewall start
If firewall-start exists and has an incorrect header
--> fix header
--> add FreshQOS into firewall start
If firewall-start does not exist
--> create firewall-start
--> set permissions of firewall-start
--> create correct header of firewall-start
--> add FreshQOS into firewall start.

If you installed your other script after FreshQOS, its likely you are overwriting the FreshQOS entry.

By default I never delete the firewall-start file or remove any existing entries (besides mine) when installing this script.

I simply append the FreshQOS entry into firewall-start if it exists. You have to fix that issue.

Simply rerun

/jffs/scripts/FreshJR_QOS -install

and it should correct the entry.

--

Side note, your iptables configuration is also missing additional entries that should be there from Asus and not from my script. Those are also required for QOS. Are you sure you are not wiping all of iptables with your other script??

--

The scheduled persistance check that you saw occurring is triggered by a scheduler at 3:30 and not a firewall-start entry.

The scheduled persistence check only checks TC structure has not been modified. It does not attempt to parse iptables for entries. (I could change it so it delete and recreate the relevate iptable entries if the TC structure gets changed in future releases of the script but it hasn't been a problem too date)

 

[JohnSmith]

That is exactally the issue I am seeing from your cold boot system log.
The firewall-start entry for FreshQOS is missing so the script never runs.

When you run the initial

./FreshJR_QOS -install command line, it does a few to create a firewall-start file

If firewall-start exists and has a correct header
--> add FreshQOS into firewall start
If firewall-start exists and has an incorrect header
--> fix header
--> add FreshQOS into firewall start
If firewall-start does not exist
--> create firewall-start
--> set permissions of firewall-start
--> create correct header of firewall-start
--> add FreshQOS into firewall start.

If you installed your other script after FreshQOS, its likely you are overwriting the FreshQOS entry.

By default I never delete the firewall-start file or remove any existing entries (besides mine) when installing this script.

I simply append the FreshQOS entry into firewall-start if it exists. You have to fix that issue.

Simply rerun

/jffs/scripts/FreshJR_QOS -install

and it should correct the entry.

--

Side note, your iptables configuration is also missing additional entries that should be there from Asus and not from my script. Those are also required for QOS. Are you sure you are not wiping all of iptables with your other script??

--

The scheduled persistance check that you saw occurring is triggered by a scheduler at 3:30 and not a firewall-start entry.

The scheduled persistence check only checks TC structure has not been modified. It does not attempt to parse iptables for entries. (I could change it so it delete and recreate the relevate iptable entries if the TC structure gets changed in future releases of the script but it hasn't been a problem too date)

Thanks for all your help FreshJR. I believe I am getting closer to resolving this. I now have entries in the POSTROUTING when running:

iptables -vL -t mangle

Just a quick note, that on your

/jffs/scripts/FreshJR_QOS -install

it did go and add the line

/jffs/scripts/FreshJR_QOS -start $1 &

but it added it to the very end of the "firewall-start" file, which unfortunately has

exit 0

which would finish the executing of the code, and would not run your command. I moved your command above "exit 0", and it works now.

Not sure if in your script, you can test for "exit 0" at the end of the "firewall-start" script, and if so, to add your line above that so it gets executed


I tried to add the code that I am using for the guest network, but it would not allow me to post it here, but here is the link that I got it from originally:

https://www.snbforums.com/threads/guest-networks-and-dhcp.14141/page-2#post-286748

 

[JohnSmith]

Appreciate the dedication!! I will update the first post stating that reading the first three posts and last few pages in this thread is sufficient!

The reason that above situation happens is that appdb gives the original destination of traffic per the Asus default unmodified setup.

After installing the script with default settings, it redirected most of "Net Control" into Web Surfing. This is because most https + other encrypted traffic was sorted into "Net Control" and I didn't agree with that priority level!

If you have more questions, dont hesitate to ask! Hope this explanation was clear.

EDIT: You can still redirect it into any category you desire with the above mark & prio!

( Maybe I should remove the "Cat: " field to reduce future confusion or rename it "Original QOS Cat before script:" ?? )

Just saw what you wrote here at the end, and I like the idea of it saying "Original QOS Cat before FreshJR script:"

Side Note: No code changed where it says DONT Modify, but I decided to test this by updating your ECHO lines, and it works for me:

admin@XXXXXXXX:/jffs/scripts# /jffs/scripts/FreshJR_QOS -appdb "Lets Encrypt"
Lets Encrypt
 Original QOS Cat before FreshJR script:  Net Control
 Mark: 0x801400c2 0xc03fffff
 Prio: 22

 

[JohnSmith]

So FreshJR, I was able to get my Downloads into the "File Transferring/Downloads" Classification for this ONE computer from https://www.snbforums.com/threads/r...and-inner-workings.36836/page-107#post-440141 , but my Uploads for "Lets Encrypt" still go into "Web Surfing", instead of "File Transferring/Downloads"

Here are the two attempts I tried to make this work under the UPLOAD Custom Rules (IP Address marked out):

iptables -D POSTROUTING -t mangle -o $wan -s X.X.X.X/32 -m mark --mark 0x801400c2/0xc03fffff -p tcp --dport 563 -j MARK --set-mark ${Downloads_mark_up} &> /dev/null
iptables -A POSTROUTING -t mangle -o $wan -s X.X.X.X/32 -m mark --mark 0x801400c2/0xc03fffff -p tcp --dport 563 -j MARK --set-mark ${Downloads_mark_up}

iptables -D POSTROUTING -t mangle -o $wan -s X.X.X.X/32 -m mark --mark 0x801400c2/0xc03fffff -p tcp --dport 49152:65535 -j MARK --set-mark ${Downloads_mark_up} &> /dev/null
iptables -A POSTROUTING -t mangle -o $wan -s X.X.X.X/32 -m mark --mark 0x801400c2/0xc03fffff -p tcp --dport 49152:65535 -j MARK --set-mark ${Downloads_mark_up}

Neither of these classified the packets for this computer to the right classification on the Upload.

The only way I could make this work was to do the following on the Upload, and then Upload Classification work by putting "Web Surfing" into "Downloads" for this computer:

iptables -D POSTROUTING -t mangle -o $wan -s X.X.X.X/32 -j MARK --set-mark ${Downloads_mark_up} &> /dev/null
iptables -A POSTROUTING -t mangle -o $wan -s X.X.X.X/32 -j MARK --set-mark ${Downloads_mark_up}

FreshJR, and thoughts on troubleshooting this?

BTW Thanks for all your time and dedication to this project and helping others as well as myself.

 

[FreshJR]

FreshJR, and thoughts on troubleshooting this?

BTW Thanks for all your time and dedication to this project and helping others as well as myself.

You sure you didn't mess up dport & sport on the upload rule?
You sure its tcp instead of udp?

I wrote a pretty comprehensive guide for creating port rules available via link located within the first three posts.