Release Asuswrt-Merlin 384.19 is now available

[mbze430]

I am still getting "WLC_SCB_AUTHORIZE sta_flags_mask not set" errors, anyone else?

 

[SomeWhereOverTheRainBow]

^^^^ Yes, we've been spoiled badly with many successful "dirty upgrades" over many Merlin releases! This resizing JFFS curveball ASUS tossed in for the AC86U may have been the straw, for some of us AC86U owners.

Over the last 3 days, have re-installed all of the J* AMTM tooling, one per day, but pointed each one where it allows in the menu, to use the USB instead of the JFFS. My USB is a SATA SSD on a uGREEN USB2SATA carrier which I've posted about before. The USB is connected to the USB3.0 port on the router. As of this AM, I am seeing no CRC errors on the JFFS at this point - nada, 0 - none since I unistalled and moved those scripts.

I think a router probably needs a full factory reset for sure. IDK about L&LD nuclear option but that may be best.

FWIW, I also found at least 2 posts from @L&LD stating when when formatting the JFFS, you need to reboot the router 3 times in the next 15 minutes (with no USB drive installed)" to allow the router time to properly format the JFFS! I did not reboot 3 times in 15 minutes, only once after I applied the JFFS format. That may be related to the JFFS CRC errors - IDK at this point - makes sense if I started using the JFFS before it was actually fully formatted... but I do recall df -h on the JFFS and seeing files still there - thinking strange... format should have wiped everything. So I am considering formatting the JFFS and rebooting 3x in 15 minutes, then putting the J* utilies back just to see. That would be very, very valuable to know.

Does anyone know if after you "format the JFFS successfully" if there are any files or default directories created by the router?

I'm trying to figure out how to best use the nvram save and restore utility to CMA. I located the thread and have been reading it. Having nvram working would make me less cautious that I'm going to botch a full reset - at least I'd have all the settings which could be restored as I've tweaked many settings over the longer haul. I saw a script that keeps like 14 days of nvram backups, that looks useful. I also need to fully backup the USB drive - just in case.

So there's some prep needed either using nvram or screen capping critical page.
I want to collect L&LD steps so I can be sure I don't miss something like "reboot the router 3 times after...."

Right now the router appears to be humming along with no JFFS CRC errors + all the AMTM J* scripts running as prior - as long as they are on USB and not JFFS.

i realized after deleting /jffs/.sys/nc/nt_center.db all my jffs problems went away

 

[Xsvrg]

Okay I have no idea what I'm doing wrong but I just can't get any internet connection on any of my devices after updating from 384.17 to 384.19. I had to roll back.
The router itself shows internet connection, I can ping addresses and update scripts through Putty, but no device (pc or phone or anything) has any WAN connection. What could be wrong? Did something change with NAT settings with this firmware that I can't find?


Using RT-AC68U

 

[JGrana]

Intel released a new driver again with additional improvements and fixes today.

I visited this page this morning. I just tried this evening (now home to download the driver) and.... the page no longer exists.

 

[maghuro]

Hello guys,
Currently I'm having an issue that started from its own.
I'm getting this log message every two seconds:


And when I open amtm, for example, it's going like that (attached). I can't run properly any script. Any clues?

AC86U-USB: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
Thu Sep 3 10:35:50 IST 2020 Disk check done on /dev/sda1

Thu Sep 3 11:18:04 IST 2020 Probing 'ext4' on device /dev/sda1
Running disk check v2.9, with command 'e2fsck -p' on /dev/sda1
AC86U-USB contains a file system with errors, check forced.
AC86U-USB: Resize inode not valid.

AC86U-USB: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
Thu Sep 3 11:18:04 IST 2020 Disk check done on /dev/sda1
---------------------------------------------------
END FILE

Any help??

 

[Xentrk]

Any help??

Looks like USB is corrupted. Happened to me recently. There are some fsck tutorials on the net. https://phoenixnap.com/kb/fsck-command-linux has good explanation. Ignore the need to sudo.

 

[Mario64]

some bits of code from 385 were just 384 repackaged with the name 385.... the only code branch that is truely different is 386. 384 and 385 share same fixes with just different names on the package. @RMerlin decided against changing the name on his package since the code bases virtually identical. However he is changing for 386 because the branch code is changing.

"edit"
For those who are curious just follow RMerlins github commits.

Bumped revision to 386.1 · RMerl/asuswrt-merlin.ng@ad3da4f

