Release Asuswrt-Merlin 386.4 is now available

[EdoAsus]

Anything that creates a virtual interface could be the cause. I believe Transmission does this.

I understand that but something is wrong with TrendMicro on this release, I also tried a factory and hard reset of the router, installing everything from scratch, nothing changed. Im not happy if I have to disable either Transmission or TrendMicro, there must be a fix somewhere, I guess Asus has to do something.

 

[emwgee]

I have been having problems with some smart bulbs not being able to hold a steady connection on my 2.4gz radio after upgrading a AX88U router to merlin 386.4 or even factory 3.0.0.4.386.45934. However, after restoring 386.3, everything works fine. Does anyone know what changed in firmware update for the 2.4 GHZ WIFI radio?

Background:

I have 4 TP-LINK LB110 smart bulbs, one KL120, and a HS105 smart plug which have worked flawlessly up until 386.4. However, after upgrading from 386.3 to 386.4, all smart bulbs disconnect several times an hour with “wl0.1: STA MAC IEEE 802.11: disassociated“ and “wl0.1: MAC RADIUS: starting accounting session BCE13EF2E594CE5C” – “wl0.1: MAC WPA: pairwise key” in the system log. As a result, the smart bulbs frequently time out when trying to manage through the KASA app.

I have tried the following troubleshooting steps with no success other than reverting to 386.3 where everything works stable.

1) Problem starting after upgrading router from 386.3 to 386.4 Beta 3 (dirty upgrade, not a full reset). Tried following steps no success:

• Hard resetting bulbs to factory defaults and rejoining guest network.
• Uninstalled several plugins including Skynet, Diversion, YAZI (bulbs were in isolated Guest network).
• Disabled WIFI 6 on 2.4 GHZ radio, changed channel (thought maybe too many conflicts), reduced channel bandwidth to 20 MHZ, ensure WIFI security still WPA 2 for guest, disabled protected frame management, disabled universal beam forming.
• Tried lowering RTS threshold.

2) Upgraded 386.4 BETA 3 to 384.4 final and problems persisted.
3) Did a hard reset on router and re-uploaded 386.4 firmware and still no luck.
4) Did hard rest on router again and did a clean upload of ASUA factory 3.0.0.4.386.45934 and problems persisted.
5) Hard rest router with clean install of Merlin 386.3 and problems went away.
6) The issues returned as soon as I upgraded to 386.4 again.
7) Did dirty downgrade back to 386.3 and all the problems went away. Bulbs are rock solid.

Given the only WIFI clients that seem to be experiencing issues with 386.4 are the bulbs, I was leaning towards an issue with the bulbs that did not get exposed until the latest firmware update. Note I also have two TP-LINK HS200 switches that did not experience any problems (I’m guessing they use different wireless chips). However, it seems like this is a problem isolated between those bulbs and the AX88U as I installed all the same bulbs at my mother’s house, and she has no problem running factory firmware 3.0.0.4.386.45934. I would like to see if TPLINK would be willing to do anything, but I suspect they will point their finger back at the router.

Hi,

I also have similar problems after upgrading my GT-AX11000 to Merlin 386.4, while version 386.3_2 runs smoothly without a glitch.

The TP-Link smart bulbs, switches and plugs started to disconnect and re-connect from the 2.4 wifi network randomly after the router being upgraded to version 386.4.
I noticed from the wireless log that the P flag (Powersave mode) goes on and off randomly with all the TP-Link devices, whenever the P flag is ON, that particular device is disconnected.
I fall back to 386.3_2 and check the wireless log, the P flag never comes on and the devices had no connection problems at all.
Anyone has any ideas if there is a router setting that will stop activating the Powersave feature of the

devices?

 

[Tech9]

Anyone has any ideas if there is a router setting that will stop activating the Powersave feature

The only Power Save related setting is in Wireless -> Professional:

Enable WMM APSD - set it to Disable for 2.4GHz and test again.

APSD - Automatic Power Save Delivery

 

[learning_curve]

You need to upgrade and reset now. We are on 386 already.

What's an early morning typo between friends? I've edited it....

 

[emwgee]

The only Power Save related setting is in Wireless -> Professional:

Enable WMM APSD - set it to Disable for 2.4GHz and test again.

APSD - Automatic Power Save Delivery

I tried, makes no difference.

Thanks anyway.

 

[JohnSmith]

I did a dirty upgrade from 386.3_2 on my AX88U. Everything seems fine apart from one message that keeps popping up in the syslog:

