Release Asuswrt-Merlin 386.1 is now available

[AntonK]

Quite possibly a silly error on my part here (upgrading late at night, on flu medication :/) went from 384.19 to 386.1, left JFFS USB in place - forgot to remove it prior to flashing - was using it for SNMP.. do I need to redo it now?

Also, I note that database maintenance etc happens on first boot after flash, wifi took upwards of 15 minutes to re-enable after rebooting manually as prompted. Is this part of the maintenance or has something potentially gone awry with my upgrade?

Thanks!

I always try to remember to "remove" my USB elegantly before a reboot, or upgrade. On a few occasions I've forgotten. I've never had to redo my USB in any sense because of that. Good luck!

 

[shabbs]

Have been enjoying this build since the weekend and I've now started down the path of AiMesh 2.0 enablement at our home now that all devices are up.

This should be interesting.

 

[sl4fko]

How many people are running this on an RT-AC86U without any issues?

I am. Looks stable, no issues, however running it only for 3 days.

I am having a problem with Guest network not working properly but I think, it is a general Asus firmware problem...

 

[L&LD]

Welcome to the forums @wonderiuy.

What model router do you have?

(You may consider adding that to your signature too).

 

[wonderiuy]

Ty, actually:
Main router: Asus RT-AC86U (386.1)
AiMesh Node1: Asus RT-AC86U (386.1)
AiMesh Node2: Asus MAP-AC1300 /Lyra mini) waiting for 386 firmware serie

 

[Wallace_n_Gromit]

@Wallace_n_Gromit I'm not sure in your case. Could it be a hardware issue is surfacing?

Fully Reset Router and Network

I would try the above (and repeat as necessary) until you're successful or you concede that the router may be due for replacement.

I was thinking that the router may be failing. I have left it on and running/idling off network just in case it needed to "settle". It will auto reboot every 24 hours. I will then try to revert to earlier Merlin versions/asus stock versions to confirm SSH failure across all firmwares.

