Solved Wifi Upload not limited by QoS on RT-AC86U

[ColinTaylor]

Yeah, I don't have that feedback page anywhere in my admin.

I can locate the page by typing URL directly, but in merlin I do not have this page.

Ah, so you're using Merlin's firmware? I thought you were talking about the stock Asus firmware as that is what this thread and sub-forum is discussing, not Merlin's.

I believe Merlin's firmware removes that feedback page as it makes no sense to submit feedback to Asus about a third party firmware they don't support.

 

[cplay]

I've submitted this to ASUS with the following below (if anyone reading the thread could also do this it would be much appreciated as this issue will affect anyone using VPN client and trying to use qos upload limiting:

This version was supposed to fix QOS Upload on wifi:
ASUS RT-AC86U Firmware version 3.0.0.4.384.32797
Changelog:
Bug fixes and enhancements:
- Fixed Adaptive QoS upload bandwidth setting issue.

Which it did UNLESS you are using a VPN Client in ASUS vpn setting.

See here and read my post and then check out my thread within it:
https://www.snbforums.com/threads/s...d-by-qos-on-rt-ac86u.44952/page-2#post-568177

If VPN client disabled your QOS upload fix fixes the problem, however if VPN client enabled your QOS upload bandwidth limiter stops working again.

There needs to be a fix for VPN client QOS upload bandwidth also.

 

[cplay]

Ah, so you're using Merlin's firmware? I thought you were talking about the stock Asus firmware as that is what this thread and sub-forum is discussing, not Merlin's.

I believe Merlin's firmware removes that feedback page as it makes no sense to submit feedback to Asus about a third party firmware they don't support.

I put this thread on here because issue exists on both ASUS WRT and Merlin, so therefore the bug originates in stock firmware and just carries over to Merlin.

Is this issue something you can address @RMerlin in your software (I am using your latest version) or is it something ASUS has to address and when fixed can be added to your software?

 

[OzarkEdge]

I can locate the page by typing URL directly, but in merlin I do not have this page.

That's an interesting conundrum... losing the Feedback mechanism for Asuswrt code.

OE

 

[cplay]

That's an interesting conundrum... losing the Feedback mechanism for Asuswrt code.

OE

But Merlins code is built on top of Asus wrt code so I don't actually see why it would be removed as this bug is not caused by Merlin himself as I've tested and had same results using stock so issue is related to asus wrt and feedback form would be only way to convey issue to ASUS?

 

[Odkrys]

Asus throttles eth0(wan interface) for upload and br0(lan interface) for download.

When client sends packets, the packets go through tun0 (vpn interface) and the packets encapsulated.
So eth0 rules are ignored.
I don't know why Asus applied this way.
Perhaps it is related to closed source components.

 

[OzarkEdge]

But Merlins code is built on top of Asus wrt code so I don't actually see why it would be removed as this bug is not caused by Merlin himself as I've tested and had same results using stock so issue is related to asus wrt and feedback form would be only way to convey issue to ASUS?

That's the conundrum... it would not be right for third-party firmware to direct all feedback to the first party... bad form... even though the potential need exists.

OE

 

[cplay]

Asus throttles eth0(wan interface) for upload and br0(lan interface) for download.

When client sends packets, the packets go through tun0 (vpn interface) and the packets encapsulated.
So eth0 rules are ignored.
I don't know why Asus applied this way.
Perhaps it is related to closed source components.

So why does download qos limiting still work when using tun0 (vpn interface) and only upload limiter stops working on devices?

 

[cplay]

That's the conundrum... it would not be right for third-party firmware to direct all feedback to the first party... bad form... even thought the potential need exists.

OE

Got it, I'm British so instinctively thought you were being sarcastic in your first post.

But yeah, it is actually a conundrum.

I've posted multiple instances of feedback under different categories to the url provided so will wait to hear back.

Quite perplexes me why they sorted issue for wan (original qos upload issue) but not vpn tunnels.

 

[Odkrys]

So why does download qos limiting still work when using tun0 (vpn interface) and only upload limiter stops working on devices?

download : VPS -> eth0 -> tun0 (unencapsulated) -> br0 (throttled)-> client.

So download limitation works.

