Release Asuswrt-Merlin 384.19 is now available

[Webheadfred]

Hey folks... I have an AX88u on the way, presently running an AC88u with Merlin 384.12. My plan is up flash 384.19 firmware on the new router. Is there any hidden things I should be aware of or should it be as straight forward as previously. Nothing fancy on this end just basic computing. Cheers all...

 

[ewong645]

Hi all! Dirty flash from 18 to 19 but having slow connection on wired PS4 connection. All wifi connection smooth. Mine is an AX-88U.

 

[RMerlin]

Did by chance we "wear out" this flash with all the neat utilities?

No. Just reformat the JFFS partition.

 

[doczenith1]

I can also se a significant drop in speed (client) with 384.19 build. With same config as 384.18.

For other reasons I started watching my vpn speed with Spdmerlin about a week ago. I plan on updating from .18 to .19 this evening and should be able to easily see if my vpn client speed changes.

 

[Db Major]

Hi all,

Any suggestions on wireless devices dropping off after less than a minute on the RT-AC68U with deauth_ind error (7)?

If not, can I still roll back from 384.19 to 384.18 and if so, will I need to do anything to the JFFS?

Other than this one problem after 3 years of solid operation and updates, I absolutely love the Merlin firmware! Thanks @RMerlin!

 

[gattaca]

No. Just reformat the JFFS partition.

Thank you! I found another post saying start over again with a format. Hoping third times a charm with this upgrade! Post upgrade when done. I also found quite a few posts from other AC86 owners on this extra little fun. Peace.

 

[Xentrk]

I can also se a significant drop in speed (client) with 384.19 build. With same config as 384.18.

That has happened to myself and a handful of users a few years ago with an older firmware build. If I reverted back to the prior firmware version, the speeds return to normal. The fix was to factory reset and manually enter the settings.

Also, check the support forum of your VPN provider. The outage this past Sunday impacted my provider. Not sure if there are residual issues.

 

[octopus]

That has happened to myself and a handful of users a few years ago with an older firmware build. If I reverted back to the prior firmware version, the speeds return to normal. The fix was to factory reset and manually enter the settings.

Also, check the support forum of your VPN provider. The outage this past Sunday impacted my provider. Not sure if there are residual issues.

I was forced to turn everything off as I had a heavy thunderstorm yesterday. Seem fix slow speed issue.
Maybe its related to that I tested and wrote some script. No need for factory reset this time.

 

[redbird71]

Check your system log.

Checked the log but did not see anything related to OpenVPN. Log mode was not in debug - also I have no idea what I am looking for.
I saved the current log - cleared and changed to debug mode for the next time but it appears only to happen after power loss and not all the time - so no idea when next time is going to be.

If it is of any help I could PM the logs to you.

 

[gattaca]

^^^^ Update. I reformatted the JFFS and rebooted twice last night. The JFFS size was 47M and everything looked good. I checked the logs about 20 mins afterwards and there were no CRC errors.

Now about 4 hours later, the JFFS2 errors are back. I cannot tell when they started b/c they have scrolled outta the logs view.

