New QoS "tracked connections" feature not showing class info

[route]

The new QoS tracked connections feature is very helpful but under application all I get is "untracked".

I'm using tradional QoS and the pie chart above has activity in the different classes. What is suppose to display under application? It would be nice if it listed the class for each connection.

Edit:
And by class I mean priority class i.e. highest, high, medium, low, lowest

 

[RMerlin]

You need to have the Trend Micro DPI engine enabled for classification to be accomplished. Rejecting the Trend micro EULA or not enabling any of the Trend Micro features will cause that.

 

[route]

Thanks. While I won't be agreeing to the trend micro eula I get lots of usefull information from the port numbers. I just wish it told me the priority classification queue. Do you think it could do that one day?

 

[RMerlin]

Thanks. While I won't be agreeing to the trend micro eula I get lots of usefull information from the port numbers. I just wish it told me the priority classification queue. Do you think it could do that one day?

Doubt it, that would require a specific implementation targeting Traditional QoS, something on which I no longer feel like devoting development time since Traditional QoS is pretty much replaced by Adaptive QoS in Asuswrt.

 

[route]

With this new feature I can see voip rtp data is going untracked under adaptive qos. A lot of bittorrent data is going untracked as well. Adaptive qos is failing at one of the most important things it's suppose to do.

 

[robcore]

With this new feature I can see voip rtp data is going untracked under adaptive qos. A lot of bittorrent data is going untracked as well. Adaptive qos is failing at one of the most important things it's suppose to do.

Check out Freshjr's add-on for adaptive qos classification. No dpi engine can ever be 100 percent correct. Lower layer classification is becoming obsolete in the modern era of encrypted traffic.

As for it not doing its job, I've not found any qos solutions more effective than adaptive via the Merlin implementation.

On that note, @RMerlin this latest release is awesome! I've been playing with various routers and "the wrts," and have found that nothing beats the raw power of a 64 bit processor with hardware acceleration (for my connection, anyway). The 86u is seriously a beast compared to anything else I've tried.

 

[route]

Traditional qos can prioritise my voip calls, although not the way it should. My old $23 adsl router could prioritise my voip calls the proper way. I don't need the router to do too much thinking.

 

[RMerlin]

With this new feature I can see voip rtp data is going untracked under adaptive qos. A lot of bittorrent data is going untracked as well. Adaptive qos is failing at one of the most important things it's suppose to do.

Torrent traffic cannot be 100% reliably tracked because it tries really hard actually to hide itself. That's why most QoS systems will have it end up in the default queue, which is generally a very low priority.

 

[route]

Torrent traffic cannot be 100% reliably tracked because it tries really hard actually to hide itself. That's why most QoS systems will have it end up in the default queue, which is generally a very low priority.

That may be true in some envirionments and adaptive qos does catch quite a bit of it. However, in my home I set the port numbers that bittorrent uses and QoS by port number can catch it 100%. Adaptive QoS not catching voip rtp data is unforgivable. Traditional QoS is very much relevent to anyone that wants reliable QoS.

I agree with Merlin that, unless it's trivial, I wouldn't bother adding features to the track connections display. I'd prefer that traditional QoS be improved by using both sending and receiving ports rather than only receiving ports.

 

[FreshJR]

That may be true in some envirionments and adaptive qos does catch quite a bit of it. However, in my home I set the port numbers that bittorrent uses and QoS by port number can catch it 100%. Adaptive QoS not catching voip rtp data is unforgivable. Traditional QoS is very much relevent to anyone that wants reliable QoS.

I agree with Merlin that, unless it's trivial, I wouldn't bother adding features to the track connections display. I'd prefer that traditional QoS be improved by using both sending and receiving ports rather than only receiving ports.

Did you even read the post that @robcore mentioned?

...I noticed and resolved those issues with AdaptiveQOS a long time ago. Even added functionality for custom port rules aswell ....

Eg. FreshJR AdaptiveQoS