Jan  3 14:48:57 kernel: potentially unexpected fatal signal 11.
Jan  3 14:48:57 kernel: CPU: 1 PID: 17082 Comm: dcd Tainted: P           O    4.1.51 #2
Jan  3 14:48:57 kernel: Hardware name: Broadcom-v8A (DT)
Jan  3 14:48:57 kernel: task: ffffffc02f0f2140 ti: ffffffc01c524000 task.ti: ffffffc01c524000
Jan  3 14:48:57 kernel: PC is at 0xf6fb739c
Jan  3 14:48:57 kernel: LR is at 0x1dd14
Jan  3 14:48:57 kernel: pc : [<00000000f6fb739c>] lr : [<000000000001dd14>] pstate: 600f0010
Jan  3 14:48:57 kernel: sp : 00000000fff33468
Jan  3 14:48:57 kernel: x12: 00000000000a2050
Jan  3 14:48:57 kernel: x11: 00000000f62ff024 x10: 00000000000a23c4
Jan  3 14:48:57 kernel: x9 : 00000000f62ff850 x8 : 00000000000a287c
Jan  3 14:48:57 kernel: x7 : 00000000f62ff888 x6 : 00000000000a2876
Jan  3 14:48:57 kernel: x5 : 0000000000000000 x4 : 00000000f62ff834
Jan  3 14:48:57 kernel: x3 : 0000000000000000 x2 : 00000000fff33444
Jan  3 14:48:57 kernel: x1 : 000000000007d75a x0 : 0000000000000000

I couldn't really find a lot of information about this issue, apart from "dcd" being closed source from Asus and that the problem can just go away.
Good job on the latest release Mr. Merlin

I also did a dirty upgrade from V386.3_2 on my AX88U, and got a similar message, but only once (router has only been up for 1 Day and 4 hours later, so still monitoring, but otherwise appears to be working properly):

Jan  2 13:50:07 kernel: CPU: 1 PID: 3568 Comm: dcd Tainted: P           O    4.1.51 #2
Jan  2 13:50:07 kernel: Hardware name: Broadcom-v8A (DT)
Jan  2 13:50:07 kernel: task: ffffffc03ebc1440 ti: ffffffc02a758000 task.ti: ffffffc02a758000
Jan  2 13:50:07 kernel: PC is at 0x29d68
Jan  2 13:50:07 kernel: LR is at 0x29fe8
Jan  2 13:50:07 kernel: pc : [<0000000000029d68>] lr : [<0000000000029fe8>] pstate: 20070010
Jan  2 13:50:07 kernel: sp : 00000000ffa7a720
Jan  2 13:50:07 kernel: x12: 00000000000a211c
Jan  2 13:50:07 kernel: x11: 0000000000081d94 x10: 000000000000000c
Jan  2 13:50:07 kernel: x9 : 0000000000000003 x8 : 000000000000000c
Jan  2 13:50:07 kernel: x7 : 00000000f5d00bc0 x6 : 0000000000000035
Jan  2 13:50:07 kernel: x5 : 00000000000000b1 x4 : 00000000f5d00c20
Jan  2 13:50:07 kernel: x3 : 0000000000000000 x2 : 000000000000000b
Jan  2 13:50:07 kernel: x1 : 0000000000000010 x0 : 0000000000000000

 

[Tech9]

I tried, makes no difference.

Sorry. No smart bulbs on wifi in my house. Regulars bulbs and smart wife only.

 

[slayerking]

Tried updating to 386.4 from 386.3_2 again on my AX88U and ran into the same problems as before, HTTPS warning, No internet, pages not loading with server can't be found message. Wifi not connected/no internet messages on all devices. Updating Arch linux get constant server can't be found trying to install or update. Logged into router with 386.4 on it to see what was going on and the pages were a complete mess, reset and reboot did nothing, putting it back to 386.3_2 fixed the lot.

 

[brself2]

Hi,

I also have similar problems after upgrading my GT-AX11000 to Merlin 386.4, while version 386.3_2 runs smoothly without a glitch.

The TP-Link smart bulbs, switches and plugs started to disconnect and re-connect from the 2.4 wifi network randomly after the router being upgraded to version 386.4.
I noticed from the wireless log that the P flag (Powersave mode) goes on and off randomly with all the TP-Link devices, whenever the P flag is ON, that particular device is disconnected.
I fall back to 386.3_2 and check the wireless log, the P flag never comes on and the devices had no connection problems at all.
Anyone has any ideas if there is a router setting that will stop activating the Powersave feature of the View attachment 38226devices?

I’m having the same problem with my two TP-Link devices (light and plug). I’m curious if there is a solution. I retired them for now.

General question, should I check the 2.4 ghz “Disable 11b, does that make any differenc?

 

[RMerlin]

