Release Asuswrt-Merlin 384.19 is now available

[gattaca]

Per my earlier posts, the issues with the /JFFS + AC86U + many AMTM scripts (J* scripts) which default to using the /JFFS, have to do with the heavier I/O workload actually hitting the /JFFS. The J* scripts write A LOT to the /JFFS file system unless you set them to use the /USB filesystem. Under 384.19 that higher I/O rate appears to lead to the NAND the /JFFS is running on not being able to perform GC (garbage collection) b/c it cannot juggle and consolidate all the "used but not released" space being deleted with the blocks it needs to perform that consolidation properly. The TLDR: details on how NAND works is beyond the scope of this thread. But quick summary for those that care...is when the /JFFS NAND is written to so often, it seems with 384.19 the /JFFS NAND does not have time (or space) to properly perform GC (garbage collection). A symptom of that is GC and other related errors start appearing. When that happens, the /JFFS becomes "read-only / out-of-space" and it's game over. Most of us who had been running the 384.18 + many of the AMTM scripts were using the /JFFS as the storage target. Doing the same on 384.19 seems to lead to the GC issues. At first it was blamed on "you have corrupt files" on the existing /JFFS which one backed up and restored it properly and that could be very true. But then 384.18 + same scripting was not generating nor was the NAND complaining about GC errors and was running great for months. YMMV.

For those of you with an AC86U + 384.19 + running LITTLE ELSE from AMTM or just a handful of custom scripts which do not hammer the /JFFS with I/O, then all indications I have, are you will likely to have few issues with AC86U + 384.19 if you follow the guidelines.

Others have have been reporting wireless issues... but I have seen none of those b/c I fix the channels to set bands, and turn off all the "Smart" stuff and few other wireless BP which are documented for stability elsewhere in our community.

My current 384.19 + AC86U + several (but not all of the J* scripts) has now been up ~ 10 days. Before it would stay up maybe 24 hours before rebooting itself or start having GC issues. (I also turned off AI Protect which stopped the unplanned reboots) I've gotten this far only after several "AC86U ASUS HARD Factory Resets" (look that up) and starting over from ground zero with every setting on every page. The family was howling about the constant issues so at this point, I'm just leaving it be for now until I get all the J* scripts running again without /JFFS NAND or other reboot issues. Stay safe, stay alive.

 

[JGrana]

AX58U also fails to mount the JFFS and needs to be formatted after install of .19.

Interesting. I have two AX58's running 384.19 as mesh nodes. I did install Entware on one of them (running chrony),
I don't recall any jffs mount errors. I will keep an eye out.

 

[Howard_inGA]

Is the RT-AX88U having these troubles? I was considering that for my next upgrade, but that is downline several months. I'm just planning for now...

 

[New2This]

Is the RT-AX88U having these troubles? I was considering that for my next upgrade, but that is downline several months. I'm just planning for now...

Running 2 of these atm...no troubles here, with 25 devices connected ....

 

[Treadler]

Is the RT-AX88U having these troubles? I was considering that for my next upgrade, but that is downline several months. I'm just planning for now...

All good here......

 

[unsynaps]

Per my earlier posts, <snip>

Wait wait wait... people are running these things off the jffs partition and not a USB device? What?

 

[shades316]

Hi, sorry if this is covered elsewhere..

Running RT-AX88U Firmware Version: 384.19. I use the AICloud functionality and if I try to generate a share link i get error: Fail to generate share link!

Is this a known error?

 

[JonEngland]

Wait wait wait... people are running these things off the jffs partition and not a USB device? What?

They use both for different things, although the J* scripts can use either for the stats and config files, e.g.

# df -h |egrep 'Filesystem|jffs|sda'
Filesystem                Size      Used Available Use% Mounted on
/dev/mtdblock9           47.0M      4.9M     42.1M  10% /jffs
/dev/sda1                14.1G      2.4G     10.9G  18% /tmp/mnt/Kingston16G

jffs is on internal nand flash and has addons, configs, scripts etc, e.g.