##Script Tested on ASUS AC-68U, FW384.9, using Adaptive QOS with Manual Bandwidth Settings
##Script Changes Unidentified Packet QOS destination away from "Defaults" into "Others"
##Script Changes HTTPS traffic destination away from "Net Control" into "Web Surfing"
##Script Changes Minimum Guaranteed Bandwidth per QOS category from 128Kbit into percentages of upload and download. (Biggest FIX in regards to original performance)
##Script Re-purposes "Defaults" Traffic Container to contain Game Downloads instead of unidentified traffic.
##  Script Changes priority of "Defaults/GameDownloads" Traffic Container into position 6 (originally position 7)
##  Script Changes priority of users lowest defined "Traffic container" into position 7 (originally position 6)
##    Included rule moves any UDP traffic on remote ports 500 & 4500 into VOIP traffic Container.             (Wifi Calling)
##    Included rule moves any UDP traffic on local  ports 16384 - 16415 into VOIP traffic Container.          (Facetime)
##    Included rule moves any TCP traffic on remote ports 119 & 563 into Downloads traffic Container.         (Usenet)
##    Included rule moves any Snapchat traffic into Others traffic Container.                                 (Snapchat)
##    Included rule moves any Speedtest.net traffic into Downloads traffic Container.                         (Speedtest.net)
##    Included rule moves any Google Play Store traffic into Downloads traffic Container.                     (Google Play)
##    Included rule moves any Apple AppStore traffic into Downloads traffic Container.                        (Apple AppStore)
##  Included rule moves router traffic acting as VPN Client into "Downloads" instead of being whitelisted.  (VPN Fix)
##  Included rule moves any Gaming TCP traffic from remote ports 80 & 443 into Defaults traffic Container.  (Gaming)
##    Gaming traffic on ports 80 & 443 is primarily downloads & patches (some lobby/login protocols can be mixed within)
##  Included (MANUAL CONFIGURATION) rule moves unidentified traffic for specified devices into "Gaming" traffic container
##     The use of this gaming rule REQUIRES gaming devices to have a static dhcp ip assignment within the webUI   <<AND>>
##     this IP RANGE (CIDR NOTATION) needs to be passed into the script
##Script supports custom QOS rules.

 

[route]

I did read his post. When I googled your script I found a description that describes the fix as moving unidentified traffic from the default class to the others class. Where the others class can be prioritised but default is always the lowest. That would mean voip rtp traffic and bittorrent traffic gets prioritised together, which is what I want to avoid. It sounds like you've improved it further?

 

[FreshJR]

I did read his post. When I googled your script I found a description that describes the fix as moving unidentified traffic from the default class to the others class. Where the others class can be prioritised but default is always the lowest. That would mean voip rtp traffic and bittorrent traffic gets prioritised together, which is what I want to avoid. It sounds like you've improved it further?

Nah most of the modifications above have been in the script since the beginning for almost two years now!!
(Its just that the script modifications were explained in the header of the script instead of the SNB forum post)

VoIP should go to VoIP if your provider is using traditional ports.

Anyway, an update to both the forum post and a large update to the script is coming soon.
It will be changed so it will integrates with the new tracked connections page and also to make it easier to create custom rules.

It has ALWAYS supported custom port rules, both sending/recieving as you desire.

(You will have to agree to the TrendMicro EULA, but that is beyond my control...methods exist to stop it from phoning your information back home)

 

[route]

Sounds good, and you should be congratulated on this work. However, it's not for everyone and adaptive qos itself being flawed is still true. But if it comes down to custom rules by port numbers than traditional qos should handle it.

 

[FreshJR]

Sounds good, and you should be congratulated on this work. However, it's not for everyone and adaptive qos itself being flawed is still true. But if it comes down to custom rules by port numbers than traditional qos should handle it.

You can create custom rules filtering by local/remote ports while using traditional QoS as you desire by bypassing the WebUI setup and adding the iptable rule for your port filter to firwewall-start.
(Little more advanced, but easily doable).

Keep in mind that tradional QoS disables HW Acceleration if you have a fast enough connection that can exceed the CPU limits of your router.

 

[route]

Thanks again. I do have a slow internet service but curious; does adaptive qos disable hardware acceleration?

 

[FreshJR]

Thanks again. I do have a slow internet service but curious; does adaptive qos disable hardware acceleration?

not entirely (just a small portion of HW acceleration)