I was planning to do something like this earlier to fix the device priority but I stopped.
Asus already dynamically modifies the TC structure as devices enter & leave the network.
Code:
1:1 - root HTB
1:10 - NetControl
10:1 - NetControl HTB
10:2 - device1
10:3 - device2
10:4 - device3
1:11 - VoOP
11:1 - VoIP HTB
11:2 - device1
11:3 - device2
11:4 - device3
1:12
1:13
1:14
1:15
1:16
I was planning to intercept Asus's TC commands for the sub structure and fix the rate/ciels/ & priority for each device to my liking.
I find that the TC parameters Asus is using to dynamically implement the per device priority in the substructure leads to a terrible end result (this is my opinion).
Calculating and changing rate/priority per networked device via the existing structure wasn't an issue at all.
I was going to piggyback off RMerlins fakeTC to intercept the commands and run some calculations to make it work. (In doing that, I did find that the QOS commands issued from the bwdpi engine issues are time sensitive before it throws errors and wipes the entire TC structure and restarts, I did find a way to work around that).
Everything was going good but I ran into an issue.
If my iPhone was device2. Once it left the network, the next device that connected to the network would will replace my iPhone as device2 instead of being assigned device4.
They are filting devices via an ID assigned within the mark and not filtering by device IP. I will pull up a picture of the mark bitwise structure I created and post it here so it can be clear.
Since I couldn't figure out which mark corresponds with which device (as the correlation is random and tracked internally somewhere), I stopped trying at this point to fix it.
---
I see that you are trying to do it in the reverse order and that will work even better. (I was trying to maintain the existing structure with different parameters, but do perfer it in the reverse order as you mentioned).
The reason I perfer first by device and they by traffic, is that even if traffic identification is poor. Each device will always have its own guaranteed bandwidth and will use it like having a dedicated connection even if identification completely fails. The traffic prioritization that would be occuring in the subclass would be nice on per machine traffic performance but blips in performance wouldn't make or break QOS quality.
A word of advice is you will HAVE to use a different set of class IDs for each perIP class and also for the all the perTraffic class within each perIP class so Asus dynamic modification do not interfere with your structure.
(We could block all of Asus dynamic modifcations via fakeTC but you would then also have to cross your fingers and hope Asus doesn't try to wipe the new structure).
My approach would be to use fakeTC to block the Asus structure entirely and then create our own. The issue is that the bwdpi executable that issues the TC commands would definitely not be happy.
If someone can comment out the QOS check, I would be happy to join you in creating this new QOS structure that dynamically adjusts based on devices present on the network.
Both Wifi-Calling and FaceTime were unidentified. I created special rules for both those cases. Try making some calls and see if the VoIP category grows. I believe Skype was correctly identified during the time I last tested it, but that was a few years ago.
@JohnSmith
Why do you keep using so many filtering elements?
Eg.
Code:
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}
Could be condensed into this
Code:
iptables -D POSTROUTING -t mangle -o $wan -m mark --mark 0x801400c2/0xc03fffff -j MARK --set-mark ${Downloads_mark_up} &> /dev/null
iptables -A POSTROUTING -t mangle -o $wan -m mark --mark 0x801400c2/0xc03fffff -j MARK --set-mark ${Downloads_mark_up}
And has higher chance of the match not being void by a mismatch with the source IP, transfer protocol, or ports used.
Go ahead and use this to log packets.
Code:
iptables -D POSTROUTING -t mangle -o $wan -m mark --mark 0x801400c2/0xc03fffff -m limit --limit 1/s -j LOG &> /dev/null
iptables -A POSTROUTING -t mangle -o $wan -m mark --mark 0x801400c2/0xc03fffff -m limit --limit 1/s -j LOG