Release Asuswrt-Merlin 386.4 is now available

[Argothar]

Upgraded my RT-AX86U from 386.3_2 to 386.4 and my old laptop (802.11n wifi controller) couldn't find wife (2.4 Ghz) anymore. Our other devices could still find both 2.4 and 5 Ghz bands. After downgrading to 386.3_2 my old laptop once again found the 2.4 Ghz band again.

 

[BreakingDad]

I posted in the beta3 forum -
I'm not sure what information you need - RT-AX88U
I run 386.4_alpha2-ga85421da82 - works great
I've updated last month to a newer beta version - both WAN ports show disconnected. Reverted back to alpha.

I run a 9/1 dual WAN balance.

I just attempted to upgrade to 386.4 - went back to both WAN ports "disconnected".

I did a factory reset via the Administration - Restore/Save/Upload Setting - set up wireless - set up Dual WAN load balance 9/1 - was okay for one reboot/config change.

Changed IP router to something other than 50.1 - back to the above (both WAN's disconnected) - uggg!

I downgraded back to the alpha version linked above and restored my previous config - back to normal.

I will add logs if requested. I'm not great in Linux so tell me what to terminal.

Updated at 3am this morning, works fine until I load my previous settings, then I get "disconnected" and can't connect to internet. Based on your experience I am now wondering if this is due to me using the old ip 192.168.1.1 After playing around until 5am I gave up and restored the same alpha as you, reloaded settings all good.

Also wondering if this is related?
"Merlin"
1) Your router has working nameservers. That means on the WAN page you need to have DNS set to either automatic, or having at least one valid DNS configured. People who leave it to manual and keep both DNS1 and DNS2 empty will have issues - you MUST have at least one valid DNS configured


I need a whole day to look into it and possibly re do all my settings manually.

 

[ColinTaylor]

Updated at 3am this morning, works fine until I load my previous settings...

You shouldn't be reloading settings from alpha2. There have been significant changes internally since then.

 

[maxbraketorque]

Try as I might, I can't update my remote AX86U... Had this with 384.6Beta1 as well.

This morning I updated my home router (AX88U) and AiMesh nodes (AX58u's) from various 384.6 betas to 384.6 release.
All went fine, everything running well!
I was at the remote site last week and updated the AX86U (locally) to 386.4 beta 2.

This morning, I tried to update remotely to 386.4 release. It just sits on the "Please wait, Applying Settings..." page and never moves to the bar graph.
I waited for 10 mins or more then did a refresh and I am back at the Admin/Firmware page.

I did a few things, nothing helped:
1) Disabled Jffs custom scripts and configs - then did a reboot. No change.
2) Disabled OpenVPN Server, did a reboot - No change.

I then SSH'd into the remote router and did a tail -f /tmp/syslog.log

Tried the update - no activity in syslog.log.

I tried 2 different Web browsers (Firefox and Edge).

I guess I will have to update when I get back to the remote site...

How are the remote router and your computer connected to the internet? My experience at this point is that the ability to remote update is very dependent on the client computer internet connection. The remote AX68U I mentioned recently is in Thailand, and when attempting to apply remote updates via OVPN from my computer in Thailand, I had hit-and-miss success depending on internet connection quality. Surprisingly, I have zero issues applying a remote update to the AX68U via OVPN using a computer in the USA. It may help if the computer applying the update is wired to the internet rather than connecting via wifi. It may also help to reboot the remote router just prior to applying the update.

 

[Jeffrey Young]

Upgraded my RT-AX86U from 386.3_2 to 386.4 and my old laptop (802.11n wifi controller) couldn't find wife (2.4 Ghz) anymore. Our other devices could still find both 2.4 and 5 Ghz bands. After downgrading to 386.3_2 my old laptop once again found the 2.4 Ghz band again.

Windows / Mac's store a lot of information about the wireless networks they attach to. Try forgetting the network on your wife's laptop and try to reconnect. That has often solved issues for me in the past. Especially when wireless drivers on the router have changed.

 

[wpte]

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

 

[Volt]

Installed 386.4 on RT-AX56U and performed a factory reset. The configuration is pretty basic, no scripts, etc. When I turn on Adaptive QOS, I get the following error that constantly occurs after about an hour after a client leaves the network (for example, if I turn off WiFi on my smartphone, this error occurs exactly one hour later). If I turn off Adaptive QOS, the error never appears.

