[Beta] Asuswrt-Merlin 380.59 Beta 2 is available

[RMerlin]

How come Smartifi is still not compatible with AC56U? Is this model missing the ASSIA agent or the CloudCheck app simply needs an update to support this router?
The app is saying the only supported asus routers are AC3200, AC66R/U/W, AC68P/R/U/W and N66R/U/W.

It's possible that Asus didn't license out the client for that model. It's typical for manufacturers to have to pay for each different model they want to support. I wouldn't know for sure, I only briefly played with it, and found it to be rather useless, especially with Asus now having their own Android app for router management.

 

[RMerlin]

Ignore those log entries, there're there since forever.

While working on getting downstream QoS to work (through IFB), I found out that one class has a quantum of 10000 instead of 1514 like the other ones. I wonder if that wouldn't be the cause for this warning.

Check Asus's 1:60 class.

 

[charlie2alpha]

While working on getting downstream QoS to work (through IFB), I found out that one class has a quantum of 10000 instead of 1514 like the other ones. I wonder if that wouldn't be the cause for this warning.

Check Asus's 1:60 class.

Ah, I've seen that class, something about the downstream apparently but I never looked much into it since I almost never saturate my downstream.

By the way, I think I found fq_codel's Achilles's heel. It works better than sfq for multiple streams but there is one issue when only one stream is used. It caps the upload lower than expected. By doing this it achieves to keep latencies low but for users with relatively low upload this can be a problem and it definitely is for me as it messes with my Plex Media Server streaming capability. In contrast, sfq doesn't cap the upload on its own, it lets the parent class to do it but latency suffers, I noticed very bad pings during the test.

The whole thing is subjective, if I had 50 Mbps upload I wouldn't care to sacrifice 1 Mbit to gain better latencies, but having only 5 Mbps I just can't afford it!

 

[MegaTronics]

I have got a somehow strange IPv6 issue with this beta (380.58 has this also). I'm running at this moment a HE IPv6 tunnel and everything is working OK.

I also got a static IPv6 block from my ISP. When I configure my RT-AC68U and reboot everything is working alright for my wired clients, but my wireless clients only work for a couple of minutes and then lose the connection to the Internet via IPv6. The http://ipv6-test.com/ site gives a not supported notification at the IPv6 tests. When I disconnect and reconnect the wireless interface of those mobile devices it works again for a couple of minutes.

With firmware's pre 380.58 the wired clients had also this behavior, so something is fixed in the 380.58 release, but only for wired clients and not mobile. Is there anybody who has an idea what this could be and hopefully how to fixed it for both clients, wireless and wired? It looks like a RA issue, but why does it only apply to wireless clients?

 

[RMerlin]

Ah, I've seen that class, something about the downstream apparently but I never looked much into it since I almost never saturate my downstream.

If I remember correctly, that's the default class for downstream traffic. Not sure if the absence of a sensible quantum value was intentional or a bug. It did create a problem in my initial downstream tests with IFB (which is what led me to it).

I re-enabled Asus's own downstream QoS code (currently disabled through the CLS_ACT if/def block), but was having some major issues. Something's not right in how it configures everything, and debugging it is proving slow since I'm not really familiar with tc (and the fact it takes 10 minutes modem power cycle every time I swap between my AC88U and the development AC68U makes it harder to work on this as well). Would be nice getting downstream QoS to work, now that we have IFB...

By the way, I think I found fq_codel's Achilles's heel. It works better than sfq for multiple streams but there is one issue when only one stream is used. It caps the upload lower than expected. By doing this it achieves to keep latencies low but for users with relatively low upload this can be a problem and it definitely is for me as it messes with my Plex Media Server streaming capability.

Codel needs to know what type of upstream overhead you have. In the case of DSL, that means an extra 12 or 16 bytes at the ATM level (I forgot the exact amount). That might be what's hurting you there.

 

[RMerlin]

I have got a somehow strange IPv6 issue with this beta (380.58 has this also). I'm running at this moment a HE IPv6 tunnel and everything is working OK.

I also got a static IPv6 block from my ISP. When I configure my RT-AC68U and reboot everything is working alright for my wired clients, but my wireless clients only work for a couple of minutes and then lose the connection to the Internet via IPv6. The http://ipv6-test.com/ site gives a not supported notification at the IPv6 tests. When I disconnect and reconnect the wireless interface of those mobile devices it works again for a couple of minutes.

With firmware's pre 380.58 the wired clients had also this behavior, so something is fixed in the 380.58 release, but only for wired clients and not mobile. Is there anybody who has an idea what this could be and hopefully how to fixed it for both clients, wireless and wired? It looks like a RA issue, but why does it only apply to wireless clients?

Try doing a power cycle of your modem, and all your LAN equipment. Some users fixed their issues with the modem power cycle.

 

[MegaTronics]

Try doing a power cycle of your modem, and all your LAN equipment. Some users fixed their issues with the modem power cycle.

I will give that a try tomorrow, if I do it now my wife will not like it.

 

[RMerlin]

if I do it now my wife will not like it.

Would that be worse than if she saw your forum avatar?

 

[charlie2alpha]

If I remember correctly, that's the default class for downstream traffic. Not sure if the absence of a sensible quantum value was intentional or a bug. It did create a problem in my initial downstream tests with IFB (which is what led me to it).

