Release Asuswrt-Merlin 386.12 is now available for AC models

[Diamond67]

I updated my home router to 386.12_2 (dirty update) about 15 hours ago. And after that used Wi-Fi for about 6 hours.

I only use 5 GHz radio.

After some 12 hours when I came home I noticed that Wi-Fi won't work at all. I rebooted the router and got the Wi-Fi up and running again. But after an hour or so, the Wi-Fi had died again and had to reboot again.

I checked connmon logs and the there were no problem with the internet connection. Just the Wi-Fi dies.

Before updating I had been running the fw 386.12_0 without any problems at all. Uptime for weeks.

Anyone else having trouble with Wi-Fi after updating to 386.12_2?

I have been still testing fw 386.12_2, and Wi-Fi keeps dying on regular basis. Wi-Fi will be very probably useless within some 24 hours of router uptime. Sometimes less.

Last time I didn't reboot the router but logged in with a wired computer instead, opened scMerlin and manually restarted WiFi (4.). After that the wireless connections could be activated again.


edit: decided to go back to 386.12_0 to rule out any hardware problem. Let's see if this move will cure my Wi-Fi uptime problem or not.

 

[Maverickcdn]

Just posting for informational purposes... I have never ever seen openvpn crash in all my years running merlin. This happened with an obfsproxy server on the lan forwarded to the openvpn server, but I've run this setup 24/7 since the 384.x days without issue. Because obfsproxy runs on port 993 I get lots of doorknockers who triggered this crash. The TLS negotiation failure is common from these door knockers and normal. Fail2ban on the server did ban this IP at the same time which may have had some influence cutting off traffic to the vpn server.

Spoiler: openvpn crash

