What's new

[Release] Asuswrt-Merlin 384.19 is now available

Meeshaw

New Around Here
HI

After seeing all the talk around the RT-86U, i'm really reluctant to make the jump to 384.19. I did have a question for those who are having issues and using the RT-86U. Currently, my setup is:

RT-AC5300 as my main router
RT-AC5300 as node
2-RT86U as nodes

So, one main router and 3-nodes. My questions are:

1. Is there anyone experiencing issues with the RT-86U that is a node with this firmware?
2. Does the JFFS partition issue affect as a node?
3. Does a simple factory reset solve the JFFS partition issue.
4. Should all be well for my usage of the 86U as nodes if I flash and hard reset the nodes as I normally do?

I don't do any extra settings once flashed. No customization, usually just dirty flash, wait a bit, unplug and replug for the router and flash then hard reset for the nodes. I have about 110 devices connected so I know it can be a P.I.T.A. if things aren't functioning as expected while upgrading (as was my experience when trying to upgrade to 384.18).
I have the RT-AC86U configured as AP (node) behind my Cable Fritzbox and have the problem.
 
Last edited:

ceez24

New Around Here
I went ahead and updated the firmware on all devices. So far, the RT-86U are distributing devices as expected in my AiMesh setup. Nothing out of the norm as yet, but I did make sure to flash the update on the two 86U while they were nodes in the AiMesh and then hard reset afterwards and added them back to the mesh setup. The rt-ac5300 node is performing fine and so is the rt-ac5300 aimesh router. I'll monitor for anything out of the ordinary.
 

gattaca