I re-enabled Asus's own downstream QoS code (currently disabled through the CLS_ACT if/def block), but was having some major issues. Something's not right in how it configures everything, and debugging it is proving slow since I'm not really familiar with tc (and the fact it takes 10 minutes modem power cycle every time I swap between my AC88U and the development AC68U makes it harder to work on this as well). Would be nice getting downstream QoS to work, now that we have IFB...



Codel needs to know what type of upstream overhead you have. In the case of DSL, that means an extra 12 or 16 bytes at the ATM level (I forgot the exact amount). That might be what's hurting you there.

No, I already have overhead properly configured, and to be sure I even capped the maximum upload via the QoS settings to 4 Mbps, the results persisted. I did another test, removed all the traffic shaping and just added fq_codel as the only (classless) qdisc on my WAN interface (ppp0). Result is exactly the same. It's possible I'm misconfiguring something on my traffic shaping script, I will try to look up what can be configured on fq_codel but I don't have much hope, it was designed to required no or little configuration in the first place.

 

[Blinkyz]

Would that be worse than if she saw your forum avatar?

Maybe not , if its her

 

[Deleted member 22229]

Maybe not , if its her

 

[stambeccuccio]

RT-AC68U
380.59_beta2

The following pages (https) do not work with Chrome 50.0.2661.94

https://router.asus.com:8443/Guest_network.asp
https://router.asus.com:8443/DNSFilter.asp
https://router.asus.com:8443/QoS_EZQoS.asp
https://router.asus.com:8443/AdaptiveQoS_WebHistory.asp
https://router.asus.com:8443/Advanced_AiDisk_samba.asp
https://router.asus.com:8443/Advanced_AiDisk_ftp.asp
https://router.asus.com:8443/Advanced_VPN_PPTP.asp
https://router.asus.com:8443/Advanced_VPN_OpenVPN.asp
https://router.asus.com:8443/Advanced_System_Content.asp

Regards

 

[RMerlin]

RT-AC68U
380.59_beta2

The following pages (https) do not work with Chrome 50.0.2661.94

https://router.asus.com:8443/Guest_network.asp
https://router.asus.com:8443/DNSFilter.asp
https://router.asus.com:8443/QoS_EZQoS.asp
https://router.asus.com:8443/AdaptiveQoS_WebHistory.asp
https://router.asus.com:8443/Advanced_AiDisk_samba.asp
https://router.asus.com:8443/Advanced_AiDisk_ftp.asp
https://router.asus.com:8443/Advanced_VPN_PPTP.asp
https://router.asus.com:8443/Advanced_VPN_OpenVPN.asp
https://router.asus.com:8443/Advanced_System_Content.asp

Regards

Known issue, the problem is caused by Asus trying to reach a Javascript page hosted on their server which don't support https. The mixed content causes Chrome to block access to that script, which in turns causes problems to the webui.

 

[westmc]

Check the system log for any error related to USB during the copy. Might be worth running a chkdsk on the hard disk as well.

So after getting it to go back to the proper speed under 380.2695, I am unable to reproduce the problem again after switching back to 380.59 beta 2. I'm not sure what could have happened that caused the issue to last through multiple downgrades/upgrades and repeated factory refreshes. Very strange!

Even though the extreme slowness has gone away, NAS speed is about 20% slower under 380.59 for me (40/22 vs 50/30). Hopefully it is due to the smb.conf changes that you already rolled back.

 

[Kanuki]

Hi..

I'm using RT-AC3200 with 380.59 Beta 2.

It would be nice if you can add the feature in MAC Filter page
that will allow to use a single MAC filter list for 2.4GHz, 5GHz-1, and 5GHz-2
or the feature that will allow to copy the MAC Address from each other
(2.4GHz, 5GHz-1, and 5GHz-2) in one single click.

 

[tarzan2000]

Good afternoon!
Does iptv traffic 59 beta 2 for AC56U?
Thank you.

 

[MegaTronics]

A complete reboot/restart of the network did not fixed the IPv6 issues on wireless. It still keeps losing the connection. In the mean time I have tested the new Asus firmware, but there it does not work either. in fact even the HE tunnel does not work stable. So back to the latest Merlin Beta and I will test is with further updates. Till that time HE tunnel it is.

And no, the avatar is not my wife, but she knows I use this avatar on all my profiles on the internet.

 

[Piter]

Hi all
RMerlin is any chance to add scheduler as is for Rebot Router but for Turn ON and OFF leds on router ? The creation of the script is cumbersome and not everyone can cope with it. Setting the from GUI is very simple and was easly for all people.

I think also that section page Performance tuning should be move to section TOOLS. Looks better.

 

[RMerlin]

RMerlin is any chance to add scheduler as is for Rebot Router but for Turn ON and OFF leds on router ? The creation of the script is cumbersome and not everyone can cope with it. Setting the from GUI is very simple and was easly for all people.

No plan to. I can't start adding a scheduler for every single option on the webui, it would be endless. The cron job is the current best method to do it.

I think also that section page Performance tuning should be move to section TOOLS. Looks better.

The reason the page is there is because it's a page originally developed by Asus (back when they originally planned to put a fan in the RT-N66U). I don't want to move their pages around, as it could create confusion.

 

[stevef9432203]

How do Mr RMerlin
My rt5300 still can't connect to ipv6 web ports(80,443). Build 380.58 was ok, testing with wget from entware repo, running wget http://ip6.me watch results on sh cmd line, fail on ipv6 from the router, but suceed using ipv4. Beta 1 & 2 show the same behavior.

Stevef