Jan  3 15:37:31 kernel: ------------[ cut here ]------------
Jan  3 15:37:31 kernel: WARNING: CPU: 1 PID: 5464 at net/sched/sch_htb.c:568 htb_qlen_notify+0x6c/0x70()
Jan  3 15:37:31 kernel: Modules linked in: tdts_udbfw(O) init_addr(  (null) -   (null)), core_addr(bf0aa000 - bf0aedd8)
Jan  3 15:37:31 kernel:  tdts_udb(PO) init_addr(  (null) -   (null)), core_addr(bf22b000 - bf249a34)
Jan  3 15:37:31 kernel:  tdts(PO) init_addr(  (null) -   (null)), core_addr(bfc09000 - bfc43790)
.......
.......
Jan  3 15:37:31 kernel:  [last unloaded: nf_conntrack_ftp]
Jan  3 15:37:31 kernel: CPU: 1 PID: 5464 Comm: tc Tainted: P        W  O    4.1.52 #2
Jan  3 15:37:31 kernel: Hardware name: Generic DT based system
Jan  3 15:37:31 kernel: [<c0026e60>] (unwind_backtrace) from [<c0022c38>] (show_stack+0x10/0x14)
Jan  3 15:37:31 kernel: [<c0022c38>] (show_stack) from [<c047cda4>] (dump_stack+0x8c/0xa0)
.......
.......
Jan  3 15:37:31 kernel: ---[ end trace 85e329579133a81b ]---

BTW, I see them on the stock firmware too. Does anyone else have such messages in the log? Is it normal?

 

[ColinTaylor]

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

Known issue. Most commonly caused by pixelserv-tls.

 

[Jack Yaz]

OK so, it only happens when service-event-end exists for me, even if it is empty. I found this by removing service-event openvpn-event and service-event-end and tested with each 1 at a time and restarting the vpn client. Very puzzling

@RMerlin are you aware of any interaction with dnsmasq/openvpn and service-event-end , even when the latter is an empty file (by emptying I mean a shebang and nothing else)?

actually still happens, albeit less frequently, without service-event-end

 

[Yooshaw]

Known issue. Most commonly caused by pixelserv-tls.

I'm not the OP. but I'm seeing the same messages. I don't have pixelserv-tls running, though I have in the past. There doesn't seem to be any adverse affects to the router though, just these message every 30 min or so.

 

[octopus]

actually still happens, albeit less frequently, without service-event-end

Maby same issue I have with update-notification not get executed after detected 384 final. (Exclemation mark blink) Working fine manual.

 

[ElmerFudd]

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.

 

[EdoAsus]

Thanks RMerlin. Just for completeness sake I'm posting the log entries I am getting in case you or someone can see something that would eventually allow Pixelsrv-tls.

Jan 2 18:53:05 kernel: potentially unexpected fatal signal 11.
Jan 2 18:53:05 kernel: CPU: 1 PID: 8553 Comm: dcd Tainted: P O 4.1.51 #2
Jan 2 18:53:05 kernel: Hardware name: Broadcom-v8A (DT)
Jan 2 18:53:05 kernel: task: ffffffc02b2f6b80 ti: ffffffc02efd8000 task.ti: ffffffc02efd8000
Jan 2 18:53:05 kernel: PC is at 0xf6d8339c
Jan 2 18:53:05 kernel: LR is at 0x1dd14
Jan 2 18:53:05 kernel: pc : [<00000000f6d8339c>] lr : [<000000000001dd14>] pstate: 600f0010
Jan 2 18:53:05 kernel: sp : 00000000fff7a6b8
Jan 2 18:53:05 kernel: x12: 00000000000a2050
Jan 2 18:53:05 kernel: x11: 00000000f60ff024 x10: 00000000000a23c4
Jan 2 18:53:05 kernel: x9 : 00000000f60ff924 x8 : 00000000000a287c
Jan 2 18:53:05 kernel: x7 : 00000000f60ff95c x6 : 00000000000a2876
Jan 2 18:53:05 kernel: x5 : 0000000000000000 x4 : 00000000f60ff908
Jan 2 18:53:05 kernel: x3 : 0000000000000000 x2 : 00000000fff7a694
Jan 2 18:53:05 kernel: x1 : 000000000007d75a x0 : 0000000000000000
Jan 2 18:56:46 hostapd: eth6: STA f4:ce:46:66:b0:3a WPA: group key handshake completed (RSN)
Jan 2 18:56:46 hostapd: eth6: STA 18:d2:76:bb:f9:31 WPA: group key handshake completed (RSN)

Hi I have the same problem with this log entries since 386.4 (RT-AX88U), but I don't have Diversion and Pixelsrv-tls installed, I have instead Entware + Transmission installed with OpenVPN only for torrent traffic, I dont know what it's causing TrendMicro to crash, so seems there are other addon's involved not just Pixelsrv-tls.
With the previous release 386.3_2 no problems.
Anywhay thanks Merlin for the big effort on making this release.

 

