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

[1219chicho]

You need the bandwidth division rules

What do you mean Vex?

 

[Vexira]

The 90% rules for bandwidth thast what fixed it for me

 

[1219chicho]

The 90% rules for bandwidth thast what fixed it for me

Wanna do it for me on TeamViewer because I tried it don't work

 

[Vexira]

kk

 

[1219chicho]

kk

Actually isn't it just the script you sent me replace with that

 

[Vexira]

Just pasep it in the same section I did

 

[FreshJR]

Fresh i am getting this log here if you can look at it

Does this appear everytime restart QOS? If it is repeatable we can generate a debug log and see if it's the script sending malformed commands to TC.

I will send you steps to generate a debug log in PM if you can get this message to be repeatable upon qos start. It's quick and simple 3 commands to generate the log.


As for the other messages, I see a pretty big issue with this one. I had the same message before with QOS not working.

 tdts_core_rule_parsing_trf_load()

That error means it is not reading the TrendMicro's adaptive QOS definition file. The QOS script did not cause this, but rather some filesystem change from 380 -> 382.

I think the following steps fixed the rule database when I had the same issue.

Router restart
Administration -> Firmware Upgrade -> Signature Version -> Check

Try these steps, and see your error system log. If not, I saw some post by RMerlin how to delete old database, but hopefully this will not be necessary to look up.

@Vex, I did not have time to test those rules, so it's not ready yet. I am able to post what they should look like and you can test it, but I perfer not to have non-working commands floating around

 

[1219chicho]

Does this appear everytime restart QOS? If it is repeatable we can generate a debug log and see if it's the script sending malformed commands to TC.

I will send you steps to generate a debug log in PM if you can get this message to be repeatable upon qos start. It's quick and simple 3 commands to generate the log.


As for the other messages, I see a pretty big issue with this one. I had the same message before with QOS not working.

 tdts_core_rule_parsing_trf_load()

That error means it is not reading the TrendMicro's adaptive QOS definition file. The QOS script did not cause this, but rather some filesystem change from 380 -> 382.

I think the following steps fixed the rule database when I had the same issue.

Router restart
Administration -> Firmware Upgrade -> Signature Version -> Check

Try these steps, and see your error system log. If not, I saw some post by RMerlin how to delete old database, but hopefully this will not be necessary to look up.

@Vex, I did not have time to test those rules, so it's not ready yet. I am able to post what they should look like and you can test it, but I perfer not to have non-working commands floating around

Ok I'll wait for pm Fresh and will also try out what you said with signature check when I get home tonight and keep you updated thanks for the prompt response

 

[FreshJR]

For the gaming rules, I need an outgoing source of unidentified upload traffic to test if the rule I created is functioning.

Honestly, the recent definitions are kick butt. Many things are NOT misclassified, and it even picks up obscure games I am testing against.

If you find a source let me know. If not, then we can currently move unidentified download traffic on designating gaming devices into "Gaming".

 

[1219chicho]

For the gaming rules, I need an outgoing source of unidentified upload traffic to test if the rule I created is functioning.

Honestly, the recent definitions are kick butt. Many things are NOT misclassified, and it even picks up obscure games I am testing against.

If you find a source let me know. If not, then we can currently move unidentified download traffic on designating gaming devices into "Gaming".

You mean on the beta tc you just released?

 

[FreshJR]

Gaming rules will apply to both. Both TC's have the same exact functionality and behavior. They just implement the commands a different way.

I just found a source of unidentified upload traffic so we are good.

 

[1219chicho]

Ok great once you getting going please let me know Fresh

 

[M@rco]

First page is outdated. All links say OLD and they are not compatible with current firmware.

By 'current firmware' you mean 382.x and up, I assume? Or is the beta also suitable for 380.x?

Unfortunately, I'm still unable, for unknown reasons, to use QoS on my RT-AC68U. It simply doesn't start and we can't find the cause. So I hope you will leave a link to FreshJR_QoS v1.92 for those who are unable to upgrade, like a 'legacy' version. I reverted to 380.69_2 to be able to use QoS and your script, and it still works like a charm.

 