Senior Member
My son complained last night about 23:00 that the "internet was not working" so I took a look. The AC86U had been up about 10 hours - running 384.19 + AMTM+ J1* scripts to USB/SSD (it's not been nuclear reset yet) I caught the AC86U slamming pCPU for no clear reason. I put the logging mode into debug and nothing was screaming except some a*&*&* in Russia/Urkrane are scanning lots of ports all the time. It was clear DNS resolution was not working well. When the pCPU peaks and stays there, I got no DNS, when it dropped from time to time, I could get DNS to resolve normally.

IDK if this related to other AC86U issues being reported. IDK why dnsmasq was running so hot - consistently.

This went on for about 30 minutes of high pCPU before I gave up and rebooted the router. So far for the past nearly 12 hours, it's behaving but then there's the update.

1600106071231.png

After all I've seen thusfar, my advice is:
  1. If you have an AC86U and are running 384.18 well and NOT running AMTM scripts and other things, then your upgrade to 384.19 might be fine. You still lose any /JFFS.
  2. If you have an AC86U and are running 384.18 well and ARE running AMTM scripts and other things, then your upgrade may have major headaches. Right now, a nuclear reset + full manual re-set of all the scripts + AMTM settings is probably the best option - though I still have my doubts from other postings on other issues: dropped radios, reboots, etc... I've not done the nuclear reset yet yet but moved the J* scripts to use USB. So far, no more /JFFS errors when that's set that way. But I think it's only a matter of time before that fails too.
Update 14 Sep 20 14:00 - This seems to be happening now every ~ 10-14 hours.. I just reboot the AC86U again for same issues as last night around 23:00. This went on for more than 30 mins with high CPU per above capture.

Game over. My AC86U needs a full nuclear wipe. I will be returning to 384.18. Reliability, Availability, Serviceability and Security are required above all else.

1600106268185.png
Update 15 Sep 2020 - The AC86U @ 384.19 rebooted itself in the early AM today without warning. This is a couple of times where it does an unplanned reboot without warning - that I know about. :( I had log level debug active. There's nothing in the logs to indicate an issue - boom, rebooting. I am removing all of the J* nice tooling for now. Attempting to stabilize until I can wipe this AC86U and return to 384.18 which ran for months without so much as a single issue or reboot.

From a customer's PoV, ASUS resizing (not RMerlin) the /JFFS partition + whatever else got picked up is a major FUBAR by ASUS. 384.19 has turned my perfectly fine AC86U running 384.18 + AMTM scripting into a quagmire of issues.

YMMV with 384.19. If you are having no issues, that's awesome - count your lucky stars! Stay safe, stay alive. Peace.
 
Last edited:

bbunge

Very Senior Member
Decided last night to try 384.19 one more time. Had Asus 384.82072 running. Rebooted the router, flashed Merlin 384.17, powered router off and did WPS factory reset, did minimal setup with SSID and user/password, flashed 384.18 (checked the /jffs size was at 48 MB), flashed 384.19 (checked that the /jffs was mounted it was and resized to 47 MB), finished configuring router with DoT, DNS Filter and reserved IP addresses, DDNS and VPN. All well so far.
Edit: I should add that I did not have to format the /jffs.
 
Last edited:

lattugatartaruga

New Around Here
hello, just got a new ax88u and flashed it with merlin 384.19 and I'm planning to set it up as my main - along with 2 x ac86u aimesh nodes that have the latest stock 384.82072 fw ... any point in flashing merlin on the nodes at this point? i have not seen many reports of people running 19 on both these models in mesh mode in my searches so far so I thought I would kindly ask - tia - massive thanks to merlin and everyone on the forum - amazing support :)
 
Last edited:

nzwayne

Regular Contributor
hello, just got a new ax88u and flashed it with merlin 384.19 and I'm planning to set it up as my main - along with 2 x ac86u aimesh nodes that have the latest stock 384.82072 fw ... any point in flashing merlin on the nodes at this point? i have not seen many reports of people running 19 on both these models in mesh mode in my searches so far so I thought I would kindly ask - tia - massive thanks to merlin and everyone on the forum - amazing support :)
I've been running a RT-AX88U with 2x RT-AC86U's with 384.19 day after it was released (14th Sept? 14thAug) in Backhaul AiMESH mode, thirty clients. No problems at all, very solid. I run this way, should the AX88U "die"...I have the AC86U's already at the same code level to reconfig and make myself operational again in known code functions, until I replace the AX88U.
 
Last edited:

lattugatartaruga

New Around Here
I've been running a RT-AX88U with 2x RT-AC86U's with 384.19 day after it was released (14th Sept?) in Backhaul AiMESH mode, thirty clients. No problems at all, very solid. I run this way, should the AX88U "die"...I have the AC86U's already at the same code level to reconfig and make myself operational again in known code functions, until I replace the AX88U.
I appreciate the quick response and feedback. I went ahead and set this up with the ac86u's running stock for now and so far so good (too early to tell though)...should I run into issues, I will try to merlin the nodes as well, thank you again! :D
 

tyreman

Regular Contributor
Asuswrt-Merlin 384.19 is now available for all supported models, except for the RT-AX56U (no up-to-date GPL available for that model).

The main changes of this release are the merge of GPL updates, and a nearly complete rewrite of the OpenVPN implementation (functionality should remain mostly unchanged, aside from a few minor things documented in the changelog, and a few bug fixes.)

IMPORTANT: due to a flash partition layout change from Asus on the RT-AC86U, the JFFS partition content for that model may be missing or corrupted following the upgrade to 384.19. Make sure you make a backup of your JFFS partition before upgrading. If you run into issues, then reformat the JFFS partition (don`t forget to reboot), then restore your JFFS backup.

Please see the included changelog for the list of changes.

Downloads are here.
Changelog is here.
 

bbunge

Very Senior Member
running newest on 86u here and fine so far
Newest what? Newest or latest means nothing as some are running versions newer than your newest!

I know I am picky but unless you cite the firmware version and router model your post is just empty words.
 

fritzk3

Occasional Visitor
For what it's worth, since I have reverted my AC86U from 384.19 to 384.18, I have had FAR fewer connection drops. I think I'll leave it there instead of trying the nuclear 384.19 option.
 

tyreman

Regular Contributor
Newest what? Newest or latest means nothing as some are running versions newer than your newest!

I know I am picky but unless you cite the firmware version and router model your post is just empty words.
RT AC86U
384.19_0
 

jpthsd

Regular Contributor
Yepper, yesterday it happened once to me on my AC-RT86U 384.18, suddenly things went dark,,, and of course it was DNS down, exactly like your scenario. I had to reboot the AC-RT86U. Coincidentally, I disabled scheduled firmware check (I suspected this was coincidentally happened the same time 384.19_0 made available..).

Today, 09/15/2020, I had one hiccup like 15s and backed as normal (without rebooting the AC-RT86U - it is AiMesh router).

I now decided to hold off my attempt to go to 384.19 ,,,maybe until next version..! as 384.18 is pretty stable for me!

My son complained last night about 23:00 that the "internet was not working" so I took a look. The AC86U had been up about 10 hours - running 384.19 + AMTM+ J1* scripts to USB/SSD (it's not been nuclear reset yet) I caught the AC86U slamming pCPU for no clear reason. I put the logging mode into debug and nothing was screaming except some a*&*&* in Russia/Urkrane are scanning lots of ports all the time. It was clear DNS resolution was not working well. When the pCPU peaks and stays there, I got no DNS, when it dropped from time to time, I could get DNS to resolve normally.

IDK if this related to other AC86U issues being reported. IDK why dnsmasq was running so hot - consistently.

This went on for about 30 minutes of high pCPU before I gave up and rebooted the router. So far for the past nearly 12 hours, it's behaving but then there's the update.

View attachment 26213

After all I've seen thusfar, my advice is:
  1. If you have an AC86U and are running 384.18 well and NOT running AMTM scripts and other things, then your upgrade to 384.19 might be fine. You still lose any /JFFS.
  2. If you have an AC86U and are running 384.18 well and ARE running AMTM scripts and other things, then your upgrade may have major headaches. Right now, a nuclear reset + full manual re-set of all the scripts + AMTM settings is probably the best option - though I still have my doubts from other postings on other issues: dropped radios, reboots, etc... I've not done the nuclear reset yet yet but moved the J* scripts to use USB. So far, no more /JFFS errors when that's set that way. But I think it's only a matter of time before that fails too.
Update 14 Sep 20 14:00 - This seems to be happening now every ~ 10-14 hours.. I just reboot the AC86U again for same issues as last night around 23:00. This went on for more than 30 mins with high CPU per above capture.

Game over. My AC86U needs a full nuclear wipe. I will be returning to 384.18. Reliability, Availability, Serviceability and Security are required above all else.

View attachment 26214
Update 15 Sep 2020 - The AC86U @ 384.19 rebooted itself in the early AM today without warning. This is a couple of times where it does an unplanned reboot without warning - that I know about. :( I had log level debug active. There's nothing in the logs to indicate an issue - boom, rebooting. I am removing all of the J* nice tooling for now. Attempting to stabilize until I can wipe this AC86U and return to 384.18 which ran for months without so much as a single issue or reboot.

From a customer's PoV, ASUS resizing (not RMerlin) the /JFFS partition + whatever else got picked up is a major FUBAR by ASUS. 384.19 has turned my perfectly fine AC86U running 384.18 + AMTM scripting into a quagmire of issues.

YMMV with 384.19. If you are having no issues, that's awesome - count your lucky stars! Stay safe, stay alive. Peace.
 

tyreman

Regular Contributor
I have no special scripts or such running, no usb dongles or such
Even have the site checker protection off
 

jpthsd

Regular Contributor
Does anyone know when the 384_19 was push-notification to Asus Merlin (RT-AC86U specific example) router? Was it September 14th? I know it was announced by Merlin 08/15/2020 but the router's firmware notification seemed to be yesterday 09/15/2020?

Can anyone confirm? or except only Merlin? :)
 

RMerlin

Asuswrt-Merlin dev
Does anyone know when the 384_19 was push-notification to Asus Merlin (RT-AC86U specific example) router? Was it September 14th? I know it was announced by Merlin 08/15/2020 but the router's firmware notification seemed to be yesterday 09/15/2020?

Can anyone confirm? or except only Merlin? :)
It was published the same day, so at most it should have appeared within 48 hours.

Make sure you are not confusing firmware updates with Trendmicro signature updates.
 

bigcid10

Senior Member
my ddns expired on the 12th of september and the firmware hasn't updated it,is there something I can do to
update this manually or is there an issue?
Thank you
 

xdj

Occasional Visitor
Hey,

Updated to Merlin's 384.19 from 384.18 last night before bed. Nothing but problems all day. Router keeps rebooting, internet drops consistently, very slow down/upload speeds (like only 10% of normal).
Also, traffic stats are not working for individual clients as well as individual apps...bizarre. Now I'm getting a "build_sam_account: smbpasswd database is corrupt! username Download with uid 856 is not in unix passwd database!". Never have this error before!!!
No special scripts running or VPN connection, very plain setup but not working properly.
My wife is not very happy with me since all her calls and work connection kept disconnecting. And of course, TV and PVR kept stopping since I'm with Rogers Ignite system!
I'm going to go back to 384.18 firmware and see if I can get back to some normality.
I'm running AC86U as my base with an RT-AC66U_B1 as a node.
I'll get back when done...fingers crossed!!!

X
 

Xentrk

Part of the Furniture
Hey,

Updated to Merlin's 384.19 from 384.18 last night before bed. Nothing but problems all day. Router keeps rebooting, internet drops consistently, very slow down/upload speeds (like only 10% of normal).
Also, traffic stats are not working for individual clients as well as individual apps...bizarre. Now I'm getting a "build_sam_account: smbpasswd database is corrupt! username Download with uid 856 is not in unix passwd database!". Never have this error before!!!
No special scripts running or VPN connection, very plain setup but not working properly.
My wife is not very happy with me since all her calls and work connection kept disconnecting. And of course, TV and PVR kept stopping since I'm with Rogers Ignite system!
I'm going to go back to 384.18 firmware and see if I can get back to some normality.
I'm running AC86U as my base with an RT-AC66U_B1 as a node.
I'll get back when done...fingers crossed!!!

X
Did you follow the steps for the AC86U in the first post?

IMPORTANT: due to a flash partition layout change from Asus on the RT-AC86U, the JFFS partition content for that model may be missing or corrupted following the upgrade to 384.19. Make sure you make a backup of your JFFS partition before upgrading. If you run into issues, then reformat the JFFS partition (don`t forget to reboot), then restore your JFFS backup.
 

xdj

Occasional Visitor
Did you follow the steps for the AC86U in the first post?
Read it...did not do it because I thought everything was working.
I did do a back up of my partition so I can give that a go.
Thanks for the reminder.

Cheers,

x
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top