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

[Sinner]

omg sweet ty

 

[Kingp1n]

@FreshJR I'm currently using the compatible version since I switched back to stock asus due to trying out AIMesh (aka AIMess haha), not sure how I feel about it yet!

I did have a question for using your script and connecting my gaming devices (xbox/ps4) to either a 2.4 or 5ghz connection. My question is does it matter whether I connect my device to either 2.4 or 5ghz ? Again, due to my setup, I connect my devices wireless and your script has helped so much and I no longer have lag like I used too...

Any input is greatly appreciated.

 

[FreshJR]

5ghz is recommended for all devices but only if they are within close range since signal strength tapers off really fast.

2.4g can be alright for all devices IF your internet speed is slower than 2.4g throughput AND those devices are not planning on doing any local LAN 2 LAN bandwidth intensive transfers.

Eg streaming/file transfers from NAS should all be executed on 5ghz since they will saturate 2.4ghz.

QOS does not care either way.

 

[Kingp1n]

QOS + VPN Client interoperability available via custom rules.

Great news, thanks to @Martineau for providing a VPN server, I have been able to develop another QOS fix.
Some of you ** damn pirates ** are going to be happy with this one.

As you might of noticed, tunneled VPN traffic when the router is acting as a VPN client does not appear on the upload/download portions of QOS.

You have to understand the difference between a router acting as a VPN Server or acting as a VPN Client before attempting to use this rule.

Spoiler: Difference between VPN Client & VPN Server

The router has the ability to act as a VPN Client on behalf of specific LAN devices.

This means that:

1) Local devices connect to the router as normal
2) A portion of these devices (depending on configuration) will have their entire communications forwarded to a private VPN Server **typically paid**
3) The VPN server will fetch/receive data from the destination/website that the local device wanted to communicate with
4) The VPN server will return the data, in encrypted form, to the local device.

This configuration is typically used when you dont want your ISP to snoop on the contents/destination of your traffic.
​

The router also has the ability to act as a VPN Server

This is the reverse of the above situation:

1) You are on a work/public WiFi network and you dont want your work/public network admin to spy on you.
2) Instead of paying for a private VPN Server, you can have your router host one for you, and tunnel your traffic via your local ISP
3) Your traffic will remain private from whatever network you are connected too.
4) As an added bonus, when connecting to your own hosted VPN, you can access your LAN devices just as if you never left your network.

This configuration is typically used when you want to access LAN devices or maintain privacy on a network away from your own.​

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) on QOS.

**THESE RULE ARE NOT APPLICABLE WHEN THE ROUTER IS ACTING AS A VPN SERVER**

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 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 the iprange of your tunneled devices​

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

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 ports of your VPN host/provider.​

Enjoy!

To anyone who this working, are we simply making changes to the script with new rules or do we copy and paste this new rules to the script? I'm trying to setup my VPN client with these new rules ...

 

[FreshJR]

To anyone who this working, are we simply making changes to the script with new rules or do we copy and paste this new rules to the script? I'm trying to setup my VPN client with these new rules ...

Those 2 rules//4 lines are an additional set of entries that need to be added into the existing script.

(You may potentially have more rules/entries depending on the quantity of your VPN clients and their iprange)

Don’t understand what else you can do with these VPN rules besides add them into the script.

 

[Kingp1n]

Those are an additional set of 2 rules//4 entries that need to be added into the existing script.

(You may potentially have more rules depending on your VPN client iprange)



Don’t understand what else you can do with the VPN rules besides add them into the script.

-p udp --dport 25000 should be changed to the ports of your VPN host/provider.

@FreshJR i'm using PIA VPN, and you mentioned the dport 25000 should be changed to ports of the VPN provider I used...the website has the following:
"In order to connect to our service using one of the VPN methods we provide, please verify you can connect over these ports:

• For OpenVPN connections UDP ports 1194, 1197, 1198, 8080, 9201 and 53 as well as TCP ports 502, 501, 443, 110, 80
• L2TP uses UDP 500, 1701, and 4500
• PPTP uses TCP 1723 or Protocol 47 (GRE)"

So, do I replace 25000 to 1194, 1197 etc...? Sorry for such the noob questions man...

 

[FreshJR]

Whichever port you defined in the router.

Your VPN server offers many ports to connect on but as a client you choose a single port for which you want to use for communication.

If your router is not acting as a VPN client on behalf of your local/LAN devices, that section is not for you.

 

[Kingp1n]

Whichever port you defined in the router.

Your VPN server offers many ports to connect on but as a client you can choose which port you want to use for communication.

If your router is not acting as a VPN client on behalf of you local/LAN devices, that section is not for you.

So with this said, is it ok to leave port as 25000? Thanks

 

[FreshJR]

So with this said, is it ok to leave port as 25000? Thanks

no, it has to match your defined port

 

[Kingp1n]

no, it has to match your defined port

Last dumb question of the day (i promise) is there a way i can find out what my define port would be?

 

[FreshJR]

Last dumb question of the day (i promise) is there a way i can find out what my define port would be?

 

[FadgewackeR]

Don't add it another ip to the script... u just need to give your consoles a static ip that fall between these lines:

192.168.2.100 - 192.168.2.103

I've been searching this thread for some time, and really don't like to duplicate work for folk... but here goes:

If I set my consoles static IP's in the DHCP route table as follows (and match the IP in my consoles Network settings), the stock script will work for correct gaming traffic prioritisation without the need to modify the script? I understand that if I want gaming above VOIP, I need to make a change in prioritisation.

Ps4 Pro 192.168.2.100
Ps4 192.168.2.101
PS3 192.168.2.102

Am I understanding this correctly? I usually follow 192.168.1.xxx

Noob question to finish: I assume that only PC games need ports to be prioritised for specific games? A console, is a console and this gaming traffic is differentiated by defined IP attached to MAC?

