[Release] Asuswrt-Merlin 380.63_2 is now available

[bbunge]

There are no download stats with Traditional QoS because that QoS can ONLY control uploads. This is normal.

I'll add a notice on the stats page in the next release to make it clear.

Bummer about the QOS.
On a brighter note and after carping about the Traffic History not creating a data file on a thumb drive I was able to get it created on a conventional USB hard drive.

 

[Serra]

Got it now, quite weird, have you tried a power cycle?

Not yet. Because that AC88U is brand-new, I thought just having factory reset is fine enough.
Let me try the power cycle first and hope it can really resolve this strange behavior. Thanks for the advice.

 

[hggomes]

No problem.

 

[crespo]

rt-ac68u updated, looks good. then overclocked but failed, factiory reset yesterday, today no 5G signal, 2.4G is fine. Not sure if its related to the update.

 

[chris.at]

I finally had a chance to look at this again.
AC56U
PPPoE
Loaded the test build and am getting the following results:

Adaptive QOS statistics page shows traffic categorized as I would expect and pie charts are showing for both upload and download. (Looks nice!)

Traditional QOS statistics page categories are all showing from Highest to Lowest, but the traffic is not matching what is setup in the user-defined QOS rules. To test this, I set up a different client MAC for each priority (Traffic Class). What I found is that every client used the "Highest" and "Low" classes. I could not get traffic to use the "High", "Medium", or "Lowest" classes as assigned to particular clients on the user-defined QOS rules page. Not sure if the traffic is really being classed correctly and displayed incorrectly or if the traffic is not hitting the assigned classes. In any case, this is different behavior than I reported for 380.63_0 where the traffic seemed to be shifted by one relative to the categores, but all classes were being used.

Good Morning Sam84,

Please have a look at my post: http://www.snbforums.com/threads/re...-63-is-now-available.35561/page-6#post-289328

