is this a bug in the TP-Link TL-WR1043N/ND v2 firmware ?

[jeremycobert]

Hey guys, longtime user, recent poster. Anyway, I got a new TP-Link TL-WR1043N/ND v2 and have the 1.8 firmware running on it.

Setting up my QOS download rules, I noticed that none of the traffic rules worked in the default setup. In the QoS (Download) -- Classification Rules by default it has traffic setup like this example "Source Port: 80, Connection bytes: 1024 kBytes" as the port 80 over 1024 rule.

I monitored it, but no traffic moved in that "normal" group. I thought about it for a second and thought that any traffic hitting the router , the packets would be looking for a destination so I changed it to" Destination Port: 80, Connection bytes: 1024 kBytes" and traffic started to flow properly. I changed all of my download rules to "Destination" instead of "Source".

I went back to the upload QOS and the same thing in reverse applied here, all the rules are setup for destination but I reversed it to source for the rules on upload and it all seems to be flowing properly.

I don't know if someone mixed those up in just this firmware, or something has changed. I just wanted to bring that to someone's attention.

the 2nd thing I noticed is that the QOS rules in 1.8 work fine by Ip address and with CIDR rules on Ip, but they don't appear to be working by port. As a test, I created a "TEST" qos group and threw my pc into that group by IP. I can see traffic moving but if I also add "destination port 80" to the rule, the traffic no longer shows up when browsing the web on port 80.

I have run several tests with different factors, but it all seems to point to the fact that port filtering on QOS is not working. can anyone confirm that or is it just this version of firmware for this router.

Currently, I just have all my QOS rules setup by CIDR groups but would like a little more control over it.

[Lantis]

port matching works perfectly here

furthermore, the original port 80 rules are correct.

the communication goes from your computer (source port chosen "randomly") to a web server (destination port 80). And from a web server (source port 80) to your computer (destination port xxxxx) for the server's responses.

[jeremycobert]

port matching works perfectly here

furthermore, the original port 80 rules are correct.

the communication goes from your computer (source port chosen "randomly") to a web server (destination port 80). And from a web server (source port 80) to your computer (destination port xxxxx) for the server's responses.

Something odd here then. Here is a video I shot of it in action.

I can get better quality on the video if needed.
https://youtu.be/RbQtXv55L5o

I show the upload section and have my rules listed as Source (instead of destination as it is in default) so my server is uploading to google drive on port 443 and is the only device in the "slow" group. It is capped at 100kbps. In the video I show the upload rules and the current load.

I switch over to resume server uploads and the switch back, at which point you will see the "slow" class hit its bandwidth limit as traffic has met the rules conditions. I then turn off my servers uploads and the class drops back down to zero load.

If I left the rules as you say and use "destination" then no traffic flows, it all goes into the default class.

[Lantis]

I had a thought. Did you allow the upload to run for long enough?

It's matching on total connection bytes exceeding 1MB.

At a speed of 100kbps that would be 81 seconds before the connection switched.
Even at your maximum listed upload speed that's still 8 seconds.

[jeremycobert]

I had a thought. Did you allow the upload to run for long enough?

Ok, I have a 2nd test. In this test I place my servers ip into the VOIP class as there is no traffic on it.

So in just to be clear, I am using "Source: 192.168.1.249, Connection bytes: 128 kBytes" on the upload section.

Which according to Gargoyle documentation, should not be a valid QOS route as you guys are telling me that Destination should be on uploads. I have reversed source and destination. So all traffic should on my network should technically default into "Slow" as all of my qos rules would be invalid.

So, lets test it out https://youtu.be/RBcIPzzUpw4

As you can see in the video, I flip on uploading to google drive on port 443. the traffic increases on "slow" briefly and then after 128k it switches over to VOIP and hits the max Voip rule of 512/up and stays there. I then pause my upload and traffic on VOIP drops back to zero.

In the default installation, the Destination and source are backwards in the QOS and all traffic is dumped into the slow class.
So, it may just be this routers firmware but it makes more sense to have source on the upload packets as routing of network packets requires the source address of the sending host, and the destination address of the receiving host.

[Lantis]

your test isn't valid.

matching by source address is completely different to matching by source port.



Here is a video showing it working correctly, with the default rules.