[Release] Asuswrt-Merlin 380.63_2 is now available

[chris.at]

Traditional QoS is known to be broken on the RT-AC68U, so that could be why.

Really? I thought that 56U and 68U were still working properly (at least with 380.59 as you said) so I assumed that's still the case.

 

[RMerlin]

Just figured this out while working on something on my fork. At least on the fork, eth0 is used when CTF is inactive....If CTF is enabled, it shows up as VLAN2.

So chances are the rules are on the correct interface (since I use the exact same API call as Asus to retrieve the correct WAN interface), but that SSH test was done on the wrong interface.

Try running the "tc" command again but using vlan11 instead of ppp0.

 

[RMerlin]

Really? I thought that 56U and 68U were still working properly (at least with 380.59 as you said) so I assumed that's still the case.

I'm not 100% sure, but I think these also got broken a few versions ago. At least, I was no longer able to do my codel tests anymore last time I tried to. A few users also reported they had doubts that it worked for them either.

 

[chris.at]

I ran some tests using dslreports speedtest with traditional QoS enabled: A/A/A (avg. 35ms up) and with QoS disabled: B/C/A (avg. 269ms up) so I'd say that traditional QoS is working on 68U.

It seems as if it's the same "display problem" as with this 56U, maybe the combination of traditional QoS with PPPoE?

 

[Schuby]

I'm having a difficult time finding the syntax changes from ipset 4.x to 6.x, can anyone point me in the right direction?

 

[matthew_eli]

Post the result from these commands then, so we can check all potential interfaces:

tc -s class show dev eth0
tc -s class show dev br0
nvram get wan0_ifname
nvram get lan_ifname

Do you use any VLAN for your Internet connection?

Pls, check the attachment:

https://drive.google.com/file/d/0B14-MriqKuXOaV9SOWptVFhwN0E/view?usp=sharing

no VLAN on my internet connection

 

[ChriscomIT]

Any Javascript error in your web browser console?

Same issue. At first view no JavaScript errors. I check factory reset later.

 

[RMerlin]

I ran some tests using dslreports speedtest with traditional QoS enabled: A/A/A (avg. 35ms up) and with QoS disabled: B/C/A (avg. 269ms up) so I'd say that traditional QoS is working on 68U.

A speedtest doesn't test much however. You'd need to ensure that traffic also gets classified into the correct classes.

It seems as if it's the same "display problem" as with this 56U, maybe the combination of traditional QoS with PPPoE?

This seems to be the common factor at this point. This will be difficult to troubleshoot, I'll have to configure a PPPoE server at home to try and reproduce the problem. What makes things harder is that Adaptive QoS is, as usual, another blackbox, so I have no way of knowing what it does and how it does it. Best I can do is poke at things around it, and see what it spits out as a result.

 

[RMerlin]

Pls, check the attachment:

https://drive.google.com/file/d/0B14-MriqKuXOaV9SOWptVFhwN0E/view?usp=sharing

no VLAN on my internet connection

So despite being on PPPoE and your firewall script mentioning using ppp0 as the WAN interface (which is what I expect), your WAN interface as configured in nvram as well as your QoS classes are both using eth0. This is making even less sense to me...

Asuswrt's WAN code is a complete mess. I'm pretty close to giving up on trying to understand how it's supposed to work. And it seems that only some very specific scenario causes this, since nobody ran into that issue during the multiple weeks of alpha and beta releases.

 

[ChriscomIT]

BTW only commit that was made is 8aeb81c in between the time. As I am coming straight from latest beta. So maybe the problem that upload chart for QOS is not shown lies into here. Just a wild guess...

 

[chris.at]

I know that a speedtest is quite useless to check the classifications but at least it shows that something gets queued and prioritized.

However, if you tell me how to check for proper classification and if I could help you investigate with commands and outputs please tell me (here or with PN) and I will try to support as good as possible.

Best wishes,
Chris

 

[RMerlin]