Traditional QoS sets up a iptables rulebase for classification which starts with these three lines (that's not RMerlins code!). After them come the rules you defined in the gui followed by a default classification for all unmatched traffic to low (thats why I setup my rulebase with a default for lowest as last statement in the gui so the systems default applied after it would never match). As far as I was able to "decode" these lines they check if traffic already has a CoS-mark set and if so, it does no reclassification. When I remove these lines (the code-lines are already the remove commands, so ready for copy&paste) traffic gets classified correctly.

Could you please try the following:
Setup your QoS as you want it for testing purpose, login to your router cli, copy&paste these 3 lines. Now don't touch QoS settings because everytime you adjust anything (bandwith, rulebase) iptables is regenerated and these lines are back again. If you go to your stats page you should see that your classification is working properly now. If not don't worry, it's not persistent, just reboot or change QoS settings.

If it's working you can save these 3 lines as firewall-start script (first script-line must be #!/bin/sh followed by these 3 lines) so that everytime you change QoS or anything else which causes a firewall restart these lines will be removed. I didn't recognize any negative side effects of this modification in my setup.

Regards,
Chris

 

[Kedorel]

Anyone else has problems with the wifi sheduler? Wifi is not starting up properly.

 

[matthew_eli]

Anyone else has problems with the wifi sheduler? Wifi is not starting up properly.

Nope, all working good here about WiFi schedule

 

[Jong]

next reboot with uptime less than 24h
I use pppoe, aiprotection. No usb devices.

Same here.

I updated from Asus firmware to this a couple of days ago. I did use Merlin about a year ago, I switched back to Asus when they updated radio firmware and have only just got around to switching back.

Anyway, the Asus firmware never "crashed", neither, from memory did the old Merlin firmware, but, like you I have had 2 crashes of my router in 2 days, about 24 hours apart. nothing evident in the log, either before or after the crash.

My router is an AC87U. aiProtection/QoS are on. I did have Traffic Analysis on. Turned Traffic Analysis off now, as I didn't have that enabled with Asus firmware. No USB device, no other special software or scripts loaded. AiCloud off. No PPPoE, just regular automatic IP assignment.

My identical AC87U in AP mode, running the same firmware, has stayed up for over 2 days

Any thoughts, anyone?? Thanks.

 

[oversim]

Any thoughts, anyone?? Thanks.

Hello! I've the same device, AC-87U, and I'm using Merlin Firmware since the day I opened the amazon package of the router
And I have no crashes, no problems, and I'm using it with QoS (no traditional), aiProt. is off but I use openvpn server a lot.

So, my first advice is to check temperature. My AC87U in summer runs in a very hot temperature, event the ambient temperature is moderate high (never higher than 26'C).
Then, personally I'll try to reset the router to default setting and the reconfigure it as a new one. Ok it's boring, I know it... but it will take you 30/40 minutes, no more (I did it some beta ago, and I have vpn certificate too..)

 

[Jong]

Hello! I've the same device, AC-87U, and I'm using Merlin Firmware since the day I opened the amazon package of the router
And I have no crashes, no problems, and I'm using it with QoS (no traditional), aiProt. is off but I use openvpn server a lot.

So, my first advice is to check temperature. My AC87U in summer runs in a very hot temperature, event the ambient temperature is moderate high (never higher than 26'C).
Then, personally I'll try to reset the router to default setting and the reconfigure it as a new one. Ok it's boring, I know it... but it will take you 30/40 minutes, no more (I did it some beta ago, and I have vpn certificate ..)

Thanks for the reply but everything was fully reset when I installed Merlin 2 days ago. The router has been perfectly happy where it is for 18 months prior to the update. I am sure it's not temperature related. Occasionally, in the past, a radio has stopped working, needing a reboot, but I have never seen a hard crash/reboot, with no error, like myself and Vant are now seeing.

Maybe it's the traffic analysis - I am not sure how much RAM its logs require and what happens when it runs out of space - turning it off, as I have now done, should eliminate that. I'm still surprised to see nothing in the log at all to indicate the cause.

 

[oversim]

[QUOTE="
Maybe it's the traffic analysis - I am not sure how much RAM its logs require and what happens when it runs out of space - turning it off, as I have now done, should eliminate that. I'm still surprised to see nothing in the log at all to indicate the cause.[/QUOTE]

You can try to log into router via ssh \ telnet and with a free command you can see ram status.. In addition (if it will) you can add a swap partition using an usb flash drive but I thing it's not an out of ram..

 

[Jong]

Yep, it would surprise me too, but it could just be Traffic Analysis itself. Anyway, let's see what the next 24 hours brings! Next I can try stopping QoS then AiProtection...!

 

[Wutikorn]

Same here.

I updated from Asus firmware to this a couple of days ago. I did use Merlin about a year ago, I switched back to Asus when they updated radio firmware and have only just got around to switching back.
Anyway, the Asus firmware never "crashed", neither, from memory did the old Merlin firmware, but, like you I have had 2 crashes of my router in 2 days, about 24 hours apart. nothing evident in the log, either before or after the crash.
Any thoughts, anyone?? Thanks.

If reset, reflash and disable functions don't help. Try 380.62_1 It is the most stable version from my opinion.

 

[Deleted member 48827]

Please have a look at my post: http://www.snbforums.com/threads/re...-63-is-now-available.35561/page-6#post-289328

Could you please try the following:
Setup your QoS as you want it for testing purpose, login to your router cli, copy&paste these 3 lines. Now don't touch QoS settings because everytime you adjust anything (bandwith, rulebase) iptables is regenerated and these lines are back again. If you go to your stats page you should see that your classification is working properly now. If not don't worry, it's not persistent, just reboot or change QoS settings.

Hello Chris,

Thank you for your reply. I'm looking forward to trying your solution. I'll need a day or so before I can get access to the router, try this and report back.

Regards,
Scott

 

[Jong]

If reset, reflash and disable functions don't help. Try 380.62_1 It is the most stable version from my opinion.

Thanks, I'll consider that.

380.63 working well while it's up though!

 

[Serra]

I have tried to power cycle the AC88U and I have also tried to flash previous version 380.62_1, but the radio temperature is still shown 'disabled'.
I'm using 5GHz to send out this reply so I'm pretty sure that the radio is enabled, does anyone have the idea?
Thanks a lot.

 

[hggomes]

Try this:

wl -i eth1 phy_tempsense
wl -i eth2 phy_tempsense

 

[MarkRH]

I turned the Wi-Fi on my RT-AC68U and I do see the temps for everything after doing so. Only commenting as I'm on 380.63 as well.

 

[hggomes]

All models temperatures work fine, except Serra's RT-AC88U, let's see why.

 

[Deleted member 48827]

PPPoE
AC56U
Traditional QOS
380.63_1 Testing Version

Please have a look at my post: http://www.snbforums.com/threads/re...-63-is-now-available.35561/page-6#post-289328

Could you please try the following:
Setup your QoS as you want it for testing purpose, login to your router cli, copy&paste these 3 lines. Now don't touch QoS settings because everytime you adjust anything (bandwith, rulebase) iptables is regenerated and these lines are back again. If you go to your stats page you should see that your classification is working properly now. If not don't worry, it's not persistent, just reboot or change QoS settings.

Chris,
I can confirm the same behavior you are seeing. Using your code to remove the three iptables rules fixes traditional QOS traffic classification. I set up five clients so that the traffic from each would be routed through the five separate QOS priority classes, Highest" through "Lowest". Before modifying the iptables rules, all traffic from all five clients used a combination of the "Highest" and "Lowest" classes only. After using your code to remove the three iptables rules, traffic from each of the five clients was correctly routed to the each class as specified in the QOS user-configuration rules. I did notice that a small amount of traffic was being channeled through the "Highest" class in addition to the appropriate lower classes for each client that was set up to use one of the lower classes (the client set to use "Highest" was powered down at the time) I'm not sure what that means, other that maybe some type of traffic is prioritized to use the "Highest" class by default even when a QOS user-defined rule specifies that a client uses a lower class than "Highest".

I wish I had a better understanding of iptables to know what those three rules are trying to accomplish. Maybe someone can help with this? Sure seems that in our cases removing those rules is the right thing to do. I have not seen any downsides to removing them so far.

Regards,
Scott