So formatting JFFS and restoring it from a backup I made BEFORE I upgraded to 384.19 has not solved the CRC data corruption on this router. I made multiple backups of the JFFS and have tried restoring both in separate attempts. I'm thinking this flash is failed or failing if a format did not fix this or there's something in the 384.19 code. As I stated earlier, no CRC issues ever appeared in the logs until this upgrade. (I'm seriously considering backflashing it to 384.18 code to see if the CRC errors return).

Thoughts? Actions?

I've got to keep this router online or the family will kill me. So I can only reboot / mess with it late at night or very early AMs.

ep 1 10:08:21 kernel: jffs2: Data CRC 4fa0304b != calculated CRC c3bee566 for node at 02ae3570
Sep 1 10:08:21 kernel: jffs2: read_cache_page() returned error: -5
Sep 1 10:08:21 kernel: jffs2: Error garbage collecting node at 02ae3570!
Sep 1 10:08:21 kernel: jffs2: Data CRC 4fa0304b != calculated CRC c3bee566 for node at 02ae3570
Sep 1 10:08:21 kernel: jffs2: read_cache_page() returned

Peace. Stay safe, stay alive!

 

[Clark Griswald]

@gattaca and others

I understand the Family depending upon you to keep the web up and working properly, since I also do router maintenance while the Family is asleep. I updated my devices to the RMerlin latest upon the release, and have not experienced any issues.
ALTHOUGH, I do a full reset of both my Main and AP at each fw release, since I do install RMerlin's beta releases. I have eliminated significant issues by doing a clean install of the fw release and associated scripts, and not doing a reinstall of any backups.

 

[gattaca]

^^^ There are so many settings which must be re-done and the number of white/black listed items is potentially lost... that's a quagmire in itself. There has to be a better way.... This is the first time in 10+ years I've been using the AC1900 + AC86U + AMTM (last 2 years) that I've gotten burned this badly. I guess I'm way overdue. If I find a way outta this mess without a full factory reset (or new router) I'll post more. With the crc error moving to a different node, I'm leery that the flash is failing or the 384.19 has some yet to be IDed issues. CRC errors are media-level errors on the flash... so I am very cautious. Typically when you see this in flash, it's game over for the flash. Peace.

So I rebooted b/ the JFFS became unwritable after about 12 hours.. I see this in the logs which are very early in the boot cycle.

May 5 01:05:13 kernel: jffs2: notice: (422) check_node_data: wrong data CRC in data node at 0x02ae3570: read 0x4fa0304b, calculated 0xc3bee566.
May 5 01:05:13 kernel: Loading HND Module

When I uninstalled all of the J* tooling, the CRC errors stopped hitting the logs b/c nothing is really hitting the JFFS hard now.

 

[Fuze]

Has anyone DNS problems with a running OpenVPN server on an AC86U and the to this server connected OpenVPN clients. These clients are not able to resolve domain names, but they are able to ping every service via IP (intern/extern). I've upgraded from 384.18 to 384.19 restored my settings and this issue occured...

 

[Db Major]

...and it's back to 384.18 I go.

Thanks folks, I guess nobody else has had the same wireless ~30 second dropouts issue as I have on the RT-AC68U ad the RT-AC86U?

Cheers all.

 

[doczenith1]

I was forced to turn everything off as I had a heavy thunderstorm yesterday. Seem fix slow speed issue.
Maybe its related to that I tested and wrote some script. No need for factory reset this time.

My VPN speeds appear to be same after the .18->.19 move. I installed .19 on the evening of 8/31 so not too much new data.

 

[doczenith1]

^^^^ Update. I reformatted the JFFS and rebooted twice last night. The JFFS size was 47M and everything looked good. I checked the logs about 20 mins afterwards and there were no CRC errors.

Now about 4 hours later, the JFFS2 errors are back. I cannot tell when they started b/c they have scrolled outta the logs view.

So formatting JFFS and restoring it from a backup I made BEFORE I upgraded to 384.19 has not solved the CRC data corruption on this router. I made multiple backups of the JFFS and have tried restoring both in separate attempts. I'm thinking this flash is failed or failing if a format did not fix this or there's something in the 384.19 code. As I stated earlier, no CRC issues ever appeared in the logs until this upgrade. (I'm seriously considering backflashing it to 384.18 code to see if the CRC errors return).

Thoughts? Actions?

I've got to keep this router online or the family will kill me. So I can only reboot / mess with it late at night or very early AMs.

ep 1 10:08:21 kernel: jffs2: Data CRC 4fa0304b != calculated CRC c3bee566 for node at 02ae3570
Sep 1 10:08:21 kernel: jffs2: read_cache_page() returned error: -5
Sep 1 10:08:21 kernel: jffs2: Error garbage collecting node at 02ae3570!
Sep 1 10:08:21 kernel: jffs2: Data CRC 4fa0304b != calculated CRC c3bee566 for node at 02ae3570
Sep 1 10:08:21 kernel: jffs2: read_cache_page() returned

Peace. Stay safe, stay alive!

I'm seeing the exact same stuff in my log. My upgrade process was:

0. Backup jffs
1. Safely Remove disk: for scripts flash drive and remove the usb stick,
2. install .19 and wait 5 minutes
3. checked Format JFFS partition at next boot, hit apply then reboot.
4. wait 5 minutes and reboot
5. restored jffs, waited 5 minutes and reboot.
6. plugged in flash drive during reboot
7. everything was looking good, scripts working
8. checked back after a number of hours and getting the errors that gattaca is showing above.
9. reboot and errors still there.

 

[gattaca]

^^^ That's very similar to what I did. The CRC errors surface about 4-5 hours after I restarted the router the last time with the JFFS restored... but not at first. Once all the J* amtm scripts kick in, that seems to be hammering the JFFS. I also checked a restore of the JFFS is just a simple tar file the router untars (as files) back to the JFFS.. so the CRC errors are likely already existing on the JFFS from the upgrade.

I have also reformatted the JFFS now maybe 5x and restored two different copies of the JFFS as it was before .19... nope.. CRC errors will eventually return.

What I'm doing now is I uninstalled all the J* scripts and am slowly adding them back 1 by 1.. and telling the scripts to use the USB drive (which is a real SSD)... I want to see if getting all the I/O off the JFFS behaves. So far, it has with ntpMerlin installed and pointing to USB.

This is uber frustrating as 384.18 has worked perfectly for months with no CRC errros. IDK WTF Asus did with resizing the JFFS, but it's breaking a lot of our tooling. (That peeve is NOT directed at RMerlin's excellent work!!)

At this point, while others have had no issues with the upgrade - hindsight/2020, I'd stayed at 384.18 on my AC86U for (*@(@* sure.

My detail steps -> https://www.snbforums.com/threads/r...19-is-now-available.65801/page-24#post-615322

 

[visortgw]

^^^ That's very similar to what I did. The CRC errors surface about 4-5 hours after I restarted the router the last time with the JFFS restored... but not at first. Once all the J* amtm scripts kick in, that seems to be hammering the JFFS. I also checked a restore of the JFFS is just a simple tar file the router untars (as files) back to the JFFS.. so the CRC errors are likely already existing on the JFFS from the upgrade.

I have also reformatted the JFFS now maybe 5x and restored two different copies of the JFFS as it was before .19... nope.. CRC errors will eventually return.

What I'm doing now is I uninstalled all the J* scripts and am slowly adding them back 1 by 1.. and telling the scripts to use the USB drive (which is a real SSD)... I want to see if getting all the I/O off the JFFS behaves. So far, it has with ntpMerlin installed and pointing to USB.

This is uber frustrating as 384.18 has worked perfectly for months with no CRC errros. IDK WTF Asus did with resizing the JFFS, but it's breaking a lot of our tooling. (That peeve is NOT directed at RMerlin's excellent work!!)

