Release Asuswrt-Merlin 384.19 is now available

[truglodite]

IDK, my Sunday has turned in to a complete mess thanks to this failed upgrade. I still can't get skynet working it keeps saying usb not available everytime I access from AMTM. Wish I could uninstall it all and start from scratch at this point, but I seem to fail at doing that as well. I really don't want to have to redo all my router settings, and I'm just about ready to throw in the towel on getting skynet working. I think there's even more than just skynet not working... uiscribe doesn't seem to work either as the logs aren't getting split out.

Very frustrating sunday... wish I didn't upgrade to .19.

 

[tommyv2]

You can try:

nvram set jffs2_format=1
nvram commit
service reboot

No guarantees.

Sweet! I'm gonna try this. Thank you!

Update: It worked! My JFFS is back in action. Thanks SO MUCH

 

[AntonK]

One lesson we can learn from this thread is all you AC86U folks have to swap your routers out for AC88Us

 

[L&LD]

Did you perform any firmware updates remotely for the AC86U or go on site for those models?

Most were done via the owner activating an OpenVPN server and me doing it remotely. About 15 were done in person.

 

[ExtremeFiretop]

Hi, i did a dirty upgrade from 348.18 to 348.19 on ax88u and now it restart randomly. Some times one cpu is 100% and in top show this:

  PID  PPID USER     STAT   VSZ %VSZ CPU %CPU COMMAND
   35     2 user   SW       0  0.0   0 24.9 [skb_free_task]

