[Beta] Asuswrt-Merlin 384.14 Beta is now available

[Hawk]

Is the Dual-WAN code still closed-source?

Majority of code is closed source, rest of it is scatter to much to make sense.

 

[bbunge]

RT-AC66U_B1 dirty upgrade from 384.14 alpha2 went well. Am using dual WAN with a Samsung J3V (CenturyLink is a week late getting service to my new house). Very pleased with this beta.

 

[GHammer]

When applying update to my 86U, as soon as I selected the file for upload, I saw Applying Settings, Please Wait. Didn't have to choose apply or anything.
Nothing more, so I waited until I saw the LEDs return to normal then refreshed the browser to get the router login page.

If this is the intended result, I vote for the old progress info to return.

 

[CaptainSTX]

When applying update to my 86U, as soon as I selected the file for upload, I saw Applying Settings, Please Wait. Didn't have to choose apply or anything.
Nothing more, so I waited until I saw the LEDs return to normal then refreshed the browser to get the router login page.

If this is the intended result, I vote for the old progress info to return.

When upgrading my AC86 I saw the progress bar. Process seemed the same as always.

 

[RMerlin]

Is the Dual-WAN code still closed-source?

Nothing has changed there. Some of it is open-source, but a complete mess that I can't understand since the code isn't commented. The routing table code is still closed source, and there is no reason for this to ever change.

Nov 8 00:04:41 kernel: nf_conntrack: automatic helper assignment is deprecated and it will be removed soon. Use the iptables CT target to attach helpers instead.

Just a kernel warning from kernel 4.1.x, has always been there.

 

[RMerlin]

When applying update to my 86U, as soon as I selected the file for upload, I saw Applying Settings, Please Wait. Didn't have to choose apply or anything.

Has been the case since AiMesh was enabled, because this is how Asus has implemented it in the AiMesh-aware firmware update code.

Nothing more, so I waited until I saw the LEDs return to normal then refreshed the browser to get the router login page.

Must have been something with your browser, because the progress bar is still there, unless your browser failed to execute the Javascript code (which hasn't changed recently).

Note that this code is from your current firmware, NOT the new firmware (which isn't even loaded yet).

 

[Elmer]

384.13 to 384.14 (dirty). Working nicely on the ax88. I know this is not Merlin code specific, but I had some problems getting AImesh back on line. What is the proper upgrade sequence? I did:

1. Update main router (Merlin code - 384.14 beta ).
2. Update AImesh router (Asus equivalent code -384_81116).

Had a heck of a time getting the mesh back on-line. Had to reset the mesh unit several times, and move the unit closer to the main router. Should I have done this in the opposite order?

 

[easyriider]

Updated my AC86U and everything is working fine.

When I look at Tools/Sysinfo HW acceleration, runner and flow-cache are now enabled, but before on 384.13 only flow-cache was enabled without changing any settings.

 

[Hawk]

Updated my AC86U and everything is working fine.

When I look at Tools/Sysinfo HW acceleration, runner and flow-cache are now enabled, but before on 384.13 only flow-cache was enabled without changing any settings.

Most likely Broadcom enabled runner on platform.

 

[hancox]

384.13 to 384.14 (dirty). Working nicely on the ax88. I know this is not Merlin code specific, but I had some problems getting AImesh back on line. What is the proper upgrade sequence? I did:

1. Update main router (Merlin code - 384.14 beta ).
2. Update AImesh router (Asus equivalent code -384_81116).

Had a heck of a time getting the mesh back on-line. Had to reset the mesh unit several times, and move the unit closer to the main router. Should I have done this in the opposite order?

I usually remove the Mesh units on the main router, upgrade it alone, then re-add. Saves frustration of running around the house resetting.

 

[clvk07]

everything working fine. DCD tainted crash is still there, I guess asus has still not fixed it>

 

[Butterfly Bones]

everything working fine. DCD tainted crash is still there, I guess asus has still not fixed it>

ASUS can not fix that since it is Broadcom closed source.

Oops, it is for ASUS to fix.
https://www.snbforums.com/threads/r...-5-is-now-available.46575/page-15#post-406352

 

[Delusion]

everything working fine. DCD tainted crash is still there, I guess asus has still not fixed it>

I guess it will never be fixed. I found that it happens when virtual network interface is created (pixelserv-tls which comes with Diversion Standard creates one ) and AiProtection is ON .

I hope Asus noticed that.
DCD= Data Collection Daemon

https://www.snbforums.com/threads/s...ion-dcd-crashing-is-guilty.55416/#post-500843

 

[Dave Moseley]

RT-AC68U: Soon after 14_Beta_1 upgrade, Windows 10 reboot required to regain IPv6 stack. Reboot also required for local Raspbian (stretch & buster). Reboot fix is temporary as problem soon returns. ISP is Comcast.

Restoring AC68U to 384.13 seems to have resolved the problem. I'll update otherwise.

 

[nlurker]

I found that it happens when virtual network interface is created (pixelserv-tls which comes with Diversion Standard creates one ) and AiProtection is ON .

I have AiProtection OFF and I get DCD tainted crashes constantly.

 

[Butterfly Bones]

I have AiProtection OFF and I get DCD tainted crashes constantly.

There are two workarounds.
Easier
https://www.snbforums.com/threads/script-to-remove-dcd-crashes-from-system-log.54734/

More powerful with enhanced logging.
https://www.snbforums.com/threads/scribe-syslog-ng-and-logrotate-installer.55853/

 

[FLA_NL]

Did a dirty flash over 384.13 yesterday evening CET. This morning the DHCP was not working, the router indicated internet was down and the CPU usage was constantly high. Did a reboot and everything was working again. Now it's evening again and had the same issue. Reverted back to 384.13. Log did not indicate crashes while there was a high CPU usage. Router model is RT-AC86U.

 

[pdc]

I have AiProtection OFF and I get DCD tainted crashes constantly.

It is also caused by enabling Traffic Analyzer - Statistic. When I turn that and AiProtection off, no more crashes cluttering up the log.

 

[Delusion]

There are two workarounds.
Easier
https://www.snbforums.com/threads/script-to-remove-dcd-crashes-from-system-log.54734/

More powerful with enhanced logging.
https://www.snbforums.com/threads/scribe-syslog-ng-and-logrotate-installer.55853/

This is not a workaround. It doesn't get rid of the crash ... only removes it from the log .

It is also caused by enabling Traffic Analyzer - Statistic. When I turn that and AiProtection off, no more crashes cluttering up the log.

I guess enabling QoS can also cause it...

 

[TheOldMan]

everything working fine. DCD tainted crash is still there, I guess asus has still not fixed it>

I still have this issue. Am using a script to hide it. It has to do with AiProtection enabled.