The simplest workaround was to delete one by one ALL users (until only the renamed admin remains, the one that can't be deleted), Apply that and then new users can be added (including the old users that were present before).

The bug is actually in previous versions that would double-encrypt the passwords, leading to corrupted accounts. 386.4 now correctly handles it, however already corrupted users have to be removed and re-created.

 

[IshWishDish]

I have a 5300 and when I attempt to flash, I just get the Applying Settings pop-up, but nothing ever moves. I've left it go for 10mins or more, twice. I've downloaded it from the main site (Sourceforge) and a backup site and tried both files... and tried 3 different browsers.
Any idea what could be happening, and is there an alternative way to update the flash outside of the GUI?

 

[banger]

I had a similar problem with my smart bulbs.... are your bridges connecting on the 2.4ghz band? If so, check out the system log and see if they are continually connecting and reconnecting.

For me, the problem resides in both 386.4 as well as ASUS's latest factory GPL. Seems like there may be a bug in the GPL.

I had problems with stock and P100 Tapo devices. If I switched off DNSoverTLS on stock they would reconnect but changing back to TLS they would go MIA after 24 hours. Haven't experienced this with Merlin's 386.4. Maybe a red herring but have you checked DNS over TLS setting or tried them off?

 

[BikeHelmet]

I've had problems with my OnePlus 6 recently as well, but _not_ on 386.4. Instead on 386.2_6 and only after I switched channels / frequency and _also_ changed to WPA2/3 personal.

Not sure which of the changes did that.

FYI.

I have found WPA3 mode to be glitchy with a wide variety of devices. I currently stick with WPA2 / AES only.

For WiFi, I added a TP-Link EAP245v3 - no AX, but very strong AC and 2.4ghz WiFi on it. They're often on sale for ~$70. Cheap fix with great compatibility across devices, at least in my experience so far. I figured older battle tested equipment would beat the new experimental stuff. Though for my router, I can't resist dabbling.

I've mentioned this behavior already in the beta 1 : http://www.snbforums.com/threads/386-4-alpha-build-s-testing-available-build-s.74186/post-726257
Fun fact: i already used your great script scMerlin there to restart DNS/DHCP Server (dnsmasq) and fly Sidenote I tried to install ( for Fun) Plex on the router and ran in some more of these Tainted hiccups. After a clean install with this final build the Tainted hiccups are still there. I just go over to your script and click It doesn't border me that much, as i don't think its critical. But i can be wrong cause I'm not that technical. You both create great user friendly software!

Plex goes on my Synology NAS. Right tool for the right job. Around Black Friday some of theirs were dipping into the $200-350 range. (DS220+ and DS920+) Very reasonable. I have old drives laying around, so it was a no-brainer.

Edit: I try to keep my router doing router-stuff only. It can port forward, but media... video... file serving... that goes on a NAS. I want my router to have months and months of uptime. I have found that a lot of addons, while cool, become problematic or leak memory, compromising stability.

 

[arewhy]

Did a factory reset and manual reconfig of the main router and the two AiMesh nodes after flashing with 386.4

Everything seemed fine up until this morning. I noticed that the AiMesh node, connected via wifi, had moved from the 5 GHz-2 Dedicated Wifi Backhaul (DWB) to 5 GHz-1. When I look at the wireless log it shows the channel to be 136u even though I have the control channel set to 100 vice auto. Is 136u a valid channel? I manually set the control channel because as I’ve mentioned in the alpha & beta threads, unchecking “Auto select channel including DFS channels” is not persistent for the 5 GHz-2 band. I uncheck the box and after hitting apply the checkmark comes back after the page refreshes. Hopefully this is not a hardware issue with the 3rd radio. I’ll continue to monitor and may try ASUS firmware if I continue to have issues with the AiMesh remaining connected to the DWB. It would be a shame to have a tri-band router if the DWB essentially does not consistently get utilized

 

[GHammer]

I had a similar problem with my smart bulbs.... are your bridges connecting on the 2.4ghz band? If so, check out the system log and see if they are continually connecting and reconnecting.

For me, the problem resides in both 386.4 as well as ASUS's latest factory GPL. Seems like there may be a bug in the GPL.

I had this very issue with TP-Link smart plugs on beta 1 with an AX58, I also have an AX86 so I put it in service and have not seen the constant connect, get a DHCP address, disconnect cycle. These were running about every 60 seconds give or take 5.
Don't know that it was limited to the 58 or to beta 1 as I swapped APs and upgraded to b2 at the same time.
after reading this thread, I'm hesitant to go from b3 to release.

 

[shabbs]

Hi,

I also have similar problems after upgrading my GT-AX11000 to Merlin 386.4, while version 386.3_2 runs smoothly without a glitch.

The TP-Link smart bulbs, switches and plugs started to disconnect and re-connect from the 2.4 wifi network randomly after the router being upgraded to version 386.4.
I noticed from the wireless log that the P flag (Powersave mode) goes on and off randomly with all the TP-Link devices, whenever the P flag is ON, that particular device is disconnected.
I fall back to 386.3_2 and check the wireless log, the P flag never comes on and the devices had no connection problems at all.
Anyone has any ideas if there is a router setting that will stop activating the Powersave feature of the View attachment 38226devices?

Interesting. I observed some stability issues with all my Nest Cameras (2.4Ghz). Following the upgrade, they would disconnect and reconnect regularly. Were not able to keep a steady feed. Rolled back to previous release and stability returned. Did not have time to triage much. I plan on re-attempt again later this week when there's time and doing a full reset and reconfigure. But I also observed the P status flag on the 2.4Ghz cams that were going in and out.

 

[MarWell]

After the updating my RT-AX86U I'm having one issue. My OpenVPN Client (have tested 3 different VPN Providers) , are leaking my ISP DNS, having the DNS Configuration with Strict, and in WAN have automatic set DNS Servers. This same configuration wasn't leaking in the previous build. Dont know if I just do a Factory Reset or go back to previous build? Any one with this issue or anyway to fix it?

 

[AlbumMan]

I have been having problems with some smart bulbs not being able to hold a steady connection on my 2.4gz radio after upgrading a AX88U router to merlin 386.4 or even factory 3.0.0.4.386.45934. However, after restoring 386.3, everything works fine. Does anyone know what changed in firmware update for the 2.4 GHZ WIFI radio?

Background:

I have 4 TP-LINK LB110 smart bulbs, one KL120, and a HS105 smart plug which have worked flawlessly up until 386.4. However, after upgrading from 386.3 to 386.4, all smart bulbs disconnect several times an hour with “wl0.1: STA MAC IEEE 802.11: disassociated“ and “wl0.1: MAC RADIUS: starting accounting session BCE13EF2E594CE5C” – “wl0.1: MAC WPA: pairwise key” in the system log. As a result, the smart bulbs frequently time out when trying to manage through the KASA app.

I have tried the following troubleshooting steps with no success other than reverting to 386.3 where everything works stable.

1) Problem starting after upgrading router from 386.3 to 386.4 Beta 3 (dirty upgrade, not a full reset). Tried following steps no success:

