[Release] Asuswrt-Merlin 384.14 (and 384.13_2) are now available

[Volfi]

Did a dirty upgrade from Beta2 -> Beta3 -> final on AC86U, via remote OpenVPN connection, and all is well.

 

[AntonK]

Updated my RT-AC88U from Beta 3 to 384.14 final. All stable and working great. Thanks RMerlin!

 

[HyperCris]

I updated my RT-AC86U from 14_beta3 to 14.0 without any problem and it's working pretty good (BTW thanks RMerlin). I only noticed
that if you disable the LEDs from the GUI then, when you use the back button on the router (the one that enable/disable the LEDs) you
get only the WIFI's LEDs enabled, I don't know if this is the expected behavior and, frankly, I never tested it on the beta, anyway the GUI does
what it supposed to do.

 

[SeniorWumpo]

Having an issue with an AC86U on 384.14 (both stable and beta 3).

When running a USB 3.0 HDD, my core 1 usage is pinned at 100%, leading to the CPU sitting at 80C constantly.
Checking top on SSH, I get that smb.conf is the culprit consuming initially 49%, then splitting into two smb.conf consuming 24% each, and then 4 at 12% each... Etc until I have ~50 of them at 0.8% each in about 4 hours.

Changing to SMB 1 only fixes this but I get continous Samba errors in my log that lead to instability over about a day.

"Dec 15 09:27:01 smbd[6444]: [2019/12/15 09:27:01.031110, 0] smbd/process.c:525(init_smb_request)
Dec 15 09:27:01 smbd[6444]: init_smb_request: invalid wct number 254 (size 106)"

Reverting back to 384.13 fixes the issue immediately and core usage is back to normal.

 

[^Tripper^]

I had noticed this issue sometime ago on my 1900P unit on 384.13 with a USB drive with a swap file. Thought it was a firmware issue as all other functions of the router were fine. I eventually started experiencing strange performance issues and decided to try formatting a new USB drive using AMTM and transferring my configs over to the new drive. Once I Did this, performance issues went away and my processor cores went down to normal.

Tried that but issue persists. Thanks for the suggestion.

If miniDLNA is configured to refresh its database at startup it does so using a lot of CPU this also happen when you insert the disk.

Not using DLNA but you gave me an idea. I checked samba share and it was turned on. Turned it off and problem solved. Turn samba share on, and core 2 goes berserk. Repeatable every time. As I don't need to share the disk, this solves the problem for me thou I guess its something folks may need to check should they face the same problem.

 

[HyperCris]

Tried that but issue persists. Thanks for the suggestion.



Not using DLNA but you gave me an idea. I checked samba share and it was turned on. Turned it off and problem solved. Turn samba share on, and core 2 goes berserk. Repeatable every time. As I don't need to share the disk, this solves the problem for me thou I guess its something folks may need to check should they face the same problem.

I use DLNA and Samba shares but I don't experience the same behavior except when I insert back the disk. For sure, Samba behavior is somehow changed because now on Linux
, to avoid "strage" locking issues. I need to mount my CIFS shares with "cache=none". I'm very happy with Samba transfer performance though

 

[RMerlin]

Any recommendations to help me get 384.14 working?

After protocol level changes, your client computers must be rebooted to force them to re-negotiate the supported protocols. Windows does not do this at access time, only at first connection time.

Why doesn't the IP update script work in /jffs/scripts/services-start?

Because that is executed way too early in the boot process, your network is probably not even up and running yet at that point.

Asus DDNS still fails to update for me because of wrong certificate.

It will report the certificate error but will still complete correctly.

Weird issue. Upgraded my AC86U and saw CPU core 2 pegged at 100%. Did a nuclear reset (was time to anyways) and a M&M config. And still, the moment I plug in a usb disk, core 2 maxes out. Tried different disks, both usb 2/3 ports but issue persists.

Look at the running processes. Could be the DLNA server re-indexing the content for instance.

 

[RMerlin]

"Dec 15 09:27:01 smbd[6444]: [2019/12/15 09:27:01.031110, 0] smbd/process.c:525(init_smb_request)
Dec 15 09:27:01 smbd[6444]: init_smb_request: invalid wct number 254 (size 106)"

