What's new

Release Asuswrt-Merlin 386.1 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.
Flashed my AC88U from b5 to final uneventfully. No problems on my end, thanks for all your hard work!
 
So will I have to reset after updating from 384.19? I have an ac-68u. Or is that just to fall back after reverting? Thanks in advance @RMerlin !

Edit: I guess it seems like I get to roll the dice on this one according to your release notes. I have a backup just in case.

Update: dirty update from 384.19 sucessfully, and all seems well so far. I Let the router settle overnight, then rebooted this morning. Re-enabled dns validation, and all seems to be working fine so far!! Thank you @RMerlin !!
 
Last edited:
Zippitydoodah! Dirty flash (AC86 - 384.19) just now: it went faster than I expected, and everything seems to be fine and dandy...heck, the LEDs even shut off as they're supposed to at the time I programmed.
I believe it has been well worth the wait (and tolerating all of the AC86 temperature reports).
Thanks and kudos to the lead devs!

UPDATE - went to ssh in and check on cake-qos and I have to remember what I have to do to not get blocked out with a key warning...that can wait til after coffee in the morning. I'm spent for today. g'nite all

FURTHER UPDATE - fixed ssh, easy peasy (good "morning"). everything has survived, and in some cases, thrived: the "green" switch I use to connect my raspi HTPC is now connecting at 1Gbps (it used to be 100Mbps). 78C CPU in a ~20C room, maybe 6C higher...not an issue to me (and it's due for a vacuuming anyway... so that may help or not, depending)
 
Last edited:
I remember a while ago having issues with time scheduling and I remember going into Administration/System and changing the DST time to something, but I can't remember which one to change.
I believe is based on your Time Zone. Once I changed it, scheduling started working again.

Maybe someone here can tell you which one to change and to what.
System time is correct. No problem with system time
 
I will stick with 386.1 on AC86U.

The temp seems ok:
386.1 b2: 72-74°C
386.1 b3: 84°C
386.1 b5: 76-77°C
386.1 final: 76-77°C
But what were they like on 384.19?
 
Thanks Merlin!

386 turned out to be one hell of a marathon eh? Thanks for your perseverance.

HB
 
Asuswrt-Merlin 386.1 is now available for all supported models (and a few new ones). This marks the switch to the new 386 code base from Asus, which introduces a few changes of its own:

- AiMesh 2.0 (better node management, shared Guest Networks, topology optimizer and more)
- Both AC and AX models are once again based on the same code base
- Speedtest powered by Ookla (note: can be limited by your router's CPU speed)
- Switch to OpenSSL 1.1.1 (so we can now fully move everything to 1.1.1 on our end)
- IPSEC IKEv2 support
- Instant Guard (new simple-to-configure mobile VPN client based on IPSEC)

And numerous changes under the hood, such as enhanced Guest Network handling (the first Guest Network can now be shared with AiMesh nodes).

On Asuswrt-Merlin's own end of things, this release mark the addition of two new models:

- RT-AX86U
- GT-AC2900 (done in collaboration with Asus)

The latter comes with a few caveats:
- The non-ROG webui is used (meaning some ROG-exclusive features are currently NOT supported)
- VPNFusion is not supported (as it's tied to Asus's own closed source OpenVPN implementation)

The non-ROG UI has been implemented by Asus, they also took care of adding GeForceNow QoS support to our code base. This will serve as an experiment to see if other GT models could be added in the future with their collaboration.


Upgrade notes:
- I strongly recommend making a backup of both your settings and your JFFS content before upgrading to 386.1, in case you need to revert back to 384.19.
- If coming from stock Asus firmware, a factory default reset is recommended, but not mandatory.
- If going back to stock Asus firmware, a factory default reset is STRONGLY recommended.
- If updating your GT-AC2900 from an older 384_xxxx firmware, reformatting your JFFS partition is STRONGLY recommended.
- Direct upgrade from 384.18 or 384.19 should be fine, but be prepared to do a factory default reset if something does not work as expected.
- Asus' 386_41535 as well as 386.1 beta 4 are known to be broken on the RT-AX88U, and require the use of Asus' Firmware Recovery Tool to upgrade
- If using third party addons, make sure you update these to the latest versions. Also check with their authors to ensure compatibility with 386.1.
- Due to encryption getting enabled for password storage on the RT-AC68U, downgrading that model to 384.xx will require a factory default reset.

Here are the highlights of changes since 384.19:
  • Merged with GPL 386_41700. Note that logging verbosity for wireless events is higher than usual on some models. This is normal, and does not indicate an issue.
  • Added support for the RT-AX86U and the GT-AC2900
  • Updated components: dnsmasq (2.84, fixing multiple recent security issues), OpenVPN (2.5.0), OpenSSL (1.1.1i), nano (5.2), curl (7.72.0), zlib (1.2.11), lz4 (1.9.2), e2fsprogs (1.45.6), dropbear (2020.81), miniuppnpd (2.2.0-20201129 snapshot), ipset userspace (7.6, which is compatible with the kernel's v6 protocol).
  • Various changes to OpenVPN to support 2.5.0, remove deprecated features (like the old ciphers setting), tweak the webui, and fix a few issues. Please review the detailed list of changes in the Changelog.
  • Added an option to run the new Speedtest through a specific OpenVPN client (the webui will automatically detect which client is currently running and add it to the list of available interfaces)
  • fq_codel is no longer supported under Adaptive QoS, due to architectural changes made by Trend Micro, preventing Asuswrt-Merlin's previous patch from injecting fq_codel into rules generated by the Trend Micro engine. Also, fq_codel is now the only scheduler used for Traditionnal QoS (removed option to select sfq or codel).
  • Fixed some ISPs that failed to renew DHCP leases when Adaptive QoS was enabled.
  • Removed largely unused and outdated support for the Cloudcheck mobile app (I bet virtually none of you knew it even existed)
  • Improvements to the DNSPrivacy preset list implementation, and the addition of AdGuard and CIRA Canadian Shield to the list
  • Increased the number of available mount points for third party web pages from 10 to 20.
  • And a brand new website to better accommodate the list of supported models, and make publishing new releases easier (and more automated) for me.

Please review the changelog for the complete list of changes as well as important upgrade informations.

Also, please limit discussions in this thread to this specific release. General support questions should be posted in a separate thread. Also note that this thread will be closed after a while once the initial launch feedback has slowed down.


Downloads are here.
Changelog is here.
@RMerlin

You have chosen a great time to launch your release, it is at a point where it seems very stable and not disturbed by any of asus beta mishaps. Great work, my router and nodes appear to be fully stable on this release. Everything appears to be running smoothly. Speeds are slightly improved as well. Keep up the awesome job you do.
 
I've been running 384.19 since it was release without issues on a RT-AC68U V2. Decided to try a 'dirty' upgrade to 386.1 but unfortunately 5 GHz wifi was very unstable after the upgrade. Connection dropped every few minutes.

Reloaded 384.19 and did a factory default reset (I.E. power on holding WPS button), restored jffs and config from backups and router running smoothly again.

I didn't have time to do a full reconfig on 386.1 but a 'dirty' upgrade was not successful for me.
 
Thank you for new builds @RMerlin.

Just updated my two routers, main and node. Seems working fine!
Uptaime: 0 days 0 hour(s) 56 minute(s) 9 seconds

Roamassist and NTP do what they should.

Jan 31 08:07:05 roamast: ROAMING Start...

Jan 31 08:17:45 roamast: [EXAP]Deauth old sta in 1 0: 04:8C:9A:xx:xx:xx
Jan 31 08:17:45 roamast: eth7: disconnect weak signal strength station [04:8c:9a:xx:xx:xx]
Jan 31 08:17:45 roamast: eth7: remove client [04:8c:9a:xx:xx:xx] from monitor list

Jan 31 08:07:06 (vpnc.sh): 2315 NTP synced in [4] seconds.
 
Dirty upgrade from beta 5 and everything seems to work fine except a minor bug.

I have a Synology NAS with two ethernet ports, but just one is connected to the node. Both ports are manually IP assigned under DSM.

The router is showing, under the client list, that the NAS is connected using the IP from the port 2 (which is the port that it is not wired to the node).

And the NAS is not accesible using the port that it is shown in the client list, which is logical because this port is not connected. The NAS is only accesible using the IP from the port 1, which is the port connected to the node, but which IP is not shown in the client list.
 
Try rebooting the NAS, or, simply unplugging the LAN cables for a few minutes and plugging them back in.
 
Upgraded my RT-AC86U from beta5. Everything seems to work.
 
I am still using 384.19 on my AC68U. Planning to upgrade to 386.1 soon. Is there any way to optimize nvram by any means?

In my 394.19 I keep seeing an this warning below. I tried removing some static IP, but didn't help much. I know one way to solve this is to factory reset and configure everything from scratch. Just checking to see if there's any shortcut.

384.19_nvram_issue.PNG
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

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