• Hard resetting bulbs to factory defaults and rejoining guest network.
• Uninstalled several plugins including Skynet, Diversion, YAZI (bulbs were in isolated Guest network).
• Disabled WIFI 6 on 2.4 GHZ radio, changed channel (thought maybe too many conflicts), reduced channel bandwidth to 20 MHZ, ensure WIFI security still WPA 2 for guest, disabled protected frame management, disabled universal beam forming.
• Tried lowering RTS threshold.

2) Upgraded 386.4 BETA 3 to 384.4 final and problems persisted.
3) Did a hard reset on router and re-uploaded 386.4 firmware and still no luck.
4) Did hard rest on router again and did a clean upload of ASUA factory 3.0.0.4.386.45934 and problems persisted.
5) Hard rest router with clean install of Merlin 386.3 and problems went away.
6) The issues returned as soon as I upgraded to 386.4 again.
7) Did dirty downgrade back to 386.3 and all the problems went away. Bulbs are rock solid.

Given the only WIFI clients that seem to be experiencing issues with 386.4 are the bulbs, I was leaning towards an issue with the bulbs that did not get exposed until the latest firmware update. Note I also have two TP-LINK HS200 switches that did not experience any problems (I’m guessing they use different wireless chips). However, it seems like this is a problem isolated between those bulbs and the AX88U as I installed all the same bulbs at my mother’s house, and she has no problem running factory firmware 3.0.0.4.386.45934. I would like to see if TPLINK would be willing to do anything, but I suspect they will point their finger back at the router.

If your 2.4 devices are mostly all G, change the Wireless Mode to Legacy. I had issues even before 386.3 with my thermostat and weather station randomly dropping and this cured it.

 

[BlackIce]

After the updating my RT-AX86U I'm having one issue. My OpenVPN Client (have tested 3 different VPN Providers) , are leaking my ISP DNS, having the DNS Configuration with Strict, and in WAN have automatic set DNS Servers. This same configuration wasn't leaking in the previous build. Dont know if I just do a Factory Reset or go back to previous build? Any one with this issue or anyway to fix it?

Yes...I discovered the same issue during the betas....I had to change the DNS Configuration to EXCLUSIVE, with WAN set to automatic DNS Servers. This will pull the DNS from your VPN Provider only and resolved my DNS leak (with Surfshark)...You're right this wasn't necessary with 386.3_2.

 

[fearz]

Good Morning, updated my RT-AC5300 just now to 386.4 and now I have a Chinese option in the main menu. I do not know what it is and wondering how to get rid of it?

Here is what I am seeing now:

https://imgur.com/a/a8GMNPI

Hey

how did you get “Game” and “OpenNAT” to show on your RTAC-5300? I dont have them..