Release Asuswrt-Merlin 386.12 is now available for AC models

[Diamond67]

I installed 386.12_2 and after reboot my Samsung phone and tablet didn't want to connect to both 2.4 and 5GHz SSIDs. It looked like the passphrase was wrong. My Windows computer was able to connect, but when I disconnected and tried to connect back, it also refused.

Yeah.

Seems that when the problem kicks in, if you have a device connected to Wi-Fi, the connection won't be disconnected and you are totally unaware of the fact that the Wi-Fi is actually completely useless because you cannot disconnect and reconnect to Wi-Fi with any device any more. You need to reboot the router to get access to Wi-Fi, which is PIA.

Seems that I have to go back to fw 386.12_0 as well...

 

[bibikalka]

I'm still experiencing major crashes after firmware update to 386.12_2: main router's wifi is working, but WebGUI is down and all Aimesh routers are down.

I have to SSH into the main router and reboot. After rebooting, things are back working ok, but it's no fun (hell of a chore before I sat up SSH in order to be able to reboot remotely).

I think this started with 3.12 (or not many versions ago; most likely 386.12, maybe 386.11, max back to 386.10 I'd wager).

But I did a fair bit of flashing back and forth between 386.11 and 12, so it's happening consistently, not a one off.

Anybody else experiencing this?

Had this issue on 12_0 - TMicro was running. Gave up and implemented nightly reboots, as to keep things always fresh.

Yeah.

Seems that when the problem kicks in, if you have a device connected to Wi-Fi, the connection won't be disconnected and you are totally unaware of the fact that the Wi-Fi is actually completely useless because you cannot disconnect and reconnect to Wi-Fi with any device any more. You need to reboot the router to get access to Wi-Fi, which is PIA.

Seems that I have to go back to fw 386.12_0 as well...

I had similar issues with 12_0. It'd happen from time to time after a good stretch of uptime. Had to reboot manually. I implemented nightly reboots.

Since then a couple of weeks ago it happened within 12 hours after a reboot (with 12_0 version), and the system had thrown a serious error before that happened. See the log below.

Oct 31 12:45:00 crashlog: LOG
Oct 31 12:45:00 crashlog: <4>LR is at 0xf701a63c
Oct 31 12:45:00 crashlog: <4>pc : [<00000000f701a650>] lr : [<00000000f701a63c>] pstate: a00b0010
Oct 31 12:45:00 crashlog: <4>sp : 00000000fff8b890
Oct 31 12:45:00 crashlog: <4>x12: 00000000f70e64c0
Oct 31 12:45:00 crashlog: <4>x11: 00000000fff8b8c4 x10: 0000000000000000
Oct 31 12:45:00 crashlog: <4>x9 : 0000000000000128 x8 : 00000000f70b8000
Oct 31 12:45:00 crashlog: <4>x7 : 0000000000000000 x6 : 0000000000000001
Oct 31 12:45:00 crashlog: <4>x5 : 00000000fff8b890 x4 : 0000000000000000
Oct 31 12:45:00 crashlog: <4>x3 : 00000000f70ec050 x2 : 0000000000000000
Oct 31 12:45:00 crashlog: <4>x1 : 000000000000445b x0 : 0000000000000000
Oct 31 12:45:00 crashlog: <4>
Oct 31 12:45:00 crashlog: <6>potentially unexpected fatal signal 7.
Oct 31 12:45:00 crashlog: <4>
Oct 31 12:45:00 crashlog: <4>CPU: 0 PID: 2333 Comm: vnstatd Tainted: P        W  O    4.1.27 #2
Oct 31 12:45:00 crashlog: <4>Hardware name: Broadcom-v8A (DT)
Oct 31 12:45:00 crashlog: <4>task: ffffffc0191df480 ti: ffffffc012b4c000 task.ti: ffffffc012b4c000
Oct 31 12:45:00 crashlog: <4>PC is at 0x7f7d53de68
Oct 31 12:45:00 crashlog: <4>LR is at 0x7f7d543db0

 

[Squall Leonhart]

I'm still experiencing major crashes after firmware update to 386.12_2: main router's wifi is working, but WebGUI is down and all Aimesh routers are down.

I'm afraid this is more than likely decaying hardware.

 

[CaptnDanLKW]

FWIW, my RT-AC86U never had the dcd or asd process crashing most others had. I use the trend micro features and have a few addons, but not Diversion or Skynet (ones that make dcd angry regardless).

Interestingly, asd process crashed once since going to 12_2, but I'll just assume it's a transitive condition for now.

For those with 'other' gremlins, like the vnstatd crash, did you also upgrade the entware packages? I have had very bad luck with upgrading entware the past few times, especially when one of the upgraded packages is libopenssl... entware upgrades have killed my scribe & vnstat addons multiple times. I tried all the fixes, manual removal of and re-adds of packages. In the end I just re-did my entware install and restored my configs (and vnstat database)

Not saying this is anyone's issue; just a word of caution when making multiple changes at the same time, even if it seems routine.

 

[maxbraketorque]

FWIW, my RT-AC86U never had the dcd or asd process crashing most others had. I use the trend micro features and have a few addons, but not Diversion or Skynet (ones that make dcd angry regardless).

Interestingly, asd process crashed once since going to 12_2, but I'll just assume it's a transitive condition for now.

For those with 'other' gremlins, like the vnstatd crash, did you also upgrade the entware packages? I have had very bad luck with upgrading entware the past few times, especially when one of the upgraded packages is libopenssl... entware upgrades have killed my scribe & vnstat addons multiple times. I tried all the fixes, manual removal of and re-adds of packages. In the end I just re-did my entware install and restored my configs (and vnstat database)

Not saying this is anyone's issue; just a word of caution when making multiple changes at the same time, even if it seems routine.

I don't run any add-ons have not made any config changes to my AC86Us in a long time. I'm only seeing the asd crash on one of my two AC86Us, and that particular router has been very unchanged for a long time and has very simple settings (it has always operated in AP mode). Definitely something introduced in the firmware starting with 386.12 that's driving this, maybe in combination with a particular user setting.

 

[heywire]

I'm afraid this is more than likely decaying hardware.

No, it works fine after a manual reboot. It is just the automatic reboot after the firmware upgrade where things are not working.

 

[L&LD]

Disable the automatic reboots.

 

[freddy2000]

RE: OpenVPN server issues with 386.12.2

I upgraded my ASUS RT-AC86U to 386.12.2 from 386.12.0. The OpenVPN server with the new firmware could not maintain the tunnel after the client made a connection for a few minutes. On the server it shows the client is connected, but on the client it turned into connecting. I have to reboot the server. But the problem comes back again. The problem is the same from all different client apps.

It has been fine with all previous versions of Asus-Merlin firmware.

I upgraded it remotely, but it looks like I cannot downgrade remotely.

Thanks.

 

[freddy2000]

By observing it for a couple of days. I report back the findings: with server running 386.12.2, if one of the client tunnels is dead, maybe due to bad mobile signal, the server turns this client to UNDEF. After this ALL the tunnels freeze up and all the connected client apps turn into connecting. No new client can make connection. The server will remain in this state forever until reboot. If I disconnect the connected client or even power off the device, the server still thinks it's connected. It looks like the server is stuck in a dead loop to resolve the UNDEF client.

With the previous versions of firmware, if one of the clients turns into UNDEF, the server automatically re-assigns a new tunnel IP to it and drops the UNDEF connection soon afterwards.

I cannot see I can do anything on the server settings or the client settings to resolve this.

 

[Sicario]

Hi,

Is this commit included in the latest 386.12_2 release? Is that the fix for the constant dcd crash issue? thanks

 

[KrypteX]

Hi,

Is this commit included in the latest 386.12_2 release? Is that the fix for the constant dcd crash issue? thanks

I don't think it is, since the tagged 386.12_2 doesn't list it https://github.com/RMerl/asuswrt-merlin.ng/commits/386.12_2
386.12_x neither https://github.com/RMerl/asuswrt-merlin.ng/commits/386.12_x

However, the 386_x branch includes it (see the two most recent Classification page related commits) https://github.com/RMerl/asuswrt-merlin.ng/commits/386_x
It's probably work considered for inclusion in the upcoming 386.13 branch.

The dcd crash fix should be the one from Nov 7 https://github.com/RMerl/asuswrt-merlin.ng/commit/f1e5d33f65185e1bd10feff48d107642b9ba934e

 

[freddy2000]

Welcome to the forum. I’d try exporting a new OpenVPN config file from the router and importing it into each of your devices that remotely connect. Doesn’t take long, and there’s a very good chance it’ll fix it. Please tell us the result.

Thanks for the warm welcome.
Re-exporting the .ovpn makes no difference. Looks like if one of the clients has a bad connection, such as bad mobile signal, the server turns the client into UNDEF and freezes all other clients forever until reboot. With the previous versions, the sever drops the dead tunnel and re-assign the client with a new IP and all other clients unaffected.

 

[Woody]

Yeah.

Seems that when the problem kicks in, if you have a device connected to Wi-Fi, the connection won't be disconnected and you are totally unaware of the fact that the Wi-Fi is actually completely useless because you cannot disconnect and reconnect to Wi-Fi with any device any more. You need to reboot the router to get access to Wi-Fi, which is PIA.

Seems that I have to go back to fw 386.12_0 as well...

I took delivery of my first ever Samsung this week (have always been a Xiaomi chap - but the incessant adverts, particularly for Temu, were getting on my tits).

Today, I have just had exactly your experience with the new Samsung, but I was able to recover by doing this on the Samsung:

1. Setting the MAC address type to "Phone MAC"

2. Setting metered network from auto, to unmetered.

Of course, your mileage may vary.

 

[JTnola]

IMHO: Not having a new/separate thread for the 386.12_2 release is very confusing.

(Unless I missed it?)

 

[Gnome10]

I got new factory firmware update on the 16th. Same problems. Version: 386_51665-g8072e52, on RT-AC66U-B1.

 

[TonyK132]

No, it works fine after a manual reboot. It is just the automatic reboot after the firmware upgrade where things are not working.

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.

 

[Woody]

I have been running 386.12_2 on an RT-AC86U for 5 days now. Apart from a config to block two device accessing the internet, I am running this vanilla, no Scripts or add-ons of any description.

This afternoon, it crashed and re-booted (fine), and the log was preserved so that during the reboot, it seemed to try and tell me why it had crashed:


"May 5 06:05:05 crashlog: <4>vis-dcon triggered out of memory codition (oom killer not called): gfp_mask=0x201da, order=0, oom_score_adj=0
May 5 06:05:05 crashlog: <4>
May 5 06:05:05 crashlog: <4>CPU: 0 PID: 20843 Comm: vis-dcon Tainted: P O 4.1.27 #2
May 5 06:05:05 crashlog: <4>Hardware name: Broadcom-v8A (DT)"

I have no idea what vis-dcon is - any bright ideas?

 

[L&LD]

When searching for "vis-dcon triggered out of memory codition (oom killer not called)", seems like a reset fixes things for some.

When was the last time you did so on your router?

 

[RMerlin]

triggered out of memory codition

Your router ran out of memory.

 

[freddy2000]

By observing it for a couple of days. I report back the findings: with server running 386.12.2, if one of the client tunnels is dead, maybe due to bad mobile signal, the server turns this client to UNDEF. After this ALL the tunnels freeze up and all the connected client apps turn into connecting. No new client can make connection. The server will remain in this state forever until reboot. If I disconnect the connected client or even power off the device, the server still thinks it's connected. It looks like the server is stuck in a dead loop to resolve the UNDEF client.

With the previous versions of firmware, if one of the clients turns into UNDEF, the server automatically re-assigns a new tunnel IP to it and drops the UNDEF connection soon afterwards.

I cannot see I can do anything on the server settings or the client settings to resolve this.

Just report back that I have managed to remotely(!) roll back to 386.12.0 from 386.12.2 by flashing the factory firmware onto 386.12.2 first. This solved my OpenVPN server frequently unresponding problem.