What's new

Downloading a file with https link does not get identified as file transfer

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

medwatt

Regular Contributor
When adaptive QoS is enabled, downloading a file with http link (http://.....) gets identified correctly as a file transfer. However, download a file with https link (https://.....) does not get identified as a file transfer. Instead, it gets identified as a SSL/TLS traffic, and this gives it the highest priority as it goes under the "Net Control Packets" category. I know https is supposed to be the secured version of http and we get end-to-end encryption, but what use is QoS if all downloads are https ?
 
The answer has been posted in my thread.

That's the way the definitions work. Your router and PC do not talk to each other as to what they are doing.

The router has to look at the packet and guess what it is. If the packet is encrypted what do you want the router to do? I think I have seen it indentifing some https traffic and have been amazed.

This behavior is all done by trendmicros QOS definitions database.

Yes if we move towards fully encrypted traffic then apaptive qos gets a hell of a lot harder. At least they can still identify by ip ranges & ports to a moderate degree of accuracy.

I hope you are not expected 100% accuracy. Your are out of your mind. While looking at my categories I have a fair share of traffic correctly identified and am impressed
 
The answer has been posted in my thread.

That's the way the definitions work. Your router and PC do not talk to each other as to what they are doing.

The router has to look at the packet and guess what it is. If the packet is encrypted what do you want the router to do? I think I have seen it indentifing some https traffic and have been amazed.

This behavior is all done by trendmicros QOS definitions database.

Yes if we move towards fully encrypted traffic then apaptive qos gets a hell of a lot harder. At least they can still identify by ip ranges & ports to a moderate degree of accuracy.

I hope you are not expected 100% accuracy. Your are out of your mind. While looking at my categories I have a fair share of traffic correctly identified and am impressed

But why give encrypted traffic the highest priority ?
 
Can you give me PM your output from

tc filter show dev br0 | grep "mark"

and

tc filter show dev br0


The sheer incompetence of ASUS is going to give me a heart attack in a second if what I suspect is true.

FWIW, mine was not picked up by adaptive QOS at all. I found that it was filter marked as 0x8013 which does not have a corresponding rule to sort it into either unidentified traffic or one of the defined catagories on my router.

WHAT IN THE HELL

hopefully your rules will show why yours is network control and mine is undetected

EDIT: From your rules, yours was marked as 0x8014 which does redirect to network control. I have no idea what other traffic is identified as 0x8014, so I don't want to change that categories destination. Also no idea why mine was identified as 0x8013 which doesnt even have a corresponding rule. ASUS should really be more open as to what is going on.
 
Last edited:
EDIT: From your rules, yours was marked as 0x8014 which does redirect to network control. I have no idea what other traffic is identified as 0x8014, so I don't want to change that categories destination. Also no idea why mine was identified as 0x8013 which doesnt even have a corresponding rule. ASUS should really be more open as to what is going on.

At least, yours doesn't get the highest priority and wreck havoc.

Edit : Maybe a third person can post his/her result?
 
Last edited:
At least, yours doesn't get the highest priority and wreck havoc.

Edit : Maybe a third person can post his/her result?

Since you updated your QOS definitions, toggle QOS on/off and try to download again. Im willing to bet it will be marked 0x8013 which will not be picked up by QOS anymore.

You may want to experiment with chaning 0x8013 & 0x8014 marked packets to go into the downloads container. I typically have not seen much traffic going into those categories so I personally would not witness adverse effects if this was my network.
 
Last edited:

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top