What's new

Release Asuswrt-Merlin 384.19 is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
Hi,
a clarification, is it enough to save a backup file of your JFFS without resorting to Install NVRAM Save / Restore Utility?
thank you
The AC68U should upgrade fine without affecting JFFS. Only AC86U users are reporting issues.
 
Last edited:
The AC68U should upgrade fine without affecting JFFS. Only AC86U users are reporting issues.

Not true. When i flashed my AX58U the JFFS showed as unmounted had to format to get it back.
 
@RMerlin, thank you for 384.19_0 release final. Great upgrade as usual.

@CaptnDanLKW, @Jack Yaz, and others, after upgrading every single RT-AC86U from 384.18 to 384.19_0 release final (almost 50 so far), the JFFS partition truncated to 47MB from 48MB caused issues either immediately or after a few minutes in the amtm scripts (showing minimal updates available when they're not, etc.), or, in the OpenVPN Servers and/or Clients. Waiting, rebooting, or full power off for a minute or two didn't solve these issues.

Upgrading from 384.18_0 or earlier and flashing 384.19_0 or later requires the steps outlined in the link below for stable operation.

I have no doubt that there will be some combination of options/features and scripts that don't seem to need the suggested steps below, but for 100% peace of mind, the minimal commitment to save the JFFS and then restore it after flashing 384.19_0 or later is worth it.


Note that I cannot edit the original post stating "... restore the JFFS partition 'if necessary' with 'required'..."

Restore the JFFS you saved after flashing to 384.19_0 to prevent unneeded wild goose chases on ghost issues that don't really exist. :)

Hi,

Updated my Ax88U to .19, and got the unresponsive UI bug so i decided to reset. Had backed up settings and JFFS partition prior to format. Also ran the NVRAM backup utility from AMTM. Am I supposed to restore the JFFS or NVRAM settings first? or just one of those? Not sure what the overlap is in what's saved/restored (if any). Thanks!
 
Restore NVRAM settings either from the saved backup config file or from the NSRU utility (make sure you know what options you're using and why with the utility).

Then, restore the JFFS partition.

Do all this without anything plugged into the router except for the Ethernet WAN and a single LAN port (if not using WiFi).

HTH.
 
Restore NVRAM settings either from the saved backup config file or from the NSRU utility (make sure you know what options you're using and why with the utility).

Then, restore the JFFS partition.

Do all this without anything plugged into the router except for the Ethernet WAN and a single LAN port (if not using WiFi).

HTH.
With the utility I just followed the guide to do a basic backup before the wipe, and then that's what I restored.
seemed to work re-setting all my settings (WiFi, DHCP, etc), but scripts were showing up as not installed.
Restored JFFS, and now getting the GUI-not-loading issue again.

May have to re-wipe, restore NVRAM again, and then reconfigure scripts i guess.
 
After a dirty or clean upgrade there's an issue: Internet over Static IP can't auto restart when router reboot. Only manual off-on works well. 384.18 doesn't have this issue.

This is an asus bug, that they claimed to have fixed in the latest RT-AC86U stock firmware. I have the possibility to change it to automatic and then everything is stable aside of a weird lease time. If you can, change it to automatic instead of static else 384.18 is probably the better option.
 
@jrmtz85, you may have a more stable and permanent fix if you don't restore anything either. Make a clean start if you have the small (extra) amount of time needed to do so, you won't regret it.
 
Maybe don't restore the jffs partition from backup? After creating jffs, manually reinstall scripts using amtm. Any scripts can be manually restored by selectively restoring files from the backup to jffs using SSH client.
That is what I was thinking. I just read through some recent posts on this thread regarding nvram backup and restore. Unfortunately I didn't see that info before I started upgrading to .19, so I don't have a clean backup of nvram from when things were working on .18. I can only take an nvram snapshot in it's current state, but that sounds like a failed idea with the errors happening. I wonder if that is why I'm having issues.

So my plan of attack this weekend is to disable scripts, backup settings using the webui, factory reset, restore settings, format jffs/apply/reboot/wait/reboot, enable scripts, reinstall amtm stuff from scratch, then ssh in to add my custom scripts, certs, etc. If that doesn't work, I'm not sure what will. I'll report back if it fails.

Revised after further reading... sounds like restoring jffs may work if I actually restore a backup that is taken after upgrading to .19? The size of the jffs backup is much smaller with .19 (~25mb) vs .18 (~52mb). Couldn't hurt to try that first I guess. If that fails, then I'll try my striked out plan B above (the 'nuclear option').

Kevin
 
Last edited:
So my plan of attack this weekend is to disable scripts, backup settings using the webui, factory reset, restore settings, format jffs/apply/reboot/wait/reboot, enable scripts, reinstall amtm stuff from scratch, then ssh in to add my custom scripts, certs, etc. If that doesn't work, I'm not sure what will. I'll report back if it fails.
Don't restore the settings from the file you used to back them up. Restore them by manually entering them. If your issues are caused by some weird settings issue you will just be restoring your issues. Keep the saved config just in case the factory reset doesn't help for easy restore.
 
@truglodite, if that doesn't work, you need to do a full reset to factory defaults, including formatting the JFFS partition and the USB drive used for amtm, scripts, Entware, and the swap file.

Then, do a minimal and manual configuration of the router without using any backup config file(s). And also without 'blindly' putting in old settings/options that may have worked before.

The two guides in the last two paragraphs in the link below may help get your router/network back to a good/known state, if, what you outlined, doesn't.

 
@jrmtz85, you may have a more stable and permanent fix if you don't restore anything either. Make a clean start if you have the small (extra) amount of time needed to do so, you won't regret it.

Naw, too annoying to re-setup everything. Started to encounter a weird error where it said I didn't have write access to JFFS when trying to access AMTM. It even completely locked down and reset button wasn't working. Had to WPS button reset. After than, figured something got corrupted in the FW, so just reinstalled, got into AMTM to base-sintall my scripts, and then the NVRAM restore seems to have finished configuring everyhting properly now. Been stable now for about 2 hours. And Wi-Fi clients have already migrated from barely reaching the router, back to their nearby nodes, so looks like all is well.
 
@jrmtz85, that's great! Hope it stays stable for you.
 
what is this then ?

maybe this is something different altogether .... but thats why i thought it was updated

OpenVPN Access Server is their commercial product, it's not the open source OpenVPN that we all use. The version strings don't match, that 2.5.2 is actually very old, the latest OpenVPN Access Server is 2.8.6, which has the OpenVPN 2.4.9 core code in it.
 
Don't restore the settings from the file you used to back them up. Restore them by manually entering them. If your issues are caused by some weird settings issue you will just be restoring your issues. Keep the saved config just in case the factory reset doesn't help for easy restore.
Well my situation appears to be about as dire as it gets. After a few tries the router is up and running using a backup from a .19 jffs. All looks to be working fine, but now, no matter what I do, my vpn server won't allow any clients to connect. I went through and made sure the certs were all correct (no \r eol's, etc), but my client keeps showing weird logs like 'bf-cbc' being used (despite only 256gcm allowed), and it always ends with an "AUTH_FAILED". I'm guessing this has to do with something still not being right in my jffs partition. I may have to take a big chunk of my sunday manually redoing everything from scratch. At least I have a jffs backup to refer to... but so many stinking settings to transcribe, from dhcp static ip's, to various dnsfilters for different clients, and I don't even want to mention the idea of redoing my ovpn pki.

Speaking of, I know this is OT, but the last time I created self signed certs for my ovpn server was years ago (rsa-256). What are folks using these days, cha-cha?
 
After initial teething issues, 384.19 is running smoothly and appears very stable, so quite happy with the upgrade.
Thanks @RMerlin et al. Getting nice ax speeds of 1.9-2.1 Mbps. Now just waitinig Full Fibre 900 from BT!
 
Temp about 80dgr is normal.
Have you read changelog?

I installed the new 384.19 beta 2 firmware from version 384.17 and everything went smoothly with no problems.
The only note is that I now get the warning "A new firmware is available for your router. We recommend that you install it now to increase the stability of your system, get new and better features, and avoid possible security problems."
What should I do to dwn to 384.19?

I thank
 

Attachments

  • 2.png
    2.png
    385.9 KB · Views: 117
Last edited:
Status
Not open for further replies.

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top