# ls -lh /jffs/
drwxr-xr-x   17 ac86u    root           0 Oct  3 05:20 addons
-rw-rw-rw-    1 ac86u    root        1.6K Sep 16 20:27 cert.pem-bk
-rw-rw-rw-    1 ac86u    root        2.2K Sep 16 20:22 cert.tgz
drwxr-xr-x    2 ac86u    root           0 Oct  2 07:22 configs
-rw-r-----    1 ac86u    root        1.6K Sep 16 20:27 key.pem-bk
-rw-r--r--    1 ac86u    root        3.9K Oct  3 05:06 nmp_cl_json.js
drwxrwxrwx    2 ac86u    root           0 Oct  2 15:41 nvram
-rw-rw-rw-    1 ac86u    root           0 Jan  1  1970 nvram_war
drwx------    2 ac86u    root           0 Sep 16 21:05 openvpn
drwxr-xr-x    3 ac86u    root           0 Oct  2 16:15 scripts
drwxrwxrwx    2 ac86u    root           0 Sep 16 19:41 stunnel
drwxrwxrwx    2 ac86u    root           0 Oct  2 07:20 syslog.log
drwxrwxrwx    2 ac86u    root           0 Oct  2 07:20 syslog.log-1
drwxr-xr-x    2 ac86u    root           0 Oct  2 16:14 usericon

attached usb stores entware, swap file, nsru, skynet (logs & config) etc, e.g.

# ls -lh /tmp/mnt/Kingston16G
drwxr-xr-x   13 ac86u    root        4.0K Sep  3 14:23 entware
drwx------    2 ac86u    root       16.0K Sep 16 18:03 lost+found
-rw-rw-rw-    1 ac86u    root        2.0G Sep 16 18:16 myswap.swp
drwxrwxrwx    3 ac86u    root        4.0K Oct  2 20:11 nsru
drwxrwxrwx    4 ac86u    root        4.0K Oct  3 06:26 skynet

personally I had all the reported issues with the jffs 'corruption' and formatting it and restoring from backup did not resolve it. I tried using usb for the J* files but it killed my usb stick after a week; it became read-only and I could no longer format it (it was old so I was not surprised). I did a factory default reset from the administration section, formatted the jffs partition and reinput/setup all settings/scripts/tools manually. All J* stats/config files were left on jffs defaults and I used a newer usb stick for entware/swap. I've not had any issues since and count myself one of the lucky ones

 

[smallnetbuildpaul]

Apologies for possible noob question here.... Do we need to backup and restore JFFS on a clean install of Merlin over stock (RT-AC86U)?

 

[xdj]

2018 HWVer 1.5

45 days on and its in my opinion the best to date. I still have issues with persistent WLCEVENTD messages but I'm 100% confident this is just my old Android devices not playing nicely with newer devices on the network... dont ask me how or why as I gave up trying to figure it exactly but mixed AC and N devices (and older versions of Android) and combination of channel settings etc wreak havoc on generating those debugging messages.... maybe Ill contact ASUS and plead with them to remove them, but honestly theres so many other ways to deal with them.

After a week or so of troubleshooting 384.19 on my AC68U, the biggest issue was random reboots, I purchase a new AC68U and I'll use the old one as a node.
Installed 384.19 and ran it for a few days just with my laptop and desktop. I let the old AC86U run the rest of the household.
Went live with the new AC86U last night and notice one device in the Syslog listing the WLCEVENTD message "WLCEVENTD wlceventd_proc_event(466): eth5: Deauth_ind D8:13:99:B2:B4:6F, status: 0, reason: Class 3 frame received from nonassociated station (7)"
I see you stated you think it's a device running an older version of Android on your network. Mine is a newer smart tv (TCL)...
Now, this message never showed up on the older AC86U with .19 installed on it. FYI, the older AC86U is the same as yours, 2018 HWVer 1.5.
The new AC86U was manufactured in 2020 but I can't locate the HW ver., just the firmware version it came with.
Now, since there have been some old issues with 384.19 on the AC86U, I just wanted to let you know what I have experienced.
At the moment, I'm not running any scripts or any add-ons. Basically, I'm running the most minimal configuration as possible so as to troubleshoot each option I roll out.

 

[bbunge]

Apologies for possible noob question here.... Do we need to backup and restore JFFS on a clean install of Merlin over stock (RT-AC86U)?

No. Just make sure the JFFS is mounted. Look in Tools, Internal Storage.

 

[gattaca]

^^^ Asus appears to have stopped printing a HW Version on the AC86U sometime with the manufacturing switch from China to Vietnam in 2020. Look closely, I bet yours says "Made in Vietnam"...

 

[xdj]