[FreshJR]

By 'current firmware' you mean 382.x and up, I assume? Or is the beta also suitable for 380.x?

Unfortunately, I'm still unable, for unknown reasons, to use QoS on my RT-AC68U. It simply doesn't start and we can't find the cause. So I hope you will leave a link to FreshJR_QoS v1.92 for those who are unable to upgrade, like a 'legacy' version. I reverted to 380.69_2 to be able to use QoS and your script, and it still works like a charm.

Beta is NOT backwards compatible with anything before 382.x.
If you are on 380 remain on v1.92

So

v380 --> script version v1.92
v382 --> script version v382 or BETA1

--

So after 3 hours of debugging the upload rule. It turns out my "Unidentified Upload Traffic" was actually identified as "Others" and not "Default" redirected to -> "Others". That's why the gaming rule was not redirecting "unidentified" traffic into "gaming", because there was no actual "unidentified" traffic.

Whoever wants the gaming rules will have to find some upload traffic I can generate that will actually be unidentified. Does not have to be Gaming traffic, just unidentified.

I do not want to post untested rules as I have no traffic to test them with.

If there are no games with unidentified upload traffic then these rules are pointless. QOS is already identifying these games correctly.

 

[FreshJR]

Wow, whoever is in charge of the database post v382 needs a raise. Even obscure F2P games in BETA are recognized.

Here are the gaming rules. I'm pretty sure they work, but the upload rule hasn't been extensively tested.

Download:

realtc filter add dev br0 protocol all prio 2 u32 match mark 0x80000000 0x8000ffff match ip dst 192.168.1.100/30 flowid ${Gaming}

Upload:

iptables -D POSTROUTING -t mangle -o eth0 -s 192.168.1.100/30 -m mark --mark 0x40000000/0x4000ffff -j MARK --set-mark ${Gaming_mark}
iptables -A POSTROUTING -t mangle -o eth0 -s 192.168.1.100/30 -m mark --mark 0x40000000/0x4000ffff -j MARK --set-mark ${Gaming_mark}

So clarify. What this does, is that it routes "unidentified/default" traffic from clients 192.168.1.100/30, and routes that "unidentified/default" traffic into the "gaming" category instead of the "others" category as per script defaults.

---

I currently see that the community is also split on running firmware v380 (and the old script) and firmware v382 (and the new script). There are QOS differences between the two.

If you are on the old script, make sure the rule is prio 1.
If you are on the new script, make sure the rule is prio 2 (as shown in the example).

192.168.1.100/30 translates to clients (192.168.1.100 - 192.168.1.103).
Use the cidr calculator to generate your own ranges. http://www.subnet-calculator.com/cidr.php


---

If you want to use ultra aggressive rules, you can do this (I dont recommend this, but it might be ok for consoles)

Download:

realtc filter add dev br0 protocol all prio 2 u32 match ip dst 192.168.100/30 flowid ${Gaming}

Upload:

iptables -D POSTROUTING -t mangle -o eth0 -s 192.168.1.100/30  -j MARK --set-mark ${Gaming_mark}
iptables -A POSTROUTING -t mangle -o eth0 -s 192.168.1.100/30  -j MARK --set-mark ${Gaming_mark}

What this ultra aggressive rule will do is that it will take all traffic from the defined clients (192.168.1.100 - 192.168.1.103) and stick ALL traffic from those clients into gaming. No classification of traffic will be at all within that range. It will evaluate all traffic from those LAN devices as 100% gaming.

If the standard QOS definitions correctly separate "Game Downloads" into File Transfers and "Game Traffic" into Gaming, then using this ultra aggressive version, even on gaming only device, is going to produce a lot worse gaming QOS performance then using the recommend version, since game updates/downloads would then compete against actual game traffic.

---

Obviously to use these rules your gaming devices need to have static IP or the router has to be set to assign them a defined IP upon their dhcp request. The IP of your gaming devices has to be within the rules defined range. Non gaming devices should not have IP's within this range.