Nov 18 19:39:30 kernel: obfsproxy993 IN=eth0 OUT=br0 MAC=04:92:26:80:8b:08:00:01:5c:97:f8:45:08:00 SRC=198.235.24.253 DST=10.1.1.11 LEN=44 TOS=0x00 PREC=0x00 TTL=60 ID=54321 PROTO=TCP SPT=52253 DPT=993 WINDOW=65535 RES=0x00 SYN URGP=0 MARK=0x8000000
Nov 18 19:40:36 kernel: obfsproxy993 IN=eth0 OUT=br0 MAC=04:92:26:80:8b:08:00:01:5c:97:f8:45:08:00 SRC=198.235.24.253 DST=10.1.1.11 LEN=60 TOS=0x00 PREC=0x00 TTL=60 ID=14155 DF PROTO=TCP SPT=59932 DPT=993 WINDOW=65320 RES=0x00 SYN URGP=0 MARK=0x8000000
Nov 18 19:40:36 ovpn-server1[2567]: TCP connection established with [AF_INET]10.1.1.11:59092
Nov 18 19:40:36 kernel: obfsproxy993 IN=eth0 OUT=br0 MAC=04:92:26:80:8b:08:00:01:5c:97:f8:45:08:00 SRC=198.235.24.253 DST=10.1.1.11 LEN=60 TOS=0x00 PREC=0x00 TTL=60 ID=59905 DF PROTO=TCP SPT=59938 DPT=993 WINDOW=65320 RES=0x00 SYN URGP=0 MARK=0x8000000
Nov 18 19:41:36 ovpn-server1[2567]: 10.1.1.11:59092 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Nov 18 19:41:36 ovpn-server1[2567]: 10.1.1.11:59092 TLS Error: TLS handshake failed
Nov 18 19:41:36 kernel: vpnserver1[2567]: unhandled level 3 translation fault (11) at 0x00000000, esr 0x92000007
Nov 18 19:41:36 kernel: pgd = ffffffc01473e000
Nov 18 19:41:36 kernel: [00000000] *pgd=0000000014708003, *pud=0000000014708003, *pmd=000000001e102003, *pte=0000000000000000
Nov 18 19:41:36 kernel: CPU: 1 PID: 2567 Comm: vpnserver1 Tainted: P           O    4.1.27 #2
Nov 18 19:41:36 kernel: Hardware name: Broadcom-v8A (DT)
Nov 18 19:41:36 kernel: task: ffffffc01473d440 ti: ffffffc017278000 task.ti: ffffffc017278000
Nov 18 19:41:36 kernel: PC is at 0x85a00
Nov 18 19:41:36 kernel: LR is at 0x82458
Nov 18 19:41:36 kernel: pc : [<0000000000085a00>] lr : [<0000000000082458>] pstate: 200f0010
Nov 18 19:41:36 kernel: sp : 00000000ffe357d0
Nov 18 19:41:36 kernel: x12: 0000000000000000
Nov 18 19:41:36 kernel: x11: 0000000000000000 x10: 000000000067c8e0
Nov 18 19:41:36 kernel: x9 : 00000000000cf904 x8 : 000000000067ce60
Nov 18 19:41:36 kernel: x7 : 0000000000000001 x6 : 0000000000000002
Nov 18 19:41:36 kernel: x5 : 000000000067cd00 x4 : 000000000067be60
Nov 18 19:41:36 kernel: x3 : 000000000065f848 x2 : 0000000000000000
Nov 18 19:41:36 kernel: x1 : 0000000000000006 x0 : 0000000000000000
Nov 18 19:41:36 kernel: potentially unexpected fatal signal 11.
Nov 18 19:41:36 kernel: CPU: 1 PID: 2567 Comm: vpnserver1 Tainted: P           O    4.1.27 #2
Nov 18 19:41:36 kernel: Hardware name: Broadcom-v8A (DT)
Nov 18 19:41:36 kernel: task: ffffffc01473d440 ti: ffffffc017278000 task.ti: ffffffc017278000
Nov 18 19:41:36 kernel: PC is at 0x85a00
Nov 18 19:41:36 kernel: LR is at 0x82458
Nov 18 19:41:36 kernel: pc : [<0000000000085a00>] lr : [<0000000000082458>] pstate: 200f0010
Nov 18 19:41:36 kernel: sp : 00000000ffe357d0
Nov 18 19:41:36 kernel: x12: 0000000000000000
Nov 18 19:41:36 kernel: x11: 0000000000000000 x10: 000000000067c8e0
Nov 18 19:41:36 kernel: x9 : 00000000000cf904 x8 : 000000000067ce60
Nov 18 19:41:36 kernel: x7 : 0000000000000001 x6 : 0000000000000002
Nov 18 19:41:36 kernel: x5 : 000000000067cd00 x4 : 000000000067be60
Nov 18 19:41:36 kernel: x3 : 000000000065f848 x2 : 0000000000000000
Nov 18 19:41:36 kernel: x1 : 0000000000000006 x0 : 0000000000000000
Nov 18 19:41:36 kernel: br0: port 7(tap21) entered disabled state
Nov 18 19:42:00 rc_service: service 15922:notify_rc restart_vpnserver1
Nov 18 19:42:00 kernel: br0: port 7(tap21) entered listening state
Nov 18 19:42:00 kernel: br0: port 7(tap21) entered listening state
Nov 18 19:42:00 kernel: br0: port 7(tap21) entered disabled state
Nov 18 19:42:00 kernel: br0: port 7(tap21) entered disabled state
Nov 18 19:42:00 kernel: device tap21 entered promiscuous mode
Nov 18 19:42:00 kernel: br0: port 7(tap21) entered listening state
Nov 18 19:42:00 kernel: br0: port 7(tap21) entered listening state
Nov 18 19:42:00 custom_script: Running /jffs/scripts/openvpnserver1.postconf (args: /etc/openvpn/server1/config.ovpn)
Nov 18 19:42:00 ovpn-server1[16006]: WARNING: file '/tmp/mnt/MavNET16GB/router/vpn/MavVPN-SERVER.key' is group or others accessible
Nov 18 19:42:00 ovpn-server1[16006]: WARNING: file '/tmp/mnt/MavNET16GB/router/vpn/tls-crypt.key' is group or others accessible
Nov 18 19:42:00 ovpn-server1[16006]: OpenVPN 2.6.7 arm-buildroot-linux-gnueabi [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Nov 18 19:42:00 ovpn-server1[16006]: library versions: OpenSSL 1.1.1w  11 Sep 2023, LZO 2.08
Nov 18 19:42:00 ovpn-server1[16007]: NOTE: when bridging your LAN adapter with the TAP adapter, note that the new bridge adapter will often take on its own IP address that is different from what the LAN adapter was previously set to
Nov 18 19:42:00 ovpn-server1[16007]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Nov 18 19:42:00 ovpn-server1[16007]: TUN/TAP device tap21 opened
Nov 18 19:42:00 ovpn-server1[16007]: ovpn-up 1 server tap21 1500 0   init
Nov 18 19:42:00 ovpn-server1[16007]: Listening for incoming TCP connection on [AF_INET][undef]:31194
Nov 18 19:42:00 ovpn-server1[16007]: TCPv4_SERVER link local (bound): [AF_INET][undef]:31194
Nov 18 19:42:00 ovpn-server1[16007]: TCPv4_SERVER link remote: [AF_UNSPEC]
Nov 18 19:42:00 ovpn-server1[16007]: Initialization Sequence Completed
Nov 18 19:42:02 kernel: br0: port 7(tap21) entered learning state
Nov 18 19:42:04 kernel: br0: topology change detected, propagating
Nov 18 19:42:04 kernel: br0: port 7(tap21) entered forwarding state

 

[RMerlin]

Just posting for informational purposes... I have never ever seen openvpn crash in all my years running merlin. This happened with an obfsproxy server on the lan forwarded to the openvpn server, but I've run this setup 24/7 since the 384.x days without issue. Because obfsproxy runs on port 993 I get lots of doorknockers who triggered this crash. The TLS negotiation failure is common from these door knockers and normal. Fail2ban on the server did ban this IP at the same time which may have had some influence cutting off traffic to the vpn server.

Spoiler: openvpn crash

Nov 18 19:39:30 kernel: obfsproxy993 IN=eth0 OUT=br0 MAC=04:92:26:80:8b:08:00:01:5c:97:f8:45:08:00 SRC=198.235.24.253 DST=10.1.1.11 LEN=44 TOS=0x00 PREC=0x00 TTL=60 ID=54321 PROTO=TCP SPT=52253 DPT=993 WINDOW=65535 RES=0x00 SYN URGP=0 MARK=0x8000000
Nov 18 19:40:36 kernel: obfsproxy993 IN=eth0 OUT=br0 MAC=04:92:26:80:8b:08:00:01:5c:97:f8:45:08:00 SRC=198.235.24.253 DST=10.1.1.11 LEN=60 TOS=0x00 PREC=0x00 TTL=60 ID=14155 DF PROTO=TCP SPT=59932 DPT=993 WINDOW=65320 RES=0x00 SYN URGP=0 MARK=0x8000000
Nov 18 19:40:36 ovpn-server1[2567]: TCP connection established with [AF_INET]10.1.1.11:59092
Nov 18 19:40:36 kernel: obfsproxy993 IN=eth0 OUT=br0 MAC=04:92:26:80:8b:08:00:01:5c:97:f8:45:08:00 SRC=198.235.24.253 DST=10.1.1.11 LEN=60 TOS=0x00 PREC=0x00 TTL=60 ID=59905 DF PROTO=TCP SPT=59938 DPT=993 WINDOW=65320 RES=0x00 SYN URGP=0 MARK=0x8000000
Nov 18 19:41:36 ovpn-server1[2567]: 10.1.1.11:59092 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Nov 18 19:41:36 ovpn-server1[2567]: 10.1.1.11:59092 TLS Error: TLS handshake failed
Nov 18 19:41:36 kernel: vpnserver1[2567]: unhandled level 3 translation fault (11) at 0x00000000, esr 0x92000007
Nov 18 19:41:36 kernel: pgd = ffffffc01473e000
Nov 18 19:41:36 kernel: [00000000] *pgd=0000000014708003, *pud=0000000014708003, *pmd=000000001e102003, *pte=0000000000000000
Nov 18 19:41:36 kernel: CPU: 1 PID: 2567 Comm: vpnserver1 Tainted: P           O    4.1.27 #2
Nov 18 19:41:36 kernel: Hardware name: Broadcom-v8A (DT)
Nov 18 19:41:36 kernel: task: ffffffc01473d440 ti: ffffffc017278000 task.ti: ffffffc017278000
Nov 18 19:41:36 kernel: PC is at 0x85a00
Nov 18 19:41:36 kernel: LR is at 0x82458
Nov 18 19:41:36 kernel: pc : [<0000000000085a00>] lr : [<0000000000082458>] pstate: 200f0010
Nov 18 19:41:36 kernel: sp : 00000000ffe357d0
Nov 18 19:41:36 kernel: x12: 0000000000000000
Nov 18 19:41:36 kernel: x11: 0000000000000000 x10: 000000000067c8e0
Nov 18 19:41:36 kernel: x9 : 00000000000cf904 x8 : 000000000067ce60
Nov 18 19:41:36 kernel: x7 : 0000000000000001 x6 : 0000000000000002
Nov 18 19:41:36 kernel: x5 : 000000000067cd00 x4 : 000000000067be60
Nov 18 19:41:36 kernel: x3 : 000000000065f848 x2 : 0000000000000000
Nov 18 19:41:36 kernel: x1 : 0000000000000006 x0 : 0000000000000000
Nov 18 19:41:36 kernel: potentially unexpected fatal signal 11.
Nov 18 19:41:36 kernel: CPU: 1 PID: 2567 Comm: vpnserver1 Tainted: P           O    4.1.27 #2
Nov 18 19:41:36 kernel: Hardware name: Broadcom-v8A (DT)
Nov 18 19:41:36 kernel: task: ffffffc01473d440 ti: ffffffc017278000 task.ti: ffffffc017278000
Nov 18 19:41:36 kernel: PC is at 0x85a00
Nov 18 19:41:36 kernel: LR is at 0x82458
Nov 18 19:41:36 kernel: pc : [<0000000000085a00>] lr : [<0000000000082458>] pstate: 200f0010
Nov 18 19:41:36 kernel: sp : 00000000ffe357d0
Nov 18 19:41:36 kernel: x12: 0000000000000000
Nov 18 19:41:36 kernel: x11: 0000000000000000 x10: 000000000067c8e0
Nov 18 19:41:36 kernel: x9 : 00000000000cf904 x8 : 000000000067ce60
Nov 18 19:41:36 kernel: x7 : 0000000000000001 x6 : 0000000000000002
Nov 18 19:41:36 kernel: x5 : 000000000067cd00 x4 : 000000000067be60
Nov 18 19:41:36 kernel: x3 : 000000000065f848 x2 : 0000000000000000
Nov 18 19:41:36 kernel: x1 : 0000000000000006 x0 : 0000000000000000
Nov 18 19:41:36 kernel: br0: port 7(tap21) entered disabled state
Nov 18 19:42:00 rc_service: service 15922:notify_rc restart_vpnserver1
Nov 18 19:42:00 kernel: br0: port 7(tap21) entered listening state
Nov 18 19:42:00 kernel: br0: port 7(tap21) entered listening state
Nov 18 19:42:00 kernel: br0: port 7(tap21) entered disabled state
Nov 18 19:42:00 kernel: br0: port 7(tap21) entered disabled state
Nov 18 19:42:00 kernel: device tap21 entered promiscuous mode
Nov 18 19:42:00 kernel: br0: port 7(tap21) entered listening state
Nov 18 19:42:00 kernel: br0: port 7(tap21) entered listening state
Nov 18 19:42:00 custom_script: Running /jffs/scripts/openvpnserver1.postconf (args: /etc/openvpn/server1/config.ovpn)
Nov 18 19:42:00 ovpn-server1[16006]: WARNING: file '/tmp/mnt/MavNET16GB/router/vpn/MavVPN-SERVER.key' is group or others accessible
Nov 18 19:42:00 ovpn-server1[16006]: WARNING: file '/tmp/mnt/MavNET16GB/router/vpn/tls-crypt.key' is group or others accessible
Nov 18 19:42:00 ovpn-server1[16006]: OpenVPN 2.6.7 arm-buildroot-linux-gnueabi [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Nov 18 19:42:00 ovpn-server1[16006]: library versions: OpenSSL 1.1.1w  11 Sep 2023, LZO 2.08
Nov 18 19:42:00 ovpn-server1[16007]: NOTE: when bridging your LAN adapter with the TAP adapter, note that the new bridge adapter will often take on its own IP address that is different from what the LAN adapter was previously set to
Nov 18 19:42:00 ovpn-server1[16007]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Nov 18 19:42:00 ovpn-server1[16007]: TUN/TAP device tap21 opened
Nov 18 19:42:00 ovpn-server1[16007]: ovpn-up 1 server tap21 1500 0   init
Nov 18 19:42:00 ovpn-server1[16007]: Listening for incoming TCP connection on [AF_INET][undef]:31194
Nov 18 19:42:00 ovpn-server1[16007]: TCPv4_SERVER link local (bound): [AF_INET][undef]:31194
Nov 18 19:42:00 ovpn-server1[16007]: TCPv4_SERVER link remote: [AF_UNSPEC]
Nov 18 19:42:00 ovpn-server1[16007]: Initialization Sequence Completed
Nov 18 19:42:02 kernel: br0: port 7(tap21) entered learning state
Nov 18 19:42:04 kernel: br0: topology change detected, propagating
Nov 18 19:42:04 kernel: br0: port 7(tap21) entered forwarding state

Might be related to this:

Do not check key_state buffers that are in S_UNDEF state · OpenVPN/openvpn@b90ec6d

When a key_state is in S_UNDEF the send_reliable is not initialised. So checking it might access invalid memory or null pointers. Github: fixes OpenVPN/openvpn#449 Change-Id: I226a73d47a2b1b29f7e...

github.com

 

[Maverickcdn]

Might be related to this:

Do not check key_state buffers that are in S_UNDEF state · OpenVPN/openvpn@b90ec6d

When a key_state is in S_UNDEF the send_reliable is not initialised. So checking it might access invalid memory or null pointers. Github: fixes OpenVPN/openvpn#449 Change-Id: I226a73d47a2b1b29f7e...

github.com

Thanks, I've been up 50 hours and have had 4 crashes since, thankfully the watchdog works great

I'll wait patiently for the next update of the firmware with 2.6.8 and hope they've resolved it

 

[sykogee]

I updated my home router to 386.12_2 (dirty update) about 15 hours ago. And after that used Wi-Fi for about 6 hours.

I only use 5 GHz radio.

After some 12 hours when I came home I noticed that Wi-Fi won't work at all. I rebooted the router and got the Wi-Fi up and running again. But after an hour or so, the Wi-Fi had died again and had to reboot again.

I checked connmon logs and the there were no problem with the internet connection. Just the Wi-Fi dies.

Before updating I had been running the fw 386.12_0 without any problems at all. Uptime for weeks.

Anyone else having trouble with Wi-Fi after updating to 386.12_2?

Ive had a similar issue on my AC88U router updating from 386.11 to either 386.12 or 386.12_2 - after hard reset of the router it takes around 35mins for the 5Ghz wifi to become available, the 2.4Ghz wifi is available after a couple of mins after a reboot.
The speed on the 5Ghz on 386.12_x firmware is slow unable to get faster than 130 - 140mbs, even copying from a local wired PC or NAS.
When running on 386.11 firmware devices can hit around 400Mbs on 5Ghz wifi.
Seems that there could be an issue somewhere

 

[bibikalka]

I am not fully sure - but it seemed there was some subtle screwy-ness with AC86U running 12_2, and the node AC68U running 12_0.

Weird small connection freezes which I don't recall before.

Anyway, I ended up reverting to 12_0 on AC86U, and since I do filter out a bunch of messages from the log anyway, I can handle more frequent dcd errors without being too bothered about that.

 

[gmy]

Hi there, new in the forum with a possible related bug (or not).
I am aware of the problems that enabling AiProtection appears to cause in my AC86u router, but when enabled I constantly get this type of errors in the log (I searched for it but couldn't find anything related):

Nov 20 03:13:14 kernel: ct_p ffffffc01427a1c8 evict flow ffffff8000b59600 key 0x60002d86 before set key 0x60002e54 for flow ffffff8000b66400 cur_time 7610
Nov 20 03:13:14 kernel: ct_p ffffffc01674aa60 evict flow ffffff8000b7de00 key 0x60002fce before set key 0x60002df3 for flow ffffff8000b60300 cur_time 7610
Nov 20 03:13:15 kernel: ct_p ffffffc0111d3538 evict flow ffffff8000b49a00 key 0x60002c8a before set key 0x60002f90 for flow ffffff8000b7a000 cur_time 7610

Is this somehow related to TrendMicro, is it another bug or it's innocuous and I'm worrying about nothing? When I disable AiProtection it goes away.

ASUS RT-AC86U with Asuswrt-Merlin 386.12_2 and Skynet installed and running.
Thanks.

 

[heysoundude]

I am not fully sure - but it seemed there was some subtle screwy-ness with AC86U running 12_2, and the node AC68U running 12_0.

I've been able to disable 2.4GHz on my AC86 w/ N66 Media Bridge, and adjust the wireless config of the 86 to surprising and reassuring ends.
Depending on your requirements, you may surprise yourself with the improvements. I'm increasingly inclined to tell people AiMesh doesn't live up to the hype and may cause more problems than it's believed to solve. YMMV.

 

[Tomo]

reverted to 386.12 , i had some disconnections on two 2.4 wifi devices (security camera), never had them before .

 

[latenitetech]

Might be related to this:

Do not check key_state buffers that are in S_UNDEF state · OpenVPN/openvpn@b90ec6d

When a key_state is in S_UNDEF the send_reliable is not initialised. So checking it might access invalid memory or null pointers. Github: fixes OpenVPN/openvpn#449 Change-Id: I226a73d47a2b1b29f7e...

github.com

As another data point, I'm hitting this same issue too with 386.12_2. My openvpn server is pretty much useless shortly after reboot. I noticed I'm now seeing an 'undef' client in the connected client list (never saw that before), and although I have other connected clients, I can't access any of them. I assume the 'undef' client is from a flakey WiFi connection, and it's locking up the server. Rolled back to 386_12 and all is good again. I will wait for the next openvpn update before taking another router firmware update.

 

[RMerlin]

As another data point, I'm hitting this same issue too with 386.12_2. My openvpn server is pretty much useless shortly after reboot. I noticed I'm now seeing an 'undef' client in the connected client list (never saw that before), and although I have other connected clients, I can't access any of them. I assume the 'undef' client is from a flakey WiFi connection, and it's locking up the server. Rolled back to 386_12 and all is good again. I will wait for the next openvpn update before taking another router firmware update.

A temporary workaround would be to change to a different, less common port, so the server won`t get hit by scanners which are probably what triggers the issue.

One of the OpenVPN devs asked for feedback on an open ticket to confirm that this fix covered all reported issues. I'm waiting for an answer before I go ahead and issue an updated firmware.

 

[RMerlin]

reverted to 386.12 , i had some disconnections on two 2.4 wifi devices (security camera), never had them before .

No change to wifi in 386.12_2. The only changes were OpenVPN, and the Trend Micro engine. Your issue is coming from elsewhere.

 

[latenitetech]

A temporary workaround would be to change to a different, less common port, so the server won`t get hit by scanners which are probably what triggers the issue.

One of the OpenVPN devs asked for feedback on an open ticket to confirm that this fix covered all reported issues. I'm waiting for an answer before I go ahead and issue an updated firmware.

Eric, thanks for the quick reply, but I'm pretty sure the source is "friendly fire," i.e. "my" clients. I'm already using alternate ports for the in-bound vpn server traffic; that dramatically cut down on hacking when I implemented that change several years ago.

As one of my retirement gigs, I do consulting for museums around the US, and implement exhibits that use Raspberry Pi's under the cover for media playback, lighting control and other special effects. I have them set up like an IoT device where my RT-AC68U running openvpn is "the cloud." This way I can monitor their activity and issue updates without having to travel to the actual museum sites. Unfortunately, some have very poor WiFi connectivity and tend to come and go. (I'm wholly dependent on the museum's WiFi network and have little to no influence over it.) In the past, the openvpn server has apparently been tolerant of this flakiness, but this new "undef" problem is a killer for me. No biggie, I'm fine sticking with 386_12 until a fix is available.

 

[heywire]

I do a weekly reboot, on Sat morning at 3am. But I use a separate device, a Zigbee power adapter, to power cycle the router at that time. Over the years, I found the router methods for doing reboots were unreliable.

From the sounds of this thread, I think I will pass on 386.12_2, and wait for the next version.

If think you should go ahead and try for yourself. With the exception of the post-flash blues that only required a manual soft-reboot (via SSH), in general things seems snappier on 386.12_2, probably because of the Trend Micro hiccups that it seeks to address.

I also experienced this problem on earlier versions, at least 386.12, if I remember correctly even before that.

Just be aware that you probably need to reboot the router manually after it comes back online (not quite online) after the firmware upgrade.

 

[st3v3n]

Successfully pgraded my RT-AC86 and GT-AC2900 from V386.10 to 386.12.2, no changes in any parameters; I always turn Wi-fi off, logoff and reboot the router prior to upgrading. Running OpenVPN configs on client one and two. No Wi-fi drops. Still trying to figure how to append Adblock servers within the tunnels, nothing drops to ISP's naked network on WAN, otherwise, this build is A-OK for me. Many thanks to Merlin for the countless hours of work over the years on this FW, wouldn't be without it!

 

[JTnola]

386.12 is so stable and wonderful. (For real)

From what im reading here, since I haven’t yet tried to update to 386.12_2, the verdict is that I should probably just stay put where at. (Unless someone has an argument to make in favor of trying the update…..?)

 

[L&LD]

Asuswrt-Merlin Changelog
========================

386.12_2 (12-Nov-2023)
- UPDATED: openssl to 1.1.1w.
- UPDATED: curl to 8.4.0.
- UPDATED: openvpn to 2.6.7.
- FIXED: WPS not working on SDK6/SDK7 devices (affecting
RT-AC68U and RT-AC88U/3100/5300)
- FIXED: dcd constantly crashing (updated Trend Micro
components)

There's an argument to consider.

 

[RMerlin]

386.12 is so stable and wonderful. (For real)

From what im reading here, since I haven’t yet tried to update to 386.12_2, the verdict is that I should probably just stay put where at. (Unless someone has an argument to make in favor of trying the update…..?)

The only problem introduced by 386.12_2 is related to OpenVPN.

 

[Tomo]

No change to wifi in 386.12_2. The only changes were OpenVPN, and the Trend Micro engine. Your issue is coming from elsewhere.

yes i know, for the moment not using Trend Micro i didn't suffer from the famous DCD error so for now i stay on .12, as soon as the fix for OpenVPN comes out i'll test everything again.
Thanks you

 

[Micharlie]

AC68U here. Although I have daily automatic reboots every morning at 4:40AM like I always had, this latest update make the Wifi unreachable every morning when we get up. I have to manually reboot the AC68U. I guess I should go back. The only thing I added after the new update was FlexQOS. That’s it.