^^^ Asus appears to have stopped printing a HW Version on the AC86U sometime with the manufacturing switch from China to Vietnam in 2020. Look closely, I bet yours says "Made in Vietnam"...

The new AC86U is also made in China.

 

[xdj]

Greetings All,

Due to issues I was having with my AC86U and 834.19, I purchased a new AC86U to troubleshoot the erroneous errors that seem to be popping up with various users and myself. Unfortunately, I have crawled down the rabbit’s hole to find answers...

I will post my observations to hopefully help others as well answer questions that I have on why these issues are occurring.

So, the new AC86U has been running live in my house for less than a day with minimal configuration. Basically, the only thing running is, of course, DHCP, Share is enabled in Samba for the SSD running on the USB 2 port for the traffic monitor file and to store files on my network to share. For the moment Traffic stats are disabled.

Nothing else is enabled…

The first few observation I’ve noticed between the new AC86U and the old AC86U running 384.19 is:

• The Syslog entry "WLCEVENTD wlceventd_proc_event(466): eth5: Deauth_ind D8:13:99:B2:B4:6F, status: 0, reason: Class 3 frame received from nonassociated station (7)" on one device (newer TCL smart TV) is flooding the syslog. I’ve never had this issue before
• When a device comes back online the Client name changes back to its default name. This happens mostly with iPhones. It also happened with my daughter’s TCL TV.
• Now I do manually assign IP’s around the DHCP list and I’ve noticed that sometimes when a device comes back online it’s assigned a new IP.

Just a reminder, these issues I’ve listed are new with the brand new AC86U running 384.19 compared to my old AC86U running 834.19.

 

[Maverickcdn]

Went live with the new AC86U last night and notice one device in the Syslog listing the WLCEVENTD message "WLCEVENTD wlceventd_proc_event(466): eth5: Deauth_ind D8:13:99:B2:B4:6F, status: 0, reason: Class 3 frame received from nonassociated station (7)"
I see you stated you think it's a device running an older version of Android on your network. Mine is a newer smart tv (TCL)...

Basically if you have no actual function issues of your wifi, ignore the messages. If you're having actual connection issues use them as a diagnosing tool.

These messages are seemingly generated by just about any Auth/Key exchange/dhcp/channel change etc which can by triggered by either the router or the client in some cases, use the messages to diagnose the actual problem client and then narrow down which event is occuring and go from there...I have 1 week dhcp leases and 1 day wpa key expiries and a fixed wifi channel and disabled smart connect and get very few messages from my 'good' clients

 

[learning_curve]

My previous post #878 certainly has provided some quite different views on the subject... Some almost authoritarian! Adding a little perspective, after reading, it appears that when you're using an RT-AC68U and you first switch over to using Merlin, any possible problems caused by NOT formatting the JFFS partition at the next reboot, appears to depend on... what level of customisation you've already applied prior to the switch over AND if it was already mounted AND which Asus / Merlin firmware releases were involved as part of the switch over too?

I have just a normal 2019, AC1900, RT-AC68U, which didn't have any significant specialised customisation (no scripts etc) prior to the switch over from Asus 3.0.0.4.385.20633 to Merlin 384.19, I didn't format the JFFS Partition, I haven't since, I have added some scripts now, but, to date, I still, have had no issues at all, relating to JFFS / storage on JFFS / Mounting JFFS etc.

 

[ugandy]

ax88
i had to downgrade to 384.18
2.4 wifi kept dying on 384.19
:-(

 

[New2This]

ax88
i had to downgrade to 384.18
2.4 wifi kept dying on 384.19
:-(

After how many hours or minutes are they disconnected?
Right now Ive got just over 15 hours on the 2.4ghz with the devices connected

 

[ugandy]

After how many hours or minutes are they disconnected?
Right now Ive got just over 15 hours on the 2.4ghz with the devices connected

it was a matter of couple of hours to happen.
the log shows "local deauth request" all 2.4 clients are disconnected one by one, and no one else can connect to 2.4 until a reboot happens. 5G kept chugging along fine.
since downgrading to .18 it has been OK for the last 24hrs. fingers crossed. for me, this started with 19b2 if I'm not mistaken.

 

[henry8866]

I am having some random wifi freeze issue (AC68U 384.17) and plan to upgrade to see any difference.

Looks that most of issues are for AC86U etc, I assume it is safe for AC68U?
To ensure clean install, are these the correct steps: hard reset, upgrade to 384.19 and then another hard reset?