Release Asuswrt-Merlin 384.19 is now available

[shabbs]

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...

That's what it boils down to right? Majority of issues seem to be related to those making use of scripts that get side-swiped with the JFFS re-size. I have two RT-AC86U's on my network but don't use any scripts, so was "immune" to the issue. The only Merlin feature I'm actually using is the DNSFilter. This has certainly been an eventful thread.

 

[RMerlin]

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

There was no change related to wifi between the two.

merlin@ubuntu-dev:~/amng$ git log --oneline 384.19-beta2-mainline..384.19-mainline
89f02ff997 (tag: 384.19-mainline, origin/mainline.384, mainline.384) Merge branch 'master' into mainline
b93cd5bb22 (tag: 384.19) bump revision to 384.19 final
abe3a5c617 Updated documentation
c6870dc93f webui: hide "show password" box for all models but RT-AC68U, all others now use encrypted storage
ecc9e58c9f webui: fix minor typo on Sysinfo page
b2effccca8 openvpn: remove broken (and redundant) log entry from vpnrouting's start.

 

[pr0jects]

Since the upgrade to 384.19 I found the following errors in the log files.
Are they related to the upgrade or is there something wrong with my router?
And what does it mean?

Sep 8 18:21:21 RT-AC88U-AB40 rtl_fail:
rtkswitch fail access, restart.
Sep 8 18:21:23 RT-AC88U-AB40 kernel: rtl8365mbrtl8365mb initialized(0)(retry:0)
Sep 8 18:21:23 RT-AC88U-AB40 kernel: rtk port_phyEnableAll ok
Sep 8 18:21:24 RT-AC88U-AB40 kernel: txDelay_user: 1
Sep 8 18:21:24 RT-AC88U-AB40 kernel: # txDelay - TX delay value, 1 for delay 2ns and 0 for no-delay
Sep 8 18:21:24 RT-AC88U-AB40 kernel: EXT_PORT:16 new txDelay: 1, rxDelay: 4
Sep 8 18:21:24 RT-AC88U-AB40 kernel: current EXT_PORT:16 txDelay: 1, rxDelay: 4
Sep 8 18:21:24 RT-AC88U-AB40 kernel: rxDelay_user: 4
Sep 8 18:21:24 RT-AC88U-AB40 kernel: # rxDelay - RX delay value, 0~7 for delay setupEXT_PORT:16 new txDelay: 1, rxDelay: 4
Sep 8 18:21:24 RT-AC88U-AB40 kernel: current EXT_PORT:16 txDelay: 1, rxDelay: 4

 

[Adamm]

Since the upgrade to 384.19 I found the following errors in the log files.
Are they related to the upgrade or is there something wrong with my router?
And what does it mean?

First result when using the search feature;

RT-AC88U: RTK Switch initialization fails

Hi guys, I don't know what this is, but it started suddenly with one of the betas in the past.. It doesn't appear directly after a reboot or a flash, but at different times after running the router for some days.. Its flooding the logs with that message and only a reboot fixes it I have the...

www.snbforums.com

 

[Paxsat]

nella schermata Amministrazione - Sistema non è possibile cambiare nulla (o devi cambiare anche nome di accesso)

on the Administration - System , nothing can be changed

rt-ac5300

 

[DHLarson]

At the risk of provoking folks on this thread that are tired of JFFS issues being discussed, please feel free to pass over this post.

After upgrading from .17 to .19 on my AC86U, I had immediate issues with JFFS partition being full and associated weirdness. After deleting traffic analyzer database that had grown beyond all bounds and reformatting the partition, trying various combinations of restoring JFFS backups, etc. I continued to have issues with JFFS garbage collection and CRC errors. I finally gave up and reverted to 384.17. As expected, had to factory reset to deal with the password encryption change then formatted the USB drive and reinstalled Skynet and VPNMGR, as well as SCmerlin and Entware. Consequently, system is again running smooth as silk for 48 hours. No errors.

My thoughts are that there is indeed an issue in some part of the JFFS code that is transient or depends on some odd combinations of packages, etc. I may stay here until 386.x is stable before I make the leap again.

Thanks to all who shared their experiences and attempts to resolve. The amount of lost time and impact on network dependent COVID-19 household makes surrender the valiant solution for me. For a while, I worried that the CRC errors and GC issues were indicator of pending hardware failure - not so convinced now. We shall see...

 

[bluepoint]

At the risk of provoking folks on this thread that are tired of JFFS issues being discussed, please feel free to pass over this post.