This statement is not correct. Have tested a little more, and
v. 19 on RT-AX88U is the culprit, where I cannot access the
Internet.
Right now.... back on v. 18 on both routers :-(

I no

I am having the same issue, along with the red light being on the RT-AX88U. I had to do factor reset and ran into many issues attempting to re-establish my mesh to my RT-AX58U (Wired). When you are applying the patch on the AX88U should you format the JFFS during the reboot ? I have not tried this because happy wife happy life rule applied, went back to 384.18 no issues.

I am a long time watcher, first time poster.

I am happy to see I am not the only one with issues with this update to 384.19 on my AX88U. I was about to submit a warranty repair for the router until I saw many people with issues as well.
I should mention, I've been flashing the Merlin builds on my AX88U since the beta versions of 384.15 without issues... I've been happily alpha and beta testing Merlin builds, sometimes with small bugs (to be expected) nothing this serious though.

This version has been a complete s**t-show (pardon my language) for me since the Alphas of 384.19!!!

For whatever reason, once I get any version of 384.19 (Alpha, beta or release) on my AX88U, it randomly reboots anywhere from every 3 minutes to every 12 minutes without any action on my part. I'm just watching the lights on the router, not even logged into the webUI.
I tried to reformat JFFS multiple times without luck, did multiple factory resets (using both the reset button on the webUI and the WPS method) and reconfiguring from scratch without luck, and also tried to use the Asus firmware restoration utility and rescue mode to re-flash the firmware down and back up again still with issues....
(Every time reconfiguring from scratch on any big firmware jump, i.e 384.18 to 384.19) and still having the random reboot issues - It's still very unstable and restarting every 3 minutes after reconfiguring from scratch.

I am configuring the device to use with WAN Aggregation and Static IP without PPPOE... (No UPNP Enabled, No NAT Enabled, No Firewalls, No AI Protection, No QoS, No IPV6..)
It's a very simplistic configuration as it's behind my own custom built Pfsense router doing most of the actual work, this is mostly acting as a simple AP, but it's in router mode for WAN aggregation so I can get the full 1.5Gbit/s over WiFi 6).

What's interesting is downgrading back to 384.18 is flawless and is the latest merlin firmware I can use this far. and upgrading to the ASUS official build of: Version 3.0.0.4.384.9566 also works flawlessly. (After reconfiguring from scratch)

Also noticed that every time the router reboots after being reconfigured on 384.19, that logs mention kernel errors on May 5th, and then continues to update the logs with the accurate date of August 16th...
After the 3 minutes pass, it will reboot again, and all the logs are once again flooded with kernel errors from "May 5th."

I would of grabbed some more details, but I only had 2 hours to play around with this last night as I live in a house with 5 people and 42 connected devices and I only get a few hours window to do these upgrades while people sleep or they get angry lol. @RMerlin let me know if you need more details for replicating the problem.
I am wondering if there could be some kind of unforeseen bug with the code in relation to the maintenance done on the nt_center database on first boot of the newer AX88U code...?

I want to say none of this is an attack against @RMerlin or ASUS, as I've been forever grateful of all the work done! I am just looking to provide feedback and assist wherever possible. This is the first time a bug/issue has made it to the final release for me that still wasn't reported or identified before in the alpha's/beta's, so I figured i'd chime in.

 

[RMerlin]

My RT-AX88U currently has an uptime of over 7 days.

 

[Fox23]

Equipment: AC86U with AIMesh Node AC88U

Read the warnings and backed up settings and jffs prior to upgrade. Did a dirty upgrade and at first all seemed fine, went into amtm to update scripts and that did not go well, dnscrypt and skynet both blew chunks when trying to open their respective menus. Errors indicated invalid memory locations (which made complete sense given the warnings about the AC86U). My setup for the scripts is pretty "out of the box" so I just did a factory reset and reconfigured from scratch rather than restore from my backup. I use diversion, skynet, scribe, and dnscrypt. All installed from amtm as expected and have been running fine the rest of the day without issue. Sorry to hear it has been so rough for some, just wanted to share that a factory reset and re-configure worked without issue.

 

[RMerlin]

This is how all over the place the current firmware + GPL release situation is, as of tonight:

https://docs.google.com/spreadsheet...Xq4I0i6lQo-RN48SGFSkKNKq8/edit#gid=2007755387

I can't deal anymore with the complete mess that 384 releases have become on Asus's end, with some GPLs being 4+ months outdated, only two models out of 10 sharing the same release, two models not even having recent enough GPLs to be compatible with every other models, etc...

I'm done with firmware releases until Asus re-unifies everything and starts issuing more regular GPL releases, which most likely won't be happening until everything is moved to the 386 code base. So, next release might be 3 months from now, 6 months from now, a year from now? I don't know, but it will take whatever time it takes. I'm tired of trying to mix and match all of these separate releases, and dealing with the aftermath.

So until then, run whatever works for you, be it 384.19, 384.18 or Asus's stock. It's out of my control, and I simply give up trying to keep it all together in the current situation.

 

[penguin22]

Just wanted to give some input into my upgrade experience with an AC-86U. I was hesitant to upgrade through the beta due to not having a good time for the downtime possibility, which was prudent on my part.

Post upgrade, it didn't take the first time, which I've seen before; second time reflected .19 and jffs was indeed not healthy. Having rtfm, I had my backup of jffs, but couldn't get it to format for some reason; turns out that it was requiring me to put a unique and new name for the router login (not sure if this is because I use something other than admin). After changing the login name, jffs formats and no longer said unmounted in tools. I followed the two reboot suggestion, restored, and jffs installed things worked fine.

Next hurdle, OpenVPN client was not happy; certs were still there following the restore and config looked in place. First issue that I found was that I had the -1 for "Connection Retry attempts (0 for infinite)" and had to change it to 0. This was easy to find, but the second issue drove me nuts. I kept getting Authentication Failed, however verified that the username and password were correct and the same as before. I confirmed login with this from my Android phone (using the PIA App) and through logging into the webpage, so figured it must be some other kink in the gears. I reset to the bare minimum, but the old adage of try the simplest thing first rang true. I reset my password from one 64-characters to 32-characters with all other settings the same and it worked! This was after doing a search and having an issue with an even longer password before, so I'm not sure if in the re-write the max password length might have changed and wanted to throw it out there to see.

Anyway, <tldr>

• Back up jffs per the instructions and you will be good
• If jffs isn't formatting, see if it is saying to change the login name (you can always change it back)
• Make sure your VPN client has "Connection Retry attempts (0 for infinite)" set to something other than -1
• If you get an authentication error, try using a password 32-characters if you were using something much longer

 

[Vexira]

Updated from 384.18 to 384.19 without any issues as usual. This is rather off-topic, but do anyone know what the required settings in order to get VoWiFi to work? Voice over WiFi has never worked for me when using my Asus RT-AX88U and Merlin firmware but when I was over at my parents house the past three days I noticed that their Google WiFi system gave me VoWiFi instantaneously and it was working all the time.

It's no biggie for me, I don't have that much use for VoWiFi. I'm just curious about whats lacking on my RT-AX88U for this to not work. We have the same ISP and I know for a fact that there is no limiting factor from the ISP itself and I have no firewall functionality on my AX88U that should be affecting this.

I can't seem to really locate any meaningful information on what kind of router requirements VoWiFi have? Some people claim that it won't work when you have hardware acceleration running in asus-wrt firmware aka flow cache but I have a hard time understanding why that might be a issue?

Who is your carrier?

 

[penguin22]

This is how all over the place the current firmware + GPL release situation is, as of tonight:

https://docs.google.com/spreadsheet...Xq4I0i6lQo-RN48SGFSkKNKq8/edit#gid=2007755387

I can't deal anymore with the complete mess that 384 releases have become on Asus's end, with some GPLs being 4+ months outdated, only two models out of 10 sharing the same release, two models not even having recent enough GPLs to be compatible with every other models, etc...

I'm done with firmware releases until Asus re-unifies everything and starts issuing more regular GPL releases, which most likely won't be happening until everything is moved to the 386 code base. So, next release might be 3 months from now, 6 months from now, a year from now? I don't know, but it will take whatever time it takes. I'm tired of trying to mix and match all of these separate releases, and dealing with the aftermath.

So until then, run whatever works for you, be it 384.19, 384.18 or Asus's stock. It's out of my control, and I simply give up trying to keep it all together in the current situation.

I don't blame you one bit; what you have to deal with is completely nuts. I would have stuck with .18 happily, but you went and outdid yourself with .19, so I took the plunge and hope to have the same success. I was running over a month solid with .18 on my AC-86U and AC-68P (AIMesh Node), with AC-3200 (Krack Free) all because of your efforts.

You do this of your own skill and generosity and have to deal with way more burden than makes sense. Thank you again for all your efforts and I hope that ASUS can get their act together for your sanity. I can firmly say that the community here extremely appreciate everything you have been doing for what I think is well over a decade, but most likely far longer than that.

 

[AntonK]

This is how all over the place the current firmware + GPL release situation is, as of tonight:

https://docs.google.com/spreadsheet...Xq4I0i6lQo-RN48SGFSkKNKq8/edit#gid=2007755387

I can't deal anymore with the complete mess that 384 releases have become on Asus's end, with some GPLs being 4+ months outdated, only two models out of 10 sharing the same release, two models not even having recent enough GPLs to be compatible with every other models, etc...

I'm done with firmware releases until Asus re-unifies everything and starts issuing more regular GPL releases, which most likely won't be happening until everything is moved to the 386 code base. So, next release might be 3 months from now, 6 months from now, a year from now? I don't know, but it will take whatever time it takes. I'm tired of trying to mix and match all of these separate releases, and dealing with the aftermath.

So until then, run whatever works for you, be it 384.19, 384.18 or Asus's stock. It's out of my control, and I simply give up trying to keep it all together in the current situation.

I hear you, and understand completely. Putting the project on hold until a baseline is met sounds eminently reasonable.

Anton

 

[Vexira]

I hear you, and understand completely. Putting the project on hold until a baseline is met sounds eminently reasonable.

Anton

Press f5 or shift f5

 

[Treadler]

This is how all over the place the current firmware + GPL release situation is, as of tonight:

https://docs.google.com/spreadsheet...Xq4I0i6lQo-RN48SGFSkKNKq8/edit#gid=2007755387

I can't deal anymore with the complete mess that 384 releases have become on Asus's end, with some GPLs being 4+ months outdated, only two models out of 10 sharing the same release, two models not even having recent enough GPLs to be compatible with every other models, etc...

I'm done with firmware releases until Asus re-unifies everything and starts issuing more regular GPL releases, which most likely won't be happening until everything is moved to the 386 code base. So, next release might be 3 months from now, 6 months from now, a year from now? I don't know, but it will take whatever time it takes. I'm tired of trying to mix and match all of these separate releases, and dealing with the aftermath.

So until then, run whatever works for you, be it 384.19, 384.18 or Asus's stock. It's out of my control, and I simply give up trying to keep it all together in the current situation.

What a nightmare!
FWIW my 384.19 is behaving very well, uptime of many days, nothing to report except happy days!

 

[AntonK]

Press f5 or shift f5

What?

 

[AxelBigDog]

Happy days here too...Note the AP mode though. Not using as a router or AIMesh.

Using an AX58U for the router, traffic cop, plus wifi, running same Alpha and apparently it DOES like to crash. Just checked it, been up for only 17 hours =(. Luckily I didn't notice the reboot.

 

[appleseed]

What?

F in the chat


j/k

 

[ExtremeFiretop]

This is how all over the place the current firmware + GPL release situation is, as of tonight:

https://docs.google.com/spreadsheet...Xq4I0i6lQo-RN48SGFSkKNKq8/edit#gid=2007755387

I can't deal anymore with the complete mess that 384 releases have become on Asus's end, with some GPLs being 4+ months outdated, only two models out of 10 sharing the same release, two models not even having recent enough GPLs to be compatible with every other models, etc...

I'm done with firmware releases until Asus re-unifies everything and starts issuing more regular GPL releases, which most likely won't be happening until everything is moved to the 386 code base. So, next release might be 3 months from now, 6 months from now, a year from now? I don't know, but it will take whatever time it takes. I'm tired of trying to mix and match all of these separate releases, and dealing with the aftermath.

So until then, run whatever works for you, be it 384.19, 384.18 or Asus's stock. It's out of my control, and I simply give up trying to keep it all together in the current situation.

I hope my comment didn't ruin your motivation on the project... I can for sure see why that could be cause for frustration though trying to deal with all those.

Just know I've been a long time supporter of you specifically, and even one of my friends have purchased an ASUS router specifically due to your implementation of the firmware.

Whatever you need to do to help send the message to ASUS that this takes the fun out of the project for you. Even if that means putting a hold and waiting until they unify everything again in 386 (hopefully).

Just know that I'm still very happy with the project and with 384.18, and I only wanted to give my feedback on the experience with my AX88U and 384.19, and ask if there was any specific setting/log, or procedure I could try or maybe missed, anything I could provide to assist further troubleshooting.

Understanding that this may be put on hold for some time. Will that mean that 384.18 will continue to get updated script support for amtm, etc? Or will it fall behind to 384.19?

Thanks again @RMerlin for all the support and work throughout the years. You clearly are an asset to ASUS, and they hopefully will get their stuff in line so you can return feeling the joy you deserve.

Thanks again.

 

[XIII]

This is a sad day.

Thank you for all your effort @RMerlin!

 

[K-2SO]

I have purchased 6 Asus routers for my personal use just because of Merlin support.
1 x RT-N66U, 1 x RT-AC66U, 2 x RT-AC1900P, 2 x RT-AC86U
Are you listening Asus?