Third party firmware for Asus routers (newer codebase) - Bumped revision to 386.1 · RMerl/asuswrt-merlin.ng@ad3da4f

github.com

I have "YET" to see @RMerlin not include a security fix once it has become available to him. Naming is just naming.

Thank you

 

[maghuro]

Looks like USB is corrupted. Happened to me recently. There are some fsck tutorials on the net. https://phoenixnap.com/kb/fsck-command-linux has good explanation. Ignore the need to sudo.

Thanks pal. Just formated the USB and all good now....

 

[Cranium]

Everyone was out of house today so I took advantage and finally updated the firmware on my AI mesh. I did a dirty upgrade from 384.17 to 314.19.

I am running the AX-58U as the router and the AC 3100 as the node.

The mesh has been running for 5 hours now and the speeds are great and there are no issues. At least none that I know of!

My thanks to RMerlin!

 

[Deleted member 22229]

AX58U here been running 19 final since release and not a single issue works excellent. Looking forward to testing the 386 code base possibly over the long weekend off work. Well just hoping anyway likely wont be any Alpha releases. But maybe..

 

[doczenith1]

Well I have no idea what was causing my issues but they are gone! The vpn client is up and spdmerlin is running with no errors in the log. My 86U is functioning just fine now.

Well I spoke too soon. As you can see the errors appear to start out of nowhere and then something triggers it every minute. Any ideas on what may be causing it? I think I'm going to Format JFFS partition at next boot again and do a number of reboots before restoring.

 

[SomeWhereOverTheRainBow]

Well I spoke too soon. As you can see the errors appear to start out of nowhere and then something triggers it every minute. Any ideas on what may be causing it? I think I'm going to Format JFFS partition at next boot again and do a number of reboots before restoring.

View attachment 25953

Here is a step by step guide i did before flashing 384.19.

Before flashing to 384.19 from 384.18,
I manually deleted /jffs/.sys/nc/nt_center.db
then I made a backup of JFFS.
Then I flashed 384.19-
Then i started getting the errors. I quickly erased JFFS using the erase option.
I then restored JFFS using the back up i made.
I had no issues after this.

here is a sample of the logs

Aug  7 00:08:15 RT-AX88U kernel: jffs2: Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is 0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
Aug  7 00:08:15 RT-AX88U kernel: jffs2: jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Aug  7 00:08:15 RT-AX88U kernel: jffs2: Error garbage collecting node at 03c7a2fc!
Aug  7 00:08:32 RT-AX88U kernel: jffs2: Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is 0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
Aug  7 00:08:32 RT-AX88U kernel: jffs2: jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Aug  7 00:08:32 RT-AX88U kernel: jffs2: Error garbage collecting node at 03c7a2fc!
Aug  7 00:08:32 RT-AX88U kernel: jffs2: Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is 0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
Aug  7 00:08:32 RT-AX88U kernel: jffs2: jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Aug  7 00:08:32 RT-AX88U kernel: jffs2: Error garbage collecting node at 03c7a2fc!
Aug  7 00:08:32 RT-AX88U kernel: jffs2: Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is 0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
Aug  7 00:08:32 RT-AX88U kernel: jffs2: jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Aug  7 00:08:32 RT-AX88U kernel: jffs2: Error garbage collecting node at 03c7a2fc!
Aug  7 00:08:32 RT-AX88U kernel: jffs2: Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is 0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
Aug  7 00:08:32 RT-AX88U kernel: jffs2: jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Aug  7 00:08:32 RT-AX88U kernel: jffs2: Error garbage collecting node at 03c7a2fc!
Aug  7 00:08:32 RT-AX88U kernel: jffs2: Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is 0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
Aug  7 00:08:32 RT-AX88U kernel: jffs2: jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Aug  7 00:08:32 RT-AX88U kernel: jffs2: Error garbage collecting node at 03c7a2fc!
Aug  7 00:08:32 RT-AX88U kernel: jffs2: Argh. No free space left for GC. nr_erasing_blocks is 0. nr_free_blocks is 0. (erasableempty: yes, erasingempty: yes, erasependingempty: yes)
Aug  7 00:08:32 RT-AX88U kernel: jffs2: jffs2_reserve_space_gc of 196 bytes for garbage_collect_dnode failed: -28
Aug  7 00:08:32 RT-AX88U kernel: jffs2: Error garbage collecting node at 03c7a2fc!

These were from August 7th. I have not had an issue since.

 