After upgrading from .17 to .19 on my AC86U, I had immediate issues with JFFS partition being full and associated weirdness. After deleting traffic analyzer database that had grown beyond all bounds and reformatting the partition, trying various combinations of restoring JFFS backups, etc. I continued to have issues with JFFS garbage collection and CRC errors. I finally gave up and reverted to 384.17. As expected, had to factory reset to deal with the password encryption change then formatted the USB drive and reinstalled Skynet and VPNMGR, as well as SCmerlin and Entware. Consequently, system is again running smooth as silk for 48 hours. No errors.

My thoughts are that there is indeed an issue in some part of the JFFS code that is transient or depends on some odd combinations of packages, etc. I may stay here until 386.x is stable before I make the leap again.

Thanks to all who shared their experiences and attempts to resolve. The amount of lost time and impact on network dependent COVID-19 household makes surrender the valiant solution for me. For a while, I worried that the CRC errors and GC issues were indicator of pending hardware failure - not so convinced now. We shall see...

Amongst all of you having problem with jffs in 86U, have you tried setting the router from scratch with no jffs restore from backup? It seems the partitioning and restoration of jffs is problematic.
a. Install 384.19
b. reset to factory default
c. format jffs partition at next boot(admin/system) reboot
d. set all settings manually(do not restore jffs from backup)

Note this actions will erase all your certificates(openvpn/pixelserv/https) so be ready to re-create new ones. If you run scripts you will need to start from scratch too starting from formatting the USB drive but it isn't hard if you use "amtm" which is builtin to the firmware,

 

[jsbeddow]

Amongst all of you having problem with jffs in 86U, have you tried setting the router from scratch with no jffs restore from backup? It seems the partitioning and restoration of jffs is problematic.
a. Install 384.19
b. reset to factory default
c. format jffs partition at next boot(admin/system) reboot
d. set all settings manually(do not restore jffs from backup)

Note this actions will erase all your certificates(openvpn/pixelserv/https) so be ready to re-create new ones. If you run scripts you will need to start from scratch too starting from formatting the USB drive but it isn't hard if you use "amtm" which is builtin to the firmware,

Yes, I have gone through the full reset and manual setup exactly as described above: I don't specifically have jffs issues, however I do still suffer from this firmware version dropping wireless clients (the router is still supposedly broadcasting on the 5Ghz band, but some clients will no longer connect without a reboot of the router). This occurs consistently after about every 5-6 days. Can't wait to see some officially (Merlin) released alphas and betas of 386.x...

 

[bluepoint]

Yes, I have gone through the full reset and manual setup exactly as described above: I don't specifically have jffs issues, however I do still suffer from this firmware version dropping wireless clients (the router is still supposedly broadcasting on the 5Ghz band, but some clients will no longer connect without a reboot of the router). This occurs consistently after about every 5-6 days. Can't wait to see some officially (Merlin) released alphas and betas of 386.x...

I don't think this is related to partitioning/restoring jffs problem. If you're not getting crc errors using the procedures then this solves the jffs bug. The wireless dropping is another story.

 

[XIII]

The wireless dropping is another story.

But one that several AC86u users experience.

(like me and I did not have any JFFS issues)

Not sure whether that is worth keeping the topic open for though, as it might be in a closed source driver, so Merlin can’t do anything about it?

(sucks that this happen in the “last” release until 386 is out)

 

[Vimes]

Yes, I have gone through the full reset and manual setup exactly as described above: I don't specifically have jffs issues, however I do still suffer from this firmware version dropping wireless clients (the router is still supposedly broadcasting on the 5Ghz band, but some clients will no longer connect without a reboot of the router). This occurs consistently after about every 5-6 days. Can't wait to see some officially (Merlin) released alphas and betas of 386.x...

I did similar to you, with a full format of the JFFS partition and then a full reset. Manually entering my details was simple, I merely use a VPN client. However wireless client dropouts happened enough for me to be concerned, on devices that had previously been very stable. Nothing was showing to be an issue in the logs, well nothing that I could recognise. Either a reset of the router or making changes to the affected radio did resolve those., temporarily.
Some of those wireless issues were noted on the 2.4Ghz radio and not just on the 5Ghz. I didn't always need to reset the router to resolve the drop and failure to connect, for some devices, just changing the channel could have the same effect for them to be able to connect again. I suppose that is similar to a reset, in terms of the wireless connection.
Going back to 384.18 and all has remained well, showing around 40 clients or so connected, half by wireless, and, as yet, no unusual behaviour.
I have had this 86U router for almost three years and this is the first time that I had needed to "downgrade" a Merlin release in all of that time, used these firmwares since bought.
Lazy maybe but it was also the first time that I had factory reset and "cleansed" the router..!