The rules go into the script corresponding to the download/upload section with the script. Do not reverse it.

---

From my latest experience, I do not think this is necessary, but it can't hurt. Virtually 100% of traffic is identified correctly lately.

 

[Vexira]

Wow, whoever is in charge of the database post v382 needs a raise. Even obscure F2P games in BETA are recognized.

Here are the gaming rules. I'm pretty sure they work, but the upload rule hasn't been extensively tested.

Download:

realtc filter add dev br0 protocol all prio 2 u32 match mark 0x80000000 0x8000ffff match ip dst 192.168.1.100/30 flowid ${Gaming}

Upload:

iptables -D POSTROUTING -t mangle -o eth0 -s 192.168.1.100/30 -m mark --mark 0x40000000/0x4000ffff -j MARK --set-mark ${Gaming_mark}
iptables -A POSTROUTING -t mangle -o eth0 -s 192.168.1.100/30 -m mark --mark 0x40000000/0x4000ffff -j MARK --set-mark ${Gaming_mark}

So clarify. What this does, is that it routes "unidentified/default" traffic from clients 192.168.1.100/30, and routes that "unidentified/default" traffic into the "gaming" category instead of the "others" category as per script defaults.

---

I currently see that the community is also split on running firmware v380 (and the old script) and firmware v382 (and the new script). There are QOS differences between the two.

If you are on the old script, make sure the rule is prio 1.
If you are on the new script, make sure the rule is prio 2 (as shown in the example).

192.168.1.100/30 translates to clients (192.168.1.100 - 192.168.1.103).
Use the cidr calculator to generate your own ranges. http://www.subnet-calculator.com/cidr.php


---

If you want to use ultra aggressive rules, you can do this (I dont recommend this, but it might be ok for consoles)

Download:

realtc filter add dev br0 protocol all prio 2 u32 match ip dst 192.168.100/30 flowid ${Gaming}

Upload:

iptables -D POSTROUTING -t mangle -o eth0 -s 192.168.1.100/30  -j MARK --set-mark ${Gaming_mark}
iptables -A POSTROUTING -t mangle -o eth0 -s 192.168.1.100/30  -j MARK --set-mark ${Gaming_mark}

What this ultra aggressive rule will do is that it will take all traffic from the defined clients (192.168.1.100 - 192.168.1.103) and stick ALL traffic from those clients into gaming. No classification of traffic will be at all within that range. It will evaluate all traffic from those LAN devices as 100% gaming.

If the standard QOS definitions correctly separate "Game Downloads" into File Transfers and "Game Traffic" into Gaming, then using this ultra aggressive version, even on gaming only device, is going to produce a lot worse gaming QOS performance then using the recommend version, since game updates/downloads would then compete against actual game traffic.

---

Obviously to use these rules your gaming devices need to have static IP or the router has to be set to assign them a defined IP upon their dhcp request. The IP of your gaming devices has to be within the rules defined range. Non gaming devices should not have IP's within this range.

The rules go into the script corresponding to the download/upload section with the script. Do not reverse it.

---

From my latest experience, I do not think this is necessary, but it can't hurt. Virtually 100% of traffic is identified correctly lately.

could that concept be appkied to video streaming and an ip tv box or chome cast?

 

[FreshJR]

could that concept be appkied to video streaming and an ip tv box or chome cast?

The second ultra aggressive rule? Of course...

But you know... the "ultra aggressive" rule has been in the template for years now......

 

[RMerlin]

Wow, whoever is in charge of the database post v382 needs a raise. Even obscure F2P games in BETA are recognized.

AFAIK, these are built for Asus by Trend Micro themselves.

 

[FreshJR]

AFAIK, these are built for Asus by Trend Micro themselves.

Yes I know it's trend micro but the newest ones are spot on, compared to a few years ago.

 

[Vexira]

The second ultra aggressive rule? Of course...

But you know... the "ultra aggressive" rule has been in the template for years now......

So i could use that rule slightly changed to do the streaming, without a port number on a single ip adress.