It means you have a client device accessing the disk share as soon as it becomes available, causing the high CPU load (Since these routers are not NAS, they are not optimized for SMB sharing). Changing the protocol simply prevented your client from being able to access the network share, therefore generating these error messages as they try to connect.

 

[^Tripper^]

Look at the running processes. Could be the DLNA server re-indexing the content for instance.

Thanks for the reply Merlin. DLNA was not turned on and It happened on all disks I tried; be it blank, reformatted etc. Finally got it to stop when I turned off SMB share.

 

[L&LD]

Excellent. I know what it was: I was getting mixed up with the warnings over risks of updating firmware remotely. I’ll now go back to updating wirelessly, confident it’s not slap-dash.

When I have a person I can trust at that remote location (or, I know I will be there the next day at the latest), I have used remote flashing successfully many times. I logically concluded that flashing via WiFi or flashing via WAN, it is effectively the same thing. Maybe @RMerlin can shed some thoughts on this for us?

For reference, I have never needed the other person to do anything than a simple reboot of the router (and even then, less than 3 times in the last 4 years). Most times, if I'm patient enough, I can see the OpenVPN connection go live, die and then live again after a flash. No routers were lost, but I would advise others to tread cautiously until RMerlin can share his experience here with us.

 

[dosborne]

I have used remote flashing successfully many times.

Although not necessarily remote, it has been many years since I've done an update via wired. I always use wireless, but I am prepared (as you are) in case it doesn't work. (Fortunately I don't have an 86U as the soft boot is borked)

 

[SeniorWumpo]

It means you have a client device accessing the disk share as soon as it becomes available, causing the high CPU load (Since these routers are not NAS, they are not optimized for SMB sharing). Changing the protocol simply prevented your client from being able to access the network share, therefore generating these error messages as they try to connect.

This is not an issue with 384.13 though. Works fine currently.

 

[Protik]

Did a dirty flash on my AC68U. Everything is working fine. Except, the Internet status is shown as disconnected in the Network Map. Turned off Network Monitoring by both DNS Query and Ping as suggested elsewhere.

Any help regarding this?

 

[rgnldo]

I've always understood in topics like this the return on some fw failure. Ends in end-user support. I admire the patience of the forum members.

 

[Diamond67]

RT-AC68U: dirty upgrade from .13 to .14. Upgrade itself went fine but am now hit with this:

Went to the Administration->System page, no Network Monitoring was enabled. Tried Ping, no luck. Tried DNS Query, no luck. It appears to be a visual problem only, access to the internet is working.

Just updated from .13 to 384.14. I don't have this problem. I have internet status : Connected as usual, and I have Network Monitoring DNS Query enabled.

 

[ShawnTRD]

So after updating my 87 I'm still seeing 384.13_1 not 384.13_2. The file name I have is RT-AC87U_384.13_2

 

[martinr]

When I have a person I can trust at that remote location (or, I know I will be there the next day at the latest), I have used remote flashing successfully many times. I logically concluded that flashing via WiFi or flashing via WAN, it is effectively the same thing. Maybe @RMerlin can shed some thoughts on this for us?

For reference, I have never needed the other person to do anything than a simple reboot of the router (and even then, less than 3 times in the last 4 years). Most times, if I'm patient enough, I can see the OpenVPN connection go live, die and then live again after a flash. No routers were lost, but I would advise others to tread cautiously until RMerlin can share his experience here with us.

You wouldn’t be describing it as a “simple reboot” if it was my wife on the other end of the phone and you were trying to explain where the on/off switch was and what to do with it. You’d vow never to try a remote flash again, even if you only needed the remote reboot once in a thousand times.

 

[Val D.]

You wouldn’t be describing it as a “simple reboot”

Keep your ISP router as router, buy a smart power plug, connect RT-AC86U to the smart plug, reboot remotely when needed. This procedure should be included in RT-AC86U User Manual in order to prevent unpleasant surprises during reboot.

I'm upgrading my network as we speak, it's still work-in-progress with the hardware/software in my signature, but I'm getting rid of ASUS as main router completely. Will probably leave it as a backup router running Asuswrt 45717 or just throw it away, haven't decided yet.

 

[octopus]

I like Aimesh link speed, someone else seeing this?

 

[Rbej]

384.15 incomming

https://github.com/RMerl/asuswrt-merlin.ng/commits/master