ASUS RT-AC86U Firmware version 3.0.0.4.384_81049

[tornor]

No, just upgraded both nodes from 81039 using the app, I'll give your advice a try, thanks.

 

[CriticJay]

Thank god. I didn't update it. I am the winner again!

Why would you say that? It sounds like they've fixed the most egregious problems from the previous firmware release.

 

[Zardoz]

It doesn't appear to have fixed issues with both the 2.4G and 5G bands dropping and reappearing.
WiFi flakiness is a serious problem for me with these routers. 2xAC86U in a 5G linked AiMesh configuration.

 

[Smedley]

WLCEVENTD errors are spamming the log.

I'm running my RT-AC86U as an access point, and with version 81049 my log is filled with Auth/Assoc/Disassoc messages, as well:

Sep 5 19:45:15 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth6: Auth XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)
Sep 5 19:45:15 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth6: Assoc XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)
Sep 5 19:45:28 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth6: Auth XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)
Sep 5 19:45:28 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth6: Assoc XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)
Sep 5 19:45:31 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth6: Disassoc XX:XX:XX:XX:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep 5 19:49:24 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth6: Auth XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)
Sep 5 19:49:24 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth6: Assoc XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)
Sep 5 19:49:44 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth6: Auth XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)
Sep 5 19:49:44 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth6: Assoc XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)

I reverted back to 45717 and the log is quiet.

 

[tallytr]

3.0.0.4.384_81049 works well for me. Simply upgraded firmware and power-cycled router afterwards, everything good, some entries in the general log but I don't care...

 

[VANT]

after two times factory default and readding for nodes, changed some wifi settings, my 86u work ok with 68u node. No continous WLCEVENTD for node.

 

[ryan806]

It doesn't appear to have fixed issues with both the 2.4G and 5G bands dropping and reappearing.
WiFi flakiness is a serious problem for me with these routers. 2xAC86U in a 5G linked AiMesh configuration.

I've also been experiencing this issue, any recommendations?

 

[VANT]

I've also been experiencing this issue, any recommendations?

Try disable Auto for Control Channel, and set fixed channel number.

 

[ryan806]

Try disable Auto for Control Channel, and set fixed channel number.

Thanks I will try that and let you know.

 

[OgUrecheK]

It is hoped to support WireGuard?

 

[OzarkEdge]

after two times factory default and readding for nodes, changed some wifi settings, my 86u work ok with 68u node. No continous WLCEVENTD for node.

That's good news.

Do you think the WiFi setting changes were a factor in the node connectivity? By AiMesh design, this should be Auto(matically) managed.

I assume you still have WLCEVENTD for other wireless clients. Some users call it log spam, some don't care about it, and some fear it and downgrade... and some bash ASUS for it.

OE

 

[OzarkEdge]

2 RT-AC66U B1s. 1 router and 1 mesh node. Router was not reset when 81049 was installed, but the mesh node was reset and re-added. My test client is a PC with a PCE-AC88 . I was running a ping tester against the router, the mesh node, and an external internet address.

At 8:34 am today the ping tester reported all pings failing after running error free for almost a full day. This was due to all clients currently attached to the mesh node were forcibly detached. The clients then flipped back to the router, leaving exactly 0 attached to the mesh node.

This is an extract from the mesh node log (not the router log):

Sep 7 07:01:43 acsd: scan in progress ...
Sep 7 07:01:43 acsd: scan in progress ...
Sep 7 07:01:43 acsd: scan in progress ...
Sep 7 08:34:46 syslog: WLCEVENTD wlceventd_proc_event(386): wl0.1: Deauth_ind 01:10:00:00:00:00, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Sep 7 08:34:46 syslog: WLCEVENTD wlceventd_proc_event(386): wl1.1: Deauth_ind 2C:FD:A1:CD:C4:E7, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Sep 7 08:35:57 rc_service: amas_wlcconnect 287:notify_rc restart_wireless
Sep 7 08:36:01 rc_service: watchdog 260:notify_rc start_amas_bhctrl
Sep 7 08:36:01 rc_service: waitting "restart_wireless" via ...
Sep 7 08:36:01 kernel: dpsta enabled, uif_bmap 0x3
Sep 7 08:36:02 acsd: scan in progress ...
Sep 7 08:36:02 acsd: scan in progress ...
Sep 7 08:36:02 acsd: scan in progress ...

2C:FD:A1:CD:C4:E7 is my PCE-AC88 client. After the 3 clients attached to the node all flipped over to the router, pings were restored at 8:36 am.

This is pretty close to the same symptom I was getting on previous releases. The log entries are a bit different but clients on the node being forced to randomly disconnect is not. The mesh node runs fine for up to 48 hours and then randomly blows off all the clients.

I happen to have a 3rd spare RT-AC66U B1 and in the past have tried swapping the boxes around in different combinations with zero impact on the disconnects. Also note the disconnects never happen when I run router only. By itself the router is flawlessly reliable. The disconnects only happen to clients attached to the mesh node.

The node and router are only about 25-30 feet apart (a couple of walls) and everything shows strong signals. My test client is only about 20 feet from the mesh node and also shows a strong signal.

So the result is the same. The ASUS mesh setup still remains unusable almost exactly 1 year after I bought the boxes hoping to fix a dead spot in the basement with a mesh.