Regardless, I am so pleased to own Asus routers, with Merlin firmwares (john9527's Fork too), and even the stock firmwares from a company that offer such prompt security updates [DNSpooq]

Edit: While troubleshooting the issue of failed SSH session in my primary RT-AC68U running 386.1 I did look at my [System Log] and see this:

Feb 2 13:19:00 rc_service: httpd 278:notify_rc restart_time;restart_leds;restart_usb_idle;restart_firewall;
Feb 2 13:19:00 ntpd: Stopped ntpd
Feb 2 13:19:00 syslogd exiting
Feb 2 13:19:01 syslogd started: BusyBox v1.25.1
Feb 2 13:19:01 kernel: klogd started: BusyBox v1.25.1 (2021-01-30 15:23:27 EST)
Feb 2 13:19:15 dropbear[2483]: Failed loading /etc/dropbear/dropbear_rsa_host_key
Feb 2 13:19:15 dropbear[2483]: Failed loading /etc/dropbear/dropbear_dss_host_key
Feb 2 13:19:15 dropbear[2483]: Failed loading /etc/dropbear/dropbear_ecdsa_host_key
Feb 2 13:19:15 dropbear[2483]: Failed loading /etc/dropbear/dropbear_ed25519_host_key
Feb 2 13:19:15 dropbear[2483]: Early exit: No hostkeys available. 'dropbear -R' may be useful or run dropbearkey.
Feb 2 13:19:15 hour_monitor: daemon is starting
Feb 2 13:19:15 hour_monitor: daemon terminate

Doing a duckduckgo search for what dropbear is (many of you already know, I'm a newbie about this) saw that:

Dropbear is a software package written by Matt Johnston that provides a Secure Shell-compatible server and client. It is designed as a replacement for standard OpenSSH for environments with low memory and processor resources, such as embedded systems. It is a core component of OpenWrt and other router distributions. Dropbear was originally released in April 2003

Why it failed I don't know but now I realize it is directly correlated as to why my SSH sessions will not work on my primary ASUS RT-AC68U running 386.1 (it is a good thing I have a backup RT-AC68U running 386.1 that dropbear does load and I can SSH into)

2nd Edit: When I reverted back to 384.19 on my primary RT68U--enabled SSH--and looked at my [System Log] I see this:

May 4 22:07:12 rc_service: httpd 233:notify_rc restart_time;restart_leds;restart_usb_idle;restart_firewall;restart_bhblock;
May 4 22:07:12 ntpd: Stopped ntpd
May 4 22:07:12 syslogd exiting
May 4 22:07:12 syslogd started: BusyBox v1.25.1
May 4 22:07:12 kernel: klogd started: BusyBox v1.25.1 (2020-08-14 15:17:43 EDT)
May 4 22:07:22 dropbear: Generated SSH keys
May 4 22:07:22 dropbear[1357]: Running in background
May 4 22:07:23 hour_monitor: daemon is starting
May 4 22:07:23 hour_monitor: daemon terminates
May 4 22:07:23 nat: apply nat rules (/tmp/nat_rules_eth0_eth0)
Feb 2 14:43:40 ntpd: Initial clock set

I can NOW SSH into my AC68U using 384.19 whereas I couldn't using 386.1. This rules out a hardware failure @L&LD on my device.

3rd Edit: After Factory Default Reset/Reboot I reinstalled 386.1. I then did a Factory Default Reset/Reboot then monitored the [System Log] for a short while before trying to enable SSH:

May 4 22:05:32 syslog: skip event due no re
Feb 2 15:28:50 ntpd: Initial clock set
Feb 2 15:28:50 rc_service: ntpd_synced 998:notify_rc restart_diskmon
Feb 2 15:28:50 disk_monitor: Finish
Feb 2 15:28:51 disk_monitor: be idle
Feb 2 15:29:09 crond[278]: time disparity of 1446860 minutes detected
Feb 2 15:30:47 kernel: Init chrdev /dev/idp with major 190
Feb 2 15:30:47 kernel: tdts: tcp_conn_max = 8000
Feb 2 15:30:47 kernel: tdts: tcp_conn_timeout = 300 sec
Feb 2 15:31:04 kernel: SHN Release Version: 2.0.1 7812743e
Feb 2 15:31:04 kernel: UDB Core Version: 0.2.18
Feb 2 15:31:04 kernel: Init chrdev /dev/idpfw with major 191
Feb 2 15:31:04 kernel: IDPfw: IDPfw is ready
Feb 2 15:31:04 kernel: sizeof forward pkt param = 192
Feb 2 15:31:04 BWDPI: fun bitmap = 3
Feb 2 15:31:18 kernel: IDPfw: Exit IDPfw
Feb 2 15:31:18 kernel: mod epilog takes 0 jiffies
Feb 2 15:31:18 kernel: IDPfw: Exit IDPfw
Feb 2 15:31:18 kernel: Exit chrdev /dev/idpfw with major 191
Feb 2 15:31:18 kernel: Exit chrdev /dev/idp with major 190
Feb 2 15:32:24 rc_service: httpd 279:notify_rc restart_wlcscan
Feb 2 15:32:33 kernel: nvram: consolidating space!
Feb 2 15:34:14 kernel: nvram: consolidating space!
Feb 2 15:34:14 kernel: Init chrdev /dev/idp with major 190
Feb 2 15:34:14 kernel: tdts: tcp_conn_max = 8000
Feb 2 15:34:14 kernel: tdts: tcp_conn_timeout = 300 sec
Feb 2 15:34:33 kernel: SHN Release Version: 2.0.1 7812743e
Feb 2 15:34:33 kernel: UDB Core Version: 0.2.18
Feb 2 15:34:33 kernel: Init chrdev /dev/idpfw with major 191
Feb 2 15:34:34 kernel: IDPfw: IDPfw is ready
Feb 2 15:34:34 kernel: sizeof forward pkt param = 192
Feb 2 15:34:34 BWDPI: fun bitmap = 3
Feb 2 15:34:47 kernel: IDPfw: Exit IDPfw
Feb 2 15:34:47 kernel: mod epilog takes 0 jiffies
Feb 2 15:34:47 kernel: IDPfw: Exit IDPfw
Feb 2 15:34:47 kernel: Exit chrdev /dev/idpfw with major 191
Feb 2 15:34:47 kernel: Exit chrdev /dev/idp with major 190
Feb 2 15:37:56 rc_service: httpd 279:notify_rc restart_time;restart_leds;restart_usb_idle;restart_firewall;
Feb 2 15:37:56 ntpd: Stopped ntpd
Feb 2 15:37:56 syslogd exiting
Feb 2 15:37:57 syslogd started: BusyBox v1.25.1
Feb 2 15:37:57 kernel: klogd started: BusyBox v1.25.1 (2021-01-30 15:23:27 EST)
Feb 2 15:38:10 dropbear[2362]: Failed loading /etc/dropbear/dropbear_rsa_host_key
Feb 2 15:38:10 dropbear[2362]: Failed loading /etc/dropbear/dropbear_dss_host_key
Feb 2 15:38:10 dropbear[2362]: Failed loading /etc/dropbear/dropbear_ecdsa_host_key
Feb 2 15:38:10 dropbear[2362]: Failed loading /etc/dropbear/dropbear_ed25519_host_key
Feb 2 15:38:10 dropbear[2362]: Early exit: No hostkeys available. 'dropbear -R' may be useful or run dropbearkey.
Feb 2 15:38:11 hour_monitor: daemon is starting
Feb 2 15:38:11 hour_monitor: daemon terminates

It appears that this particular router just refuses to allow dropbear to load, in firmware version 386.1, not allowing me to SSH into it (unlike 384.19--and every earlier versions I ever used--which were no problem). Maybe it just needs to "settle down". I will just leave it running for a few days, reboot daily, and see if things improve.

@RMerlin would this be a unique issue with only my router, or something that might warrant further investigation?

 

[molinski70]

Can't make speedtest to work after dirty upgrade from stock firmware on my AX-86,

 

[molinski70]

Can't make speedtest to work after dirty upgrade from stock firmware on my AX-86,

had to do a reset again to make it work

 

[Morac]

My RT-AC88U locked up and stopped responding to all network traffic again. I needed to do a hard reset. This isn’t something new as it happens every few months and I haven’t found the cause. I was hoping that would be fixed in 386.1, but apparently not.

 

[L&LD]

@Morac, happening for months?

If you're following a systematic approach to the resets and striving to eliminate all possible 'remnants' of old code from remaining active on new firmware, then it may be a hardware issue?

I can't remember if you've mentioned doing a full reset after flashing to the 386.1_0 release final?

Fully Reset Router and Network

Best Practice Update/Setup Router/AiMesh Node(s) 2021

 

[DanNuke86]

Does anyone know if these reports in the Syslog should still be happening? I know this has been brought up previously in the beta etc, but I’m still none the wiser about it and what it actually is?

17:52:00 kernel: CONSOLE: 200425.969 wl1: wlc_recv: dropping a frame with invalid src mac addressaf:6c:d0:01:08:3b
Feb 2

17:52:00 kernel: CONSOLE: 200425.969 Unexpected RX reason 22 {if=wl1 fc=0040 seq=12a0 A1=ff:ff:ff:ff:ff:ff A2=af:6

 

[ATLga]

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.

I've never seen so many questions asked about things that have been asked & answered a hundred times before. Maybe the Upgrade Notes should include a link to the 60 page Beta thread (here: https://www.snbforums.com/threads/asuswrt-merlin-386-1-beta-stage-2-is-now-available.69116/ )and be made required reading before one is allowed to download the firmware. Makes your head spin...just wow...

 

[Morac]

@Morac, happening for months?

It’s been happening randomly since at least Summer 2017. i haven’t full reset lately, but have since I first saw the issue. In 2020 it happened 3 times: Jan, Oct and Dec. So far this year it happened once (today).

No idea why exactly, since the lights on the router still blink, but all network traffic just stops and sometimes WiFi goes down. There’s nothing in the logs.

Had it happen once when I was on a trip overseas and I had to have someone drive to my house to power the router off and on. I had purposely power cycled the router before I left to prevent that from happening, but that didn’t help.

I‘m thinking of getting something like this to work around this next time I go on a trip.
https://www.amazon.com/dp/B0861NX6H2/?tag=snbforums-20

 

[Rob Q]

I'm preparing to upgrade my router from 384.19 to 386.1 and I would like to know if I'm good to go for a nice and smooth and successful upgrade..
Model: RT-AC1900P
Current temps are: 2.4 GHz: 49°C - 5 GHz: 53°C - CPU: 77°C

Memory
Total 249.68 MB
Free 117.48 MB
Buffers 1.08 MB
Cache 11.98 MB
Swap 0.00 / 2048.00 MB
Internal Storage
NVRAM usage 52638 / 65536 bytes
JFFS 4.16 / 62.75 MB

Installed packages (made sure everything was up to date):

amtm 3.1.8 FW
Diversion v4.1.12
Skynet v7.2.3
scMerlin v2.1.0
Entware

Steps I've taken:
Save setting (left the box unchecked to share config for debugging)
Saved a backup of the JFFS partition.

My current ISP plan is 40 Mbps / 10 Mbps but I am getting 44 Mbps / 11 Mbps. I see some folks are saying that they are seeing a speed increase. Since I'm capped at 40/10 could I see much of an improvement?

 

[L&LD]

@Morac is power (consistency) an issue in your area? I would consider a UPS first over what you linked (particularly if you have a USB drive with amtm attached).

 

[L&LD]

@Rob Q looks like you're well prepared.

Just be prepared to do a full reset if necessary and be sure to note that after the upgrade, the web GUI may not be available for up to 60 minutes or more.

Best Practice Update/Setup Router/AiMesh Node(s) 2021

 

[aspen63]

AC5300, dirty update. Blocks out some devices on wi-fi after several hours. Have to revert back to 384, I'm afraid.

 

[bbunge]

I am. Looks stable, no issues, however running it only for 3 days.

I am having a problem with Guest network not working properly but I think, it is a general Asus firmware problem...

I initially did an upgrade from 384.19. It worked right out of the box but I lost connection to the web gui a few hours later. Doing SSH to the router and restarting the HTTPD did not work. So, I did a Factory Default Reset and configured manually. Seems to be working OK. 2.4 GHZ does not see as strong as before. Rebooted yesterday and the Ecobee t'stat did not reconnect. Have had FlexQOS on and off and their beta with fq_codel which I removed.
Your issue with Guest WIFI may not be an issue but the way Guest Network 1 on both bands works. Under Guest Network 1 the 2.4 GHZ IP range is 192.168.101.0/24 and the 5 GHZ is 192.168.102.0/24 This is to enable guest across nodes and it does work very well in stock Asus firmware.

 

[zackattack784]

Anybody having issues where iPhones just hang and you eventually get a “Safari could not open the page because the server stopped responding” message? Has only happened since 386.1. I’ve tried resetting network settings on the phones and I’ve done a full reset on both my router and node (AX88U and AX58U). When it happens it doesn’t matter what website I try I get the same message.

Seems to happen randomly but often enough to be very annoying. Nothing in the logs when it happens.

For anyone with the same problem, it seems it was caused by Aimesh. I had always run my AX58U as an AP but decided to try out Aimesh 2.0. Switched it back to an AP and problem went away. Weird considering everybody else seems to have good results with Aimesh.

 

[roboots21]

AC5300, dirty update. Blocks out some devices on wi-fi after several hours. Have to revert back to 384, I'm afraid.

Before you roll back, perhaps a reset is in order. If you're having unexplained issues (which this sounds like), a full reset will likely remedy.