Release Asuswrt-Merlin 384.19 is now available

[gattaca]

^^^^ Yeap, tried on SAT deleting the nc db.. the GC/CRC errors returned when I move the J* scripts back. Killing that file, sadly, did not work for my AC86U. Thanks for the suggestions! (See my update about this file returning)....

Update: 04:30 09/09/20 - My brain is exhausted down this 384.19 upgrade rabbit hole. Game over. My plan is to reset my AC86U to factory defaults and start over fresh with a @L&LD nuclear factory reset and go. I am at a crossroads with 384.19 in which either or/and:

1. A standard JFFS backup is somehow moving corrupted files to the a new /JFFS file system.
   1. Which I don't understand how that's possible since the tar is really a simple tar (zip) file of files which are unpacked on the target.
2. There's something wrong with ASUS's resizing of /JFFS from 48MB to 47MB which is causing CRC/GC errors with high I/O to the JFFS or the 47M JFFS filesystem has issues.
3. The "3 x bad nand blocks" as IDed on my AC86U's 384.19 boots is interfering with nand GC on 384.19.
4. The /jffs/.sys/nc/* file is somehow causing CRC/GC errors unless it is completely removed and stays removed.
5. All or none or one or more of the above are in play.

The nuclear reset is the best proven method to re-validate my AC86U is as clean as it can be before staring over. After that + below, if the CRC/GC errors return with a clean setup, then it's option # 2 a/or #3 b/c my potentially "bad JFFS" restore will be off the table.

As part of this:

1. I will not "restore the JFFS" I will start over with a freshly formatted JFFS.
2. I will make sure any file in /jffs/.sys/nc/* is deleted rm /jffs/.sys/nc/* (and stays deleted)
3. I will immediately reinstall the AMTM J* scripts manually 1:1 and send their I/O to JFFS first to see if the CRC/GC errors return 1:1.
4. Then I will move my own 6+ NextDNS + other JFFS scripts manually back into /jffs/scripts
5. Install / enable Diversion + Skynet + Pixelserv after a clean few days.
6. I also considered reverting to 384.18 just to see if the CRC/GC errors stop with the J* scripts hitting the JFFS. No go b/c with 384.19 ASUS also mucked with how/way/where the login passwords are stored. This has also been mentioned a couple times in this thread by people who have reverted as yet another ASUS 384.19 gotcha.

Hopefully, I can perform these steps this weekend. In the meantime, the J* scripts will remain pointed to my USB. I'll post the outcome of the above when I have it. Stay safe, stay alive. Peace.

 

[PARC]

Hi guys I think someone also posted this error log. After upgrading to 384.19 on my AC88U I'm starting to get this error.

Any fix or just ignore? Thanks in advance!

 

[fritzk3]

I have an RT-AC86U and have been experiencing a high level of wireless client disconnects with this latest build. My current setup is Zoom cable modem hardwired via Ethernet cable to the RT-AC86U (Main) with an RT-AC68U as an AiMesh node. I've also seen a noticeable drop in wireless signal strength in 384.19 as compared to 384.18, with no physical change to the location of either router.

Is there a way to tell from the router log files whether the disconnections I am experiencing are related to the wireless client disconnecting from the router/node, or a failure of the cable modem to send a signal to the router?

 

[XIII]

I have an RT-AC86U and have been experiencing a high level of wireless client disconnects with this latest build.

Same here...

Also curious what we can do about it!

 

[ugandy]

Same here...

Also curious what we can do about it!

same here. sometimes 2.5 other 5Gghz

 

[Meeshaw]

Same here too. Happened to me today on 2.4 and 5 Ghz. Devices couldn't connect to wifi anymore. The wifi is visible but no connection can be established. Restart wifi or router solves the problem for me (temporarely).

Edit: Forgot to mention that I did a factory reset after upgrade and reconfigured all settings manually

 

[jsbeddow]

Same here (on 384.19 final, and even now 5 days after a full "nuclear"reset) , but only noticing 5Ghz symptoms as others reported above, and consistently only after about 5 days uptime. Wireless is semi-functional at that point, sometimes devices will connect, sometimes not, but either way they don't connect out to the internet without rebooting the router. Will soon have to revert to 384.18 and patiently wait for 386.1 releases . Just hope that the new smaller/re-formated jffs partition size does not cause any additional gotchas on reverting to 384.18.

 

[Lotta Cox]

Uptime: 29 days 18 hour(s) 57 minute(s) 59 seconds on 384.19_beta2
72 wireless clients. No scripts! Log squeaky clean
Not touching a THING!

 

[gattaca]

...Will soon have to revert to 384.18 and patiently wait for 386.1 releases . Just hope that the new smaller/re-formated jffs partition size does not cause any additional gotchas on reverting to 384.18.

Warning: I do not believer there's a way backward from 384.19 to 384.18 without a nuclear reset! Why? More changes in ASUS's handling the router login PW. Several earlier posts mention that gotcha. IDK, maybe if you set the default userid and then blank for the password you might get away with a revert. But don't count on it. I'm seriously considering going back to 384.18 with my nuclear reset.

 

[jsbeddow]

Warning: I do not believer there's a way backward from 384.19 to 384.18 without a nuclear reset! Why? More changes in ASUS's handling the router login PW. Several earlier posts mention that gotcha. IDK, maybe if you set the default userid and then blank for the password you might get away with a revert. But don't count on it. I'm seriously considering going back to 384.18 with my nuclear reset.

Yes, I have seen posts that seem to indicate this, but not 100% positive. Will report back when I do this (and I might just try the username password trick you mentioned).

Edit: I may hold off on reverting to 384.18 for a few more days, as my issue seems more related to wireless performance (more so than general router stability). I will try a few tweaks to the Wireless Professional settings page and try again to run for 5-7 days: if it can go that long without a lockup, I am fairly confidant it can go longer. If not, my problem could still be a symptom of the radio(s) dying, which sadly is not unheard of for the RT-AC86U .

 

[dave14305]

Unless this thread deserves a longer life as the terminal release for 384, it really has become depressing and should be put out of its misery. JFFS backups, J* scripts (no offense @Jack Yaz), passwords...

Of course that’s only my opinion as an AC68U user suffering no ill effects...don’t hate me because I’m stable...

 

[QuikSilver]

Unless this thread deserves a longer life as the terminal release for 384, it really has become depressing and should be put out of its misery. JFFS backups, J* scripts (no offense @Jack Yaz), passwords...

Of course that’s only my opinion as an AC68U user suffering no ill effects...don’t hate me because I’m stable...

It has become a wash and repeat of comments regarding Jffs resizing issues.

 

[gattaca]

1. rm /jffs/.sys/nc/nt_center.db (backup it up if you are paranoid - I have seen zero impact on removal)
2. Reboot
My last error was shortly before the steps above (on both routers).
Hope it helps some people (with a more complex setup).

Update: 10 Sep 2020 06:00 - The AC86U ran with J* scripts hitting JFFS without CRC/GC errors for nearly 48 hours once I deleted the even small nt_center.db. Around 06:00AM today, the GC/CRC errors returned. I checked there was nothing in the /jffs/.sys/nc/* dir this time. The size of the /JFFS had grown from 6.9MB (with no J* scripts on JFFS) to ~ 10.8MB with still 36.2M free with the J* scripts hitting it. I moved the J* scripts I/O back to USB, rebooted. As 11:45, no GC/CRC errors, no nt_center.db and /JFFS size is back to 6.9MB. I'll execute my plan to wipe and start again this weeked.

I have a good (not conclusive) reason to think now that this file /jffs/.sys/nc/nt_center.db may be related to the CRC/GC errors on my unit. I wiped it out on SAT and then it returned sometime on Saturday when I was not looking for it. Since I removed it earlier today, I've seen no CRC/GC errors but I have more testing to do. I'm still going to nuclear-reset this AC86 b/c it's been through the wringer. I cannot comment on the wireless dropping - that's the least of my concerns vs a full /JFFS...

My .o2 for the AC86U owners who've had no issues - count yourself *@(*@* lucky! I wish I could claim the same.

While I don't own this thread, I'd vote for not locking it. Why? B/c if those of us still dealing with the AC86U fallout do find a root-cause, it's going to benefit those lucky AC86U owners in the same boat - now or later. Not my call though - stay safe, stay alive. Peace.

 

[fritzk3]

I can confirm the password issue is real when reverting from 384.19 to 384.18. I reverted my RT-AC86U today, and the very first time I tried to log back into the GUI, my credentials were denied... same with admin/admin and admin/(blank). Not surprisingly, I was also denied when trying to SSH into the router.

My connection seems to be more stable, though, and signal strength a bit higher than on 384.19, so that's something.

Planning to factory reset tomorrow, flash 384.18, and start fresh, including reformatting my USB drive and reinstalling all of the amtm scripts. It'll be a bit of a pain to go through and tweak all of the settings again, but I need to have access to the GUI! Once all is up and running in a stable manner, I'll back up the config in case I have to go through this again.

 

[Adamm]

I can confirm the password issue is real when reverting from 384.19 to 384.18. I reverted my RT-AC86U today, and the very first time I tried to log back into the GUI, my credentials were denied... same with admin/admin and admin/(blank). Not surprisingly, I was also denied when trying to SSH into the router.

This isn't an issue, as has been mentioned dozens of times now the password string is now encrypted upon upgrade to 384.19, so when you then downgrade to 384.18 your router isn't able to decrypt this string.

 

[thecheapseats]

this is the first time I've set an SNB thread on a current merlin release to 'ignore'... kill me now please...

 

[Meeshaw]

Uptime: 29 days 18 hour(s) 57 minute(s) 59 seconds on 384.19_beta2
72 wireless clients. No scripts! Log squeaky clean
Not touching a THING!

Just downgraded to beta 2. Will see if this solves the problem.

 

[MarkyPancake]

My current setup is Zoom cable modem hardwired via Ethernet cable to the RT-AC86U (Main) with an RT-AC68U as an AiMesh node. I've also seen a noticeable drop in wireless signal strength in 384.19 as compared to 384.18, with no physical change to the location of either router.

When I updated my AC86U router and AC68U node to 348.19, I noticed the reported DWB signal strength between them was one bar weaker (1/4 bars instead of the consistent 2/4), without either of the devices being moved or touched in their respective locations. I increased the 5 GHz transmit power in the settings, which got it back to 2/4 bars.

 

[fritzk3]

When I updated my AC86U router and AC68U node to 348.19, I noticed the reported DWB signal strength between them was one bar weaker (1/4 bars instead of the consistent 2/4), without either of the devices being moved or touched in their respective locations. I increased the 5 GHz transmit power in the settings, which got it back to 2/4 bars.

Interestingly, for me the GUI was reporting a strong 5 GHz signal between the 86U and the 68U - 4/4 bars. (No change from previous release.) Where I noticed the difference was at the locations where I was using a wireless device - my laptop had previously been getting 3/4 bars at the desk where I work, but after 384.19 was usually maxing out at 2/4, and sometimes clinging to just 1/4. In the past 24 hours it seems like 384.18 has been both more reliable (no dropped connections) and the signal strength has been better. I think I'll stick with 384.18 for a bit and see how things go.

I'm also interested to see whether users report more stability with 384.19 beta 2.

 

[taffeys]

AC86U Router on 384.19 Uptime 10 days 23 hour(s) 35 minute(s) 44 seconds
AX58U AP on 384.19 Uptime 24 days 18 hour(s) 11 minute(s) 39 seconds

Wired clients = 5
2.4 GHz clients = 7 to 10
5 GHz clients = 4

No issues at all