ASUS RT-AC86U Firmware version 3.0.0.4.384_81049

[OzarkEdge]

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.

There is typically one thread for each router/firmware combination. Seems to best organize related discussion.

OE

 

[Pak Kriss]

None-meshed, single router at my end, my friend

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.

OE

 

[OzarkEdge]

None-meshed, single router at my end, my friend

Then for your standalone use, disabling RA just means you don't get cut off... your client connection is allowed to drain down until usage chokes... I guess.

You could still benefit from Smart Connect if using the same SSID for both bands.

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

unfortunatelly WLCEVENTD is back for my node and 2.4HGz not work in this node.....

Stations List                           
----------------------------------------
idx MAC               Associated Authorized    RSSI PHY PSM SGI STBC MUBF NSS Tx rate Rx rate Connect Time
    2C:xx:A1:xx:69:xx Yes                      0dBm ac  No  Yes Yes  No     3      1M         00:00:08

 

[Pak Kriss]

5GHz serve with a separated SSID as a transport/backbone band for none-mobile devices with higher bandwidth and low latency needs.

BTW Smart Connect might be not smart enough if it's rely on RSSI only IMO - this could be a topic in an other thread.

Then for your standalone use, disabling RA just means you don't get cut off... your client connection is allowed to drain down until usage chokes... I guess.

You could still benefit from Smart Connect if using the same SSID for both bands.

OE

 

[OzarkEdge]

5GHz serve with a separated SSID as a transport/backbone band for none-mobile devices with higher bandwidth and low latency needs.

BTW Smart Connect might be not smart enough if it's rely on RSSI only IMO - this could be a topic in an other thread.

So, it sounds like you don't need RA nor SC... that simplifies things.

SC has the controls listed under Network Tools\Smart Connect Rule. Most of us users probably don't know what to do with them.

My notes have some links to related SC articles, if your interested.

OE

 

[tallytr]

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

In my case I simply upgraded and it left my Roaming Assistant settings untouched. I keep 2.4GHZ disconnect at lower than -55 dBm and 5GHz at -72, otherwise it switches clients to 2.4 GHz in our basement while 5 GHz is still much faster.....

 

[Pak Kriss]

I appreciate your feedback on the "Smart Connect Rule" tab and will look into this topic if it fits my scenario.

So, it sounds like you don't need RA nor SC... that simplifies things.

SC has the controls listed under Network Tools\Smart Connect Rule. Most of us users probably don't know what to do with them.

My notes have some links to related SC articles, if your interested.

OE

 

[OzarkEdge]

unfortunatelly WLCEVENTD is back for my node and 2.4HGz not work in this node.....

If you can fix it with a downgrade to 45717, then maybe firmware related. If not, then maybe a hardware issue. Given you are the only one reporting such an issue, I'm thinking it might be a hardware issue.

Maybe some 2018 86Us have something borderline going on hardware-wise that is killing some radios outright and dragging others through the mud. Are wireless clients connecting reliably to your 86U router.

Next, how does your 68U WiFi behave if you use it as your router? Maybe that would reveal the problem area.

OE

 

[podkaracz]

Im curious if merlin firmware is better than official one when it comes to stability, beeing bug free after many ups and downs with latest firmware 81049 and 45717 beeing stable ill try merlin 384.13

 

[OzarkEdge]

Im curious if merlin firmware is better than official one when it comes to stability, beeing bug free after many ups and downs with latest firmware 81049 and 45717 beeing stable ill try merlin 384.13

You should ask users in the Asuswrt-Merlin forum.

OE

 

[VANT]

If you can fix it with a downgrade to 45717, then maybe firmware related. If not, then maybe a hardware issue. Given you are the only one reporting such an issue, I'm thinking it might be a hardware issue.

Maybe some 2018 86Us have something borderline going on hardware-wise that is killing some radios outright and dragging others through the mud. Are wireless clients connecting reliably to your 86U router.

Next, how does your 68U WiFi behave if you use it as your router? Maybe that would reveal the problem area.

OE

on my previous setup (384.13 and 45717) work without problem. Work also ok on 81039.

btw. im not alone, same situation here
https://www.snbforums.com/threads/a...on-3-0-0-4-384-81049.58374/page-2#post-514048

 

[Andy1932]

Looks like this version has already been pulled from the web ui.

 

[OzarkEdge]

Looks like this version has already been pulled from the web ui.

And is no longer available here:

https://www.asus.com/us/Networking/RT-AC86U/HelpDesk_BIOS/

[sigh] Back to 45717, no Smart Connect/Auto channels, and no AiP.

OE

 

[L&LD]

I can still see this version as available.

 

[OzarkEdge]

I can still see this version as available.

Try selecting Win7 32-bit for the OS.

I do still see it when I select Win10 64-bit.

I suspect 81049 is on its way out if it's dropping wireless clients and nodes.

OE

 

[OzarkEdge]

I suspect 81049 is on its way out if it's dropping wireless clients and nodes.

I have mild log entries for a 2.4 (eth5) client sleeping about halfway between my nodes, so I decide to revert the 2.4 Roaming Assistant threshold from -70 back to the previous default of -55 dBm.

The log then filled up with similar eth5 and eth6 entries for multiple clients... too much to post.

And the webUI showed 5.0 clients moving/connecting to the remote node much farther away... in the detached garage. Why is a 2.4 change affecting 5.0 clients? I can understand eth6 disruption during a WiFi restart at the router for the eth5 setting change, but the log entries are still pouring in much later and I still have 5.0 clients not connecting normally.

It's as if the RA 2.4 default was changed to mask a firmware/AiMesh system problem!

I'm downgrading to 45717 and holding, again.

Edit: The 45717 Quick Setup routine and webUI is still offering 81049... no thanks.

OE

 

[citrixscu]

I downgraded to Merlin's latest after having a few clients connect/disconnect every 15 seconds or so.

 

[OzarkEdge]

I downgraded to Merlin's latest after having a few clients connect/disconnect every 15 seconds or so.

Wise.

@RMerlin may rue the day he enabled AiMesh. ASUS' last 18 months of AiMesh rollout have been painful; the latest firmware releases, 81039 and 81049, have been even uglier.

OE

 

[tallytr]

just downgraded to 3.0.0.4.384_45717 again, I guess I like it better