upload : client -> br0 -> tun0 (encapsulated) -> eth0 (throttled) -> VPS

eth0 doesn't know which lan client sends the packet.

 

[cplay]

download : VPS -> eth0 -> tun0 (unencapsulated) -> br0 -> client.

So download limitation works.

upload : client -> br0 -> tun0 (encapsulated) -> eth0 -> VPS

eth0 doesn't know which lan client sends the packet.

Right - just to clarify - does wifi still go through br0 (lan interface)

 

[RMerlin]

Is this issue something you can address @RMerlin in your software

No.

 

[RMerlin]

That's an interesting conundrum... losing the Feedback mechanism for Asuswrt code.

I remove the page from my firmware to prevent people from submitting feedback to Asus about a firmware that does NOT come from them.

It also ensures that people actually test the original firmware before complaining to Asus about this and that.

 

[cplay]

I remove the page from my firmware to prevent people from submitting feedback to Asus about a firmware that does NOT come from them.

It also ensures that people actually test the original firmware before complaining to Asus about this and that.

Got it, so the feedback i submitted while using merlin but just by visiting the feedback url form has been submitted correctly, yes?

Like I said this problem stems from ASUS wrt code not yours.

 

[OzarkEdge]

Like I said this problem stems from ASUS wrt code not yours.

Whether it does or doesn't, the Asuswrt-Merlin user may not know for sure and should direct all feedback to the source of the firmware who is now responsible for processing that feedback, or not. I suppose if the user is told 'not my chair, not my problem', they can then use some other means to address their feedback directly to Asus... or just forget about it.

OE

 

[RMerlin]

Got it, so the feedback i submitted while using merlin but just by visiting the feedback url form has been submitted correctly, yes?

I cannot guarantee that it's working properly. The feedback code is closed source, and I know it also does some data gathering to include technical info about the router in the report, no idea if that part works as well.

And Asus may very well decide to dismiss any feedback that does not come from a stock firmware, to avoid wasting their time in chasing after wild gooses. I know that personally I generally ignore any "bug report" that comes from anyone not running my firmware. Too often I wasted time trying to track down something, only to discover later on that the user was running someone else's forks, they weren't running my firmware, or they were running an older version.

People should not use that page on my firmware, period. The only reason I left the actual web page there is for a while some third party developers were reusing that page to add new content to the webui. Now that the new addons API has been available for a while, I am seriously considering completely removing the page if there are people found to be misusing it.

 

[cplay]

I cannot guarantee that it's working properly. The feedback code is closed source, and I know it also does some data gathering to include technical info about the router in the report, no idea if that part works as well.

And Asus may very well decide to dismiss any feedback that does not come from a stock firmware, to avoid wasting their time in chasing after wild gooses. I know that personally I generally ignore any "bug report" that comes from anyone not running my firmware. Too often I wasted time trying to track down something, only to discover later on that the user was running someone else's forks, they weren't running my firmware, or they were running an older version.

People should not use that page on my firmware, period. The only reason I left the actual web page there is for a while some third party developers were reusing that page to add new content to the webui. Now that the new addons API has been available for a while, I am seriously considering completely removing the page if there are people found to be misusing it.

You literally told me to use it as the best way to get hold of them?

How else can I get them to fix a bug that is your not your bug with your firmware?

 

[Odkrys]

this way will work at br0 interface level.
example of limiting 5mbit upload speed to 192.168.50.85.
I do not guarantee its stability.

tc qdisc del dev br0 handle ffff: ingress 2>/dev/null
tc qdisc add dev br0 handle ffff: ingress
tc filter add dev br0 parent ffff: protocol ip prio 30 u32 match ip src 192.168.50.85 police rate 5120kbit burst 30k drop flowid 30:

 

[Grisu]

How else can I get them to fix a bug that is your not your bug with your firmware?

Load stock firmware and go on with feedback, its so easy.
And before you can safe your Merlin config for faster get back to where you are.

 

[RMerlin]

You literally told me to use it as the best way to get hold of them?

You posted in a thread about the *official* firmware. You never told me that you were on my firmware before people starting quizzing you about it. Once you did, everyone told you THEN that you should provide feedback using the form on the stock firmware, not my firmware.