[Yooshaw]

Installed 386.4 on RT-AX56U and performed a factory reset. The configuration is pretty basic, no scripts, etc. However, when I turn on Adaptive QOS, I get the following error that constantly occurs after about an hour after a client leaves the network (for example, if I turn off WiFi on my smartphone, this error occurs exactly one hour later). If I turn off Adaptive QOS, the error never appears.

Jan  3 15:37:31 kernel: ------------[ cut here ]------------
Jan  3 15:37:31 kernel: WARNING: CPU: 1 PID: 5464 at net/sched/sch_htb.c:568 htb_qlen_notify+0x6c/0x70()
Jan  3 15:37:31 kernel: Modules linked in: tdts_udbfw(O) init_addr(  (null) -   (null)), core_addr(bf0aa000 - bf0aedd8)
Jan  3 15:37:31 kernel:  tdts_udb(PO) init_addr(  (null) -   (null)), core_addr(bf22b000 - bf249a34)
Jan  3 15:37:31 kernel:  tdts(PO) init_addr(  (null) -   (null)), core_addr(bfc09000 - bfc43790)
.......
.......
Jan  3 15:37:31 kernel:  [last unloaded: nf_conntrack_ftp]
Jan  3 15:37:31 kernel: CPU: 1 PID: 5464 Comm: tc Tainted: P        W  O    4.1.52 #2
Jan  3 15:37:31 kernel: Hardware name: Generic DT based system
Jan  3 15:37:31 kernel: [<c0026e60>] (unwind_backtrace) from [<c0022c38>] (show_stack+0x10/0x14)
Jan  3 15:37:31 kernel: [<c0022c38>] (show_stack) from [<c047cda4>] (dump_stack+0x8c/0xa0)
.......
.......
Jan  3 15:37:31 kernel: ---[ end trace 85e329579133a81b ]---

BTW, I see them on the stock firmware too. Does anyone else have such messages in the log? Is it normal?

I'm seeing the same issue, shows up in logs every 30 min or so. I don't have Diversion or PixelServ running.

 

[Deleted member 66328]

Updated at 3am this morning, works fine until I load my previous settings, then I get "disconnected" and can't connect to internet. Based on your experience I am now wondering if this is due to me using the old ip 192.168.1.1 After playing around until 5am I gave up and restored the same alpha as you, reloaded settings all good.

Also wondering if this is related?
"Merlin"
1) Your router has working nameservers. That means on the WAN page you need to have DNS set to either automatic, or having at least one valid DNS configured. People who leave it to manual and keep both DNS1 and DNS2 empty will have issues - you MUST have at least one valid DNS configured


I need a whole day to look into it and possibly re do all my settings manually.

You may want to check WAN / Dual WAN (or the other location if not dual WAN - “Network monitoring” and make sure it’s not on Ping Query and is on DNS query. That resolved my issue.

 

[ColinTaylor]

I'm not the OP. but I'm seeing the same messages. I don't have pixelserv-tls running, though I have in the past. There doesn't seem to be any adverse affects to the router though, just these message every 30 min or so.

I'm seeing the same issue, shows up in logs every 30 min or so. I don't have Diversion or PixelServ running.

These are two different problems. Are you experiencing both?

 

[ColinTaylor]

Hi I have the same problem with this log entries since 386.4 (RT-AX88U), but I don't have Diversion and Pixelsrv-tls installed, I have instead Entware + Transmission installed with OpenVPN only for torrent traffic, I dont know what it's causing TrendMicro to crash, so seems there are other addon's involved not just Pixelsrv-tls.
With the previous release 386.3_2 no problems.
Anywhay thanks Merlin for the big effort on making this release.

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

 

[JIPG]

View attachment 38197

Load average is high - no ?

Yes, at least for me, it was around 1.9% in the past, until I installed FW 386.4, and now I have similar numbers to yours (I check frequently the CPU load after I had a recurrent problem with my previous router RT-AC87U, that from time to time had the CPU throttled continously at 100%).

 

[Spc]

As discussed before, new versions have space restrictions in wifi passwords, space is no longer allowed in wifi passwords.
New version more restrictions.

I'll test other functions and report back.
Thanks for new release in a long time.

Happy new year everyone.

 

[cptnoblivious]

I did try a few since I also received this suggestion on OnePlus forum but it did not help. I also forced the channel (56) as it was during my initial speedtests but no luck. I haven't tried switching off AX mode yet but that was also enabled from the beginning.

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.