At this point, while others have had no issues with the upgrade - hindsight/2020, I'd stayed at 384.18 on my AC86U for (*@(@* sure.

My detail steps -> https://www.snbforums.com/threads/r...19-is-now-available.65801/page-24#post-615322

So... As far as restoring JFFS following reformatting, I use the backup made by a weekly backup automatically generated by the nsru utility (option 8 of amtm) -- my cron job is as follows:

25 3 * * Sun sh /mnt/USBdrive/nsru/nvram-save.sh #nvrambu#

Restoring is as simple as performing a recursive UNIX cp command from the backup directory (/mnt/USBdrive/nsru/backup/jffs-date-routerID/) to JFFS. Is it possible that you are not restoring ALL of the JFSS, in particular, the hidden directories from the tarball?

 

[gattaca]

Good point - unsure but not likely as I am not manually untaring the JFFS backup file. I'm restoring the JFFS backup by using the router's own GUI utility to "restore the jffs" from the earlier backup - which is a simple tar file. As I said, when I turn off / uninstall the j* amtm scripts (ntpMerlin, uiDivstats, connmon, etc, ) , the JFFS CRC errors stop immediately. So I know it is those scripts hammering the JFFS. It's not like we are filling it up the 47M b/c in-use it's like 8-9M when the scripts are enabled and like 1.4M when it is "freshly formatted." What I found interesting is that after the JFFS is "formatted", there are files and directories still there which is a bit unexpected.

What I saw today was after running for ~ 12 hours with all the scripts ON and CRC errors flying, the JFFS will report "full" and in order to make it writeable again, a reboot is required.

 

[bbunge]

Good point - unsure but not likely as I am not manually untaring the JFFS backup file. I'm restoring the JFFS backup by using the router's own GUI utility to "restore the jffs" from the earlier backup - which is a simple tar file. As I said, when I turn off / uninstall the j* amtm scripts (ntpMerlin, uiDivstats, connmon, etc, ) , the JFFS CRC errors stop immediately. So I know it is those scripts hammering the JFFS. It's not like we are filling it up the 47M b/c in-use it's like 8-9M when the scripts are enabled and like 1.4M when it is "freshly formatted." What I found interesting is that after the JFFS is "formatted", there are files and directories still there which is a bit unexpected.

What I saw today was after running for ~ 12 hours with all the scripts ON and CRC errors flying, the JFFS will report "full" and in order to make it writeable again, a reboot is required.

Bite the bullet, do a factory reset, configure manually and do not restore backups. Use Dual Band SmartConnect and no AMTM apps. If you want to do filtering use a Pi-Hole.
My AC86U is working well on 384.19!