I might be tempted to try again.

 

[unsynaps]

I did similar to you, with a full format of the JFFS partition and then a full reset. Manually entering my details was simple, I merely use a VPN client. However wireless client dropouts happened enough for me to be concerned, on devices that had previously been very stable. Nothing was showing to be an issue in the logs, well nothing that I could recognise. Either a reset of the router or making changes to the affected radio did resolve those., temporarily.
Some of those wireless issues were noted on the 2.4Ghz radio and not just on the 5Ghz. I didn't always need to reset the router to resolve the drop and failure to connect, for some devices, just changing the channel could have the same effect for them to be able to connect again. I suppose that is similar to a reset, in terms of the wireless connection.
Going back to 384.18 and all has remained well, showing around 40 clients or so connected and, as yet, no unusual behaviour.
I have had this 86U router for almost three years and this is the first time that I had needed to "downgrade" a Merlin release in all of that time, used these firmwares since bought.
Lazy maybe but it was also the first time that I had factory reset and "cleansed" the router..!

Sounds like hardware issues to me.

Considering tons of people are using the same model with the same firmware and not having any issues you being singled out can only mean this.

 

[Vimes]

Sounds like hardware issues to me.

Considering tons of people are using the same model with the same firmware and not having any issues you being singled out can only mean this.

Not sure, but could be possible of course. I am tempted to try again as all has seemed well for some time now with 384.18. If it was hardware I would expect similar issues regardless of firmware revision.
But if I do change to 384.19 I'll do as I did previously with a format, reset and manually entering in my details, and this time work with the issues for longer. Perhaps the previous install was flawed in some way, in other words errors created by myself rather than that of the firmware per se. I'll see later.

 

[Catalinus]

I also tried 384.19 on my RT-AX58U. Everything is fine for a few days. After a couple of days, my 5Ghz devices lose connection. On these devices, my 5Ghz SSID is visible but the devices cannot obtain an IP address. Nothing really strange in the log files / dmesg. Going back to 384.16 or 384.17 fixes it. I tried playing around with using WPA2 personal only instead of WPA2/WPA3 personal but that does not fix it. I know @RMerlin also has an RT-AX58U and wondering if he has seen anything like this or not. Also noticed the GIT activity around the new 386 codebase and that is itself pretty exciting for us router nerds. BTW, I have done clean installs not dirty flashes. There is something going on, maybe with the dnsmasq changes in 384.19 to 2.82-openssl not sure.

On AX88U I have seen very similar issues in the past (and it was most obvious on iOS devices) - but mine seemed to go away using 384.18 by returning from WPA3 back to just WPA2. on 384.19 I have on the AX88U an issue where OpenVPN only works for one client at a time, so I went back to 384.18 for the moment

 

[GHammer]

Was the WiFi driver changed in this build for your device?
If not, pretty hard for other things to affect the radio.
It's my (likely incorrect) understanding that everything to do with the radios is encrypted, not changeable, and provided by the manufacturer of the chipset.
Try changing the regulatory country/region for instance.

 

[Trent Hubbert]

Sounds like hardware issues to me.

Considering tons of people are using the same model with the same firmware and not having any issues you being singled out can only mean this.

Definitely not hardware. Others are experiencing this as well. I see the same behavior on AX58 router.

 

[Sicario]

Yes, I have gone through the full reset and manual setup exactly as described above: I don't specifically have jffs issues, however I do still suffer from this firmware version dropping wireless clients (the router is still supposedly broadcasting on the 5Ghz band, but some clients will no longer connect without a reboot of the router). This occurs consistently after about every 5-6 days. Can't wait to see some officially (Merlin) released alphas and betas of 386.x...

I think I had the same problem with my AC86U. Just bought AC86U and using it for exactly a week using 384.19, it works great. But after that, it lost 5GHz band out of sudden. Rebooting doesn't help, factory reset only helps for a few minutes. Tried the latest official firmware, the problem still persist. Even the latest 386RC didn't fix that problem.

 

[ceez24]

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).

 

[jsbeddow]

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).

It is highly unlikely that you will be impacted by any issues in the use case that you have, where your 86U units are simply fully factory reset nodes (we assume you mean they are in AiMesh "node" mode). Worst case scenario, you have to roll back to your previous firmware and hard reset again, but then that should be very easy to add them back to your mesh setup.

 

[Meeshaw]

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.