[Release] Asuswrt-Merlin 380.63_2 is now available

[eclp]

Unfortunately, the RT-AC87U will not update from 380.63_1 to 380.63_2. It remains on 380.63_1 despite going to 100%.
No issues with the RT-AC68U except needing a physical reboot after the update.

Try several times! And without connected USB devices.

 

[Veldkornet]

Unfortunately, the RT-AC87U will not update from 380.63_1 to 380.63_2. It remains on 380.63_1 despite going to 100%.
No issues with the RT-AC68U except needing a physical reboot after the update.

See my post a page or so back, I have the same problem. Try upgrade from the terminal.


Sent from my iPhone using Tapatalk

 

[ankhazam]

My AC87U upgraded flawlessly from 62->63_0->63_1->63_2

 

[xenas]

Hello

New here in this nice place

Let me ask you guys a question, is it safe to upgrade from 63_0 -> 63_2 on the N66U, without doing a factory reset after the upgrade ?

Thanks

 

[Wutikorn]

ask you guys a question, is it safe to upgrade from

Yes, it is normally safe to upgrade from 63_0 to 63_2 as it is basically based on the same version with just a few bug fixes.

 

[RMerlin]

Classification works properly so far but only after removing the first three lines from iptables-classification:

iptables -t mangle -D QOSO -m mark --mark 0x8000/0x8000 -j RETURN
iptables -t mangle -D QOSO -j CONNMARK --restore-mark --nfmask 0x7 --ctmask 0x7
iptables -t mangle -D QOSO -m connmark ! --mark 0x0/0xff00 -j RETURN

The first rule is used by the Merlin NAT loopback. Second and third ones are used to restore marks associated with the connection, as stored in conntrack (this allows classification to remain working throughout the life of a TCP/UDP session).

No idea why you would run into issues, rule 2 and 3 are pretty much part of most QoS scripts, unless something is messing up the packet marks. You could try just switching back to the Asus NAT loopback to see if the issue comes from the first rule.

 

[TheOldMan]

I am able to upgrade my rt-ac87u to 380.63_2 from 380.63_1 but with _2 there is no internet access. Went back to _1 and I have internet access. ??? ??? Any one know why?

 

[phrunt]

i disabled ai protection on my ac87u and my router hasn't rebooted since doing so. Only problem is i'd rather have it enabled, is this a bug in the new firmware? i never had the problem in prior versions

 

[TheOldMan]

I am able to upgrade my rt-ac87u to 380.63_2 from 380.63_1 but with _2 there is no internet access. Went back to _1 and I have internet access. ??? ??? Any one know why?

I got rt-ac87u 380.63_2 fixed by compiling from git. Hopefully it's taken care of... Internet is accessible now.

 

[ejinet]

httpd -i br0 seems to chug a significant %cpu sometimes on an n66u. haven't figured out what's causing it, reset nvram

 

[redsoxguy676]

I am currently running 380.62_1 on an RT-AC68P. Is there any reason not to upgrade to this newer firmware? I like to get some feedback before updating to the newest firmware releases that Merlin does for us! Thanks in advance!

 

[Wutikorn]

I am currently running 380.62_1 on an RT-AC68P. Is there any reason not to upgrade to this newer firmware? I like to get some feedback before updating to the newest firmware releases that Merlin does for us! Thanks in advance!

I don't have a problem at all on 380.63_2. The two main reasons I upgrade are that it 380.63_2 patches Dirty Cow vulnerability and add QoS Statistics page which allow me to set QoS priority more accurately. I had not a single problem on either alphas, betas or stable versions of 380.63, but some might have. I have RT-AC68U rev C1, AiProtection, Adaptive QoS and Traffic manager on. So I see no reason not to upgrade to newer firmware. The problem most people face is about QoS statistic page that does not show stats, not related to internet connection. Maybe you should wait a few more hours to see if others have problems on new firmware.

 

[RMerlin]

I am able to upgrade my rt-ac87u to 380.63_2 from 380.63_1 but with _2 there is no internet access. Went back to _1 and I have internet access. ??? ??? Any one know why?

There's been zero change related to WAN between 380.63 and 380.63_2. Your problem lies elsewhere.

 

[RMerlin]

I am currently running 380.62_1 on an RT-AC68P. Is there any reason not to upgrade to this newer firmware? I like to get some feedback before updating to the newest firmware releases that Merlin does for us! Thanks in advance!

380_63_1 was a beta build. Final fixes are only in 380.63_2.

 

[TheOldMan]

There's been zero change related to WAN between 380.63 and 380.63_2. Your problem lies elsewhere.

Not sure what it was. I downloaded from your site and it did not work for the rt-ac87u. So I compiled it from your git, it worked. I must have gotten a "bruised" file?

 

[chris.at]

The first rule is used by the Merlin NAT loopback. Second and third ones are used to restore marks associated with the connection, as stored in conntrack (this allows classification to remain working throughout the life of a TCP/UDP session).

No idea why you would run into issues, rule 2 and 3 are pretty much part of most QoS scripts, unless something is messing up the packet marks. You could try just switching back to the Asus NAT loopback to see if the issue comes from the first rule.

Hello RMerlin,

I tested it and no matter which type of NAT loopback is selected (even disabled), the first three rules are always there and always the same, resulting in wrong classifications. My test setup classifies udp 53 to High, tcp 80 and 443 to Medium, tcp 20, 21 and 22 to Low and anything else to Lowest.
Without these first rules the Medium counter reflects the http file upload and speedtest.net reflects to Lowest (afaik they use tcp 8080 for testing). When I leave the rules in place the Low counter reflects the same http upload, no matches at Medium anymore and speedtest.net also reflects to Low, not to Lowest anymore. But this is not specific to that actual release. BTW, a reset button to clear the statistics could be useful (only if it's simple to implement of course).

Regards,
Chris

 

[RMerlin]

BTW, a reset button to clear the statistics could be useful (only if it's simple to implement of course).

I already looked, and there's no way to reset tc's counters without deleting and recreating the rules - too disruptive.

 

[Deleted member 48827]

The first rule is used by the Merlin NAT loopback. Second and third ones are used to restore marks associated with the connection, as stored in conntrack (this allows classification to remain working throughout the life of a TCP/UDP session).

No idea why you would run into issues, rule 2 and 3 are pretty much part of most QoS scripts, unless something is messing up the packet marks. You could try just switching back to the Asus NAT loopback to see if the issue comes from the first rule.

Thanks for your feedback RMerlin.

I can confirm the same behavior as Chris on my RT-AC56U. Disabling NAT loopback didn't make any difference for me either. The only way traffic gets categorized correctly using traditional QOS is when those three rules are removed. Otherwise, all traffic goes through the "Highest" and "Low" categories. I had previously reported the categories being off by one, for which I understand an indexing problem was found and corrected. But in the versions since the indexing was corrected, I've had the problem where all traffic gets categorized into the "Highest" and "Low" categories unless the three iptables rules are removed as shown by Chris.

 

[Freddi]

Alright, Dumbass question, but after a general google search, and going tab to tab, I'm missing where AIProtect is enabled/Disabled. (I'm not lazy, i'm just missing it.....)

What am I looking right past?

 

[Zirescu]

Alright, Dumbass question, but after a general google search, and going tab to tab, I'm missing where AIProtect is enabled/Disabled. (I'm not lazy, i'm just missing it.....)

What am I looking right past?

It's only available on certain models.