Why are you posting in an 86U thread? Do you have an 86U in your network?

I would reset all units after upgrading to 81049, and then configure minimally until the network has run reliably for some time.

The acsd scanning suggests you are using Auto channel selection and may have excessive channel changing. I would try fixed channels for both bands. I assume you are using separate SSIDs for each band.

OE

 

[VANT]

That's good news.

Do you think the WiFi setting changes were a factor in the node connectivity? By AiMesh design, this should be Auto(matically) managed.

I assume you still have WLCEVENTD for other wireless clients. Some users call it log spam, some don't care about it, and some fear it and downgrade... and some bash ASUS for it.

OE

i make some changes in wifi settings and saved it. then, i think, this settings have been replicated on node.
I still have WLCEVENTD in syslog for rest my devices, but not continous like before (second by second). Now no WLCEVENTD for my node.

 

[jjrs]

Looks like they pulled the update, it's not on the site anymore.

I updated because I received the notification on my router but my VPN isn't working and my log is full of WLCEVENTD entries.

 

[OzarkEdge]

Looks like they pulled the update, it's not on the site anymore.

I updated because I received the notification on my router but my VPN isn't working and my log is full of WLCEVENTD entries.

Both links in post 1 still seem to be active.

OE

 

[jjrs]

Both links in post 1 still seem to be active.

OE

It's not publicly listed anymore: https://www.asus.com/us/Networking/RTAC68U/HelpDesk_BIOS/

There were two releases, one on the 4th and then again on the 5th, it appears that the firmware is buggy.

 

[OzarkEdge]

It's not publicly listed anymore: https://www.asus.com/us/Networking/RTAC68U/HelpDesk_BIOS/

There were two releases, one on the 4th and then again on the 5th, it appears that the firmware is buggy.

1. This thread is for 86U, not 68U.

2. The link you posted still lists 68U 81049 firmware for download.

I can't explain any date discrepancies, particularly for dates not there... but I can say that if the version hasn't changed, then the firmware hasn't changed... otherwise, God help asus all!

Edit: Also, the decision to pull suspect firmware chronologically precedes the posting of new firmware, typically by many days to allow for investigating the suspect firmware and for developing and testing the new firmware.

3. The log having entries and your VPN not working does not mean the firmware is buggy.

OE

 

[jjrs]

1. This thread is for 86U, not 68U.

2. The link you posted still lists 68U 81049 firmware for download.

I can't explain any date discrepancies, particularly for dates not there... but I can say that if the version hasn't changed, then the firmware hasn't changed... otherwise, God help asus all!

3. The log having entries and your VPN not working does not mean the firmware is buggy.

OE

My fault, there are four threads about this firmware, two for the 68u and two for the 86u. I posted in the wrong thread by mistake.

That link is not showing the firmwate on my end. I have tried it on multiple browsers and on my phone, the latest firmware I see is the one from May 13, 2019.

Anyway, thanks for your help, I'll take my post to the correct thread now.

 

[Pak Kriss]

Very similar here on a single, no mashed router.

Upload new FW.

Full reset to factory defaults.

Flooding of WLCEVENTD and client disconnects.

Investigation turned out Roaming Assistance is active with factory defaults.

Disabled Roaming Assistance for both bands in Wireless -> Professional tab.

No auto channel setup.

Now good

I'm running my RT-AC86U as an access point, and with version 81049 my log is filled with Auth/Assoc/Disassoc messages, as well:

Sep 5 19:45:15 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth6: Auth XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)
Sep 5 19:45:15 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth6: Assoc XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)
Sep 5 19:45:28 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth6: Auth XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)
Sep 5 19:45:28 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth6: Assoc XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)
Sep 5 19:45:31 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth6: Disassoc XX:XX:XX:XX:XX:XX, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep 5 19:49:24 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth6: Auth XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)
Sep 5 19:49:24 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth6: Assoc XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)
Sep 5 19:49:44 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth6: Auth XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)
Sep 5 19:49:44 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth6: Assoc XX:XX:XX:XX:XX:XX, status: 0, reason: d11 RC reserved (0)

I reverted back to 45717 and the log is quiet.

 

[OzarkEdge]

Very similar here.

Upload new FW.

Full reset to factory defaults.

Flooding of WLCEVENTD and client disconnects.

Investigation turned out Roaming Assistance is active with factory defaults.

Disabled Roaming Assistance for both bands in Wireless -> Professional tab.

No auto channel setup.

Now good

Smart Connect and/or Auto channels has caused excessive channel scanning and changing. I have not bothered to enable SC (forced Auto channels) to see if this still occurs in 81049... I think I prefer fixed channels. I should test it unless someone else can confirm, does Auto channels still scan/change channels excessively?

81039 and 81049 changed the Roaming Assistant RSSI threshold defaults... they are now both at -70 dB. Maybe this (and associated firmware changes) and node placement (range overlap) are behind the spat of logged WLCEVENTD and client disconnects for certain affected/located clients. I should try the old RA defaults of -55 and -70... some could try spreading their nodes farther apart(?).

Finally, without RA and SC working in a mesh system, what's the point?! I'm pretty sure excessive client disconnects and channel changing are not desirable behaviors. However, although I have the log entries note here, that client use seems unaffected.

OE