I'm setting up my 86U tomorrow and currently working blind, but will flash Merlin, get set up as best I can and then look to implement the script once I've breathed life back into the network. I'm sure I'll have a few more questions before long!

 

[Sinner]

I

I've been searching this thread for some time, and really don't like to duplicate work for folk... but here goes:

If I set my consoles static IP's in the DHCP route table as follows (and match the IP in my consoles Network settings), the stock script will work for correct gaming traffic prioritisation without the need to modify the script? I understand that if I want gaming above VOIP, I need to make a change in prioritisation.

Ps4 Pro 192.168.2.100
Ps4 192.168.2.101
PS3 192.168.2.102

Am I understanding this correctly? I usually follow 192.168.1.xxx

Noob question to finish: I assume that only PC games need ports to be prioritised for specific games? A console, is a console and this gaming traffic is differentiated by defined IP attached to MAC?

I'm setting up my 86U tomorrow and currently working blind, but will flash Merlin, get set up as best I can and then look to implement the script once I've breathed life back into the network. I'm sure I'll have a few more questions before long!

I havent messed with the gaming mods but have customized my own script for my particular needs so have an understanding of your question. I believe you can set your static ip to your preference as long as it matches what you have put in the script. Also when doing that as you probably know you should set your statics out of dhcp range. As for your ports question, everything uses ports for different services. The only difference with consoles is alot of the same ports are used for most things on them.

 

[FreshJR]

@FadgewackeR

1) Once you assign the consoles a static DHCP IP, you don’t have to modify their network settings to pull that specific IP. They will be assigned it.

2) You still have to enable the rules in the script after the DCHP assignment. This is all explained in post3.

3) You can still use 192.168.1.xxx, just modify the rule to match.

 

[FadgewackeR]

To be clear, my current router is an N55U. Will be 86U from tomorrow.

Also when doing that as you probably know you should set your statics out of dhcp range.

Every day is a school day... I've always assigned them inside them the DHCP range 192.168.1.2-254. Never had any problems doing it that way with NAS/VPN/Consoles. What is the consequence of assigning them within the DHCP range?

I just reduced my DHCP range to 192.168.1.2-100 for a quick and dirty test as all my static IPs were outside of that range, and pretty much everything fell over

I'll have a read up.

As for your ports question, everything uses ports for different services. The only difference with consoles is a lot of the same ports are used for most things on them.

Got ya. Will I have to assign ports for specific console games, or will the IP allocation and rule/rank take care of that for me?

 

[FadgewackeR]

1) Once you assign the consoles a static DHCP IP, you don’t have to modify their network settings to pull that specific IP. They will be assigned it.

Gotcha. I have always set my console connections up manually and use the static IP address so that I can be sure all's as I require. Seems to work ok, but thanks for the pointer. Anyway, a bit off topic.

2) You still have to enable the rules in the script after the DCHP assignment. This is all explained in post3.

Understood, and what I expected in all honesty. I took what was in the post I originally quoted too literally.

3) You can still use 192.168.1.xxx, just modify the rule to match.

Well understood.

Will get things squared up tomorrow, follow the installation guide and no doubt ask some more stupid questions.

 

[FreshJR]

What is the consequence of assigning them within the DHCP range?

This really depends on the routers behavior.

For the ASUS DHCP server, every device is assigned a DHCP address as a function of their MAC address. (eg. it is not a sequential / incremental assignment scheme)
Two devices can never be assigned a duplicate IP.

Either

1) Asus DHCP is smart enough to not assign a duplicate IP if an existing dhcp lease/assignment exists (no consequence)

or

2) Asus DHCP is dumb and will assign the other device a previously assigned IP (both devices will lose connectivity).

As it stands there is a 0.4% chance of a duplicate assignment so I do not even worry about changing the default DHCP range, and will deal with a duplicate if I encounter it.

I am also leaning on ASUS being smart enough to not assigning duplicate IP's and simply produce a different IP assignment if an overlap is to exist.

Got ya. Will I have to assign ports for specific console games, or will the IP allocation and rule/rank take care of that for me?

No port rules necessary.

I just reduced my DHCP range to 192.168.1.2-100 for a quick and dirty test as all my static IPs were outside of that range, and pretty much everything fell over

When ever making changes to the DHCP range (or assignments) all the affected devices in question and the router have to be turned off, and then powered on to clear previous DHCP lease assignments.

Eg.

Turning off router will revoke all existing dhcp leases.
Turning off device will cause it to request a new dhcp lease.

A lack of power cycle will cause issues as either the router/device will be trying to communicate on a non-valid IP.

 

[FadgewackeR]

Thanks for that. Answered my queries perfectly.

Last one, I promise as this really is off topic...

For the ASUS DHCP server, every device is assigned a DHCP address as a function of their MAC address. (eg. it is not a sequential / incremental assignment scheme)
Two devices can never be assigned a duplicate IP.

So when I have DHCP enabled, every MAC on my network is assigned it's own static IP, and the remote device should connect to the router via that static IP automatically. No need to add any of the MACs to the "Manually Assigned IP around the DHCP list", as due to the IP tie to the MAC, the internally assigned IP should never change?

 

[FreshJR]

If you have statically assigned IPs via the devices themselves, (vs the alternative of assigning the IPs via the router), then those static assignments should be outside the routers DHCP assignment range.

This is because the router will not have prior knowledge of these assignments since technically the IPs were NOT assigned by the router but rather forced by the device itself.

A greater chance of overlap will exist since the DHCP server (in the smart scenario) will not be able to know and deal with potential duplicates.

Those devices are not using the DHCP server for assignments but rather taking the matter into their own hands.

 

[FadgewackeR]

Good explanation. Thanks.