BTW only commit that was made is 8aeb81c in between the time. As I am coming straight from latest beta. So maybe the problem that upload chart for QOS is not shown lies into here. Just a wild guess...

What this commit did is use the exact same function Asus uses in their Traditional QoS when generating the configuration, instead of hardcoding it to eth0 (which is the physical WAN port). Unfortunately, it seems that Adaptive QoS might be using a different method to chose the WAN interface to configure, and even more confusing is that some people have ppp0 (so this commit fixed their issue), while others still have eth0. So at this point, it will probably be a guessing game to figure out how Adaptive QoS's closed source code selects the interface to use.

 

[RMerlin]

I know that a speedtest is quite useless to check the classifications but at least it shows that something gets queued and prioritized.

However, if you tell me how to check for proper classification and if I could help you investigate with commands and outputs please tell me (here or with PN) and I will try to support as good as possible.

That's what the new QoS Statistics page is meant to accomplish - showing how much traffic goes into each classes. Otherwise, you have to go fairly low-level, using the "tc" command from Linux's iproute2 suite. With traditional QoS, that would be "tc -s class show dev INT", where INT is either eth0, ppp0, vlan2 or God-knows-what-interface (determining how Asuswrt's WAN interface is selected is currently at the core of this problem).

 

[RMerlin]

Those with QoS stats issues using Adaptive QoS (@matthew_eli and others), please post the output of the following command:

ps w | grep qosd

It should hopefully tell me what WAN interface is used, as I see it's passed as an argument to that daemon. That could be a starting point to see what kind of interfaces everyone is using on their specific setup.

 

[ChriscomIT]

Those with QoS stats issues using Adaptive QoS (@matthew_eli and others), please post the output of the following command:

ps w | grep qosd

It should hopefully tell me what WAN interface is used, as I see it's passed as an argument to that daemon. That could be a starting point to see what kind of interfaces everyone is using on their specific setup.

My output:

14461 Chriscom   696 S    qosd -i /dev/idpfw -f /tmp/bwdpi/qosd.conf -w eth0 -l br0 -u 253 -b
31228 Chriscom  1380 R    grep qosd

 

[Veldkornet]

Those with QoS stats issues using Adaptive QoS (@matthew_eli and others), please post the output of the following command:

ps w | grep qosd

It should hopefully tell me what WAN interface is used, as I see it's passed as an argument to that daemon. That could be a starting point to see what kind of interfaces everyone is using on their specific setup.

I'm not having any issues FYI. But I do use Adaptive QoS on the 87u.

2231 admin   696 S    qosd -i /dev/idpfw -f /tmp/bwdpi/qosd.conf -w eth0 -l br0 -u 253 -b

Sent from my iPhone using Tapatalk

 

[tsunami2311]

NEW: Added pc_delete() to the helper script (patch by john95287)

Does this mean what I think it does? can we really delete client now by click the x next to offline clients?

 

[john9527]

NEW: Added pc_delete() to the helper script (patch by john95287)

Does this mean what I think it does? can we really delete client now by click the x next to offline clients?

No, sorry. That's for use in postconf scripts to delete a line from the router generated conf files.

 

[kau97]

With a RT-AC87U having adaptive QOS, automatic bandwidth & a DSL (3.0/0.5Mb) PPPOE connection.
I have blank upload stats in the QOS statistics tab. QOS download stats are working. I was coming from 380.62_1 and did not perform a hard reset.

 1063 admin      700 S    qosd -i /dev/idpfw -f /tmp/bwdpi/qosd.conf -w eth0 -l br0 -u 253 -b
 4192 admin     1380 D    grep qosd

This is probably unrelated ... the upload portion of QOS does not seem to work. When any user is uploading, the connection is significantly affected. Web requests do not appear to be prioritized. All web browsing is slower. This may just be due to the small upload pipe and buffer bloat I have.

 

[mafiaboy01]

Had my AC66u crash and restart on 380.63

I can't post a text file for some reason so here is a picture of some of the error.