[Xentrk]

Not sure I've seen this method mentioned. The primary difference is to disable jffs and reboot the router before applying 384.19. Then, once the router boots back up, enable/format jffs and reboot. Then, restore jffs from backup.

1. Make backup of JFFS of System Configs
2. >>Enable JFFS custom scripts and configs - No
3. >>Reboot
4. unmount USB
5. Flash 384.19
6. >>Enable JFFS custom scripts and configs - Yes
7. >>Format JFFS partition at next boot
8. Reboot
9. Restore JFFS from backup

I have one offsite location with an AC86U left to do and prefer to connect via VPN to perform the upgrade. Not sure if the jffs errors would prevent my ability to reconnect over the VPN connection. In theory, the above steps should prevent the jffs errors. VPN connection shouldn't be impacted if jffs is not enabled.

 

[gattaca]

Thanks pal. Just formated the USB and all good now....

the fsck might have repaired the error but if you can format the USB, that's the best longer term solution. You get these if the USB is yanked without the filesystem flushing buffers or maybe loss of power.

 

[gattaca]

As you can see the errors appear to start out of nowhere and then something triggers it every minute. Any ideas on what may be causing it? I think I'm going to Format JFFS partition at next boot again and do a number of reboots before restoring.

The flash is performing garbage collection (GC) on the media. It is getting CRC errors which means the data at that storage location is corrupted. See my several posts over the past few pages.

What I've done is move the J* AMTM scripts to use the USB drive fore now. I rebooted the router b/c at this point the JFFS flash is likely "full or not writable" I then moved all of the J* amtm scripts to use the USB... (open the menu on each, there is an option) and then rebooted the router. The CRC errors ceased b/c the J* scripts are not hammering the flash media anymore.

That does not mean the flash media is OK. I am so very suspect now that the format really did not complete properly or my flash nand media is failing.

The mistake I think I made (unless my flash media is really failing) is that @L&LD recommends that when formatting the JFFS, you do the steps I outlined in this post. See steps 7, 8, 9, 10 -> https://www.snbforums.com/threads/r...19-is-now-available.65801/page-24#post-615322

You disconnect the USB drive in the GUI, then remove the drive physically, then select to format the flash on next reboot. Hit Apply. Now reboot # 1. Let the router site for 5-10 minutes. Now reboot # 2. Let the router site 5-10 minutes. Now reboot # 3. Let the router sit 5-10 minutes. Now you restore the JFFS backup, reconnect the USB and reboot one more time. Check things out. He said these 3 reboots were required for the router to properly format the flash. He's posted this procedure several times in the past year or so.

I have not tried those repeating steps yet, but I will this weekend. I did not do the 3 reboot pass when I flashed to 384.19. I am also suspect of this file posted earlier. IDK what it does exactly. -> "/jffs/.sys/nc/nt_center.db"

Maybe this is a warning about us hammering the JFFS (cheap flash nand) so maybe moving the J* AMTM scripts to a real USB/SATA/SSD is better long term. IDK. YMMV.

See also -> https://www.snbforums.com/threads/r...19-is-now-available.65801/page-26#post-615897
See also -> https://www.snbforums.com/threads/r...19-is-now-available.65801/page-27#post-616090

 

[gattaca]

Not sure I've seen this method mentioned. The primary difference is to disable jffs and reboot the router before applying 384.19. Then, once the router boots back up, enable/format jffs and reboot. Then, restore jffs from backup.

Good call. I had already thought about adding this to the steps. Then the multi-reboot format... Not tried.

 

[gattaca]

Then i started getting the errors. I quickly erased JFFS using the erase option.

Please explain "use the erase option" is there a command to "erase" the JFFS manually? I would think the JFFS has to be unmounted to perform a format etc ... on it. which is why ASUS has you reboot the router... it has code to "format the JFFS" before releasing it is my guess during boot time.

 

[dazedandlost]

A data point, perhaps: 384.19 RT-AC86U seems to work mostly without issue. Always, but after some time, it will stop accepting browser connections to the gui. As many as four or five different browsers. Manual logout seems to delay this behaviour. Almost always a “reboot” via putty has fixed it but this morning putty reports “connection refused” on first attempt and not found after that. Ping succeeds. A hard reset resolved it. This is after a “nuke and factory default clean” upgrade. The router is set to reboot nightly.

 

[doczenith1]

Does this give us any clues as to what is happening?

 

[New2This]

So far so good, running this firmware