ASUS RT-AC86U Firmware version 3.0.0.4.384_81049

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

OzarkEdge

Part of the Furniture
WebUI is offering this 86U upgrade:

Firmware version 3.0.0.4.384_81049
- Release Note -

Security fix:
- Fixed a DDoS vulnerability. Thanks for Altin Thartori's contribution.

Bug fix:
- Fixed web control interface login problem. (new since 81039)
- Fixed Network map clist list issues. (new since 81039)
- Fixed block internet access problem when clients connected to AiMesh node. (new since 81039)
- Fixed Samba server compatibility issue.
- Fixed OpenVPN related bugs.
- Fixed schedule reboot bugs.
- Improved AiMesh compatibility.
- Improved system stability.

Edit: https://dlcdnets.asus.com/pub/ASUS/wireless/RT-AC86U/FW_RT_AC86U_300438481049.zip

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

OE
 
Last edited:

CriticJay

Senior Member
Hope this one sticks? :)
 

bitsbytes

Regular Contributor
gui is more responsive for me, ram usage is the same. Aimesh is running fine. ftp is back to 100Mbps after being limited to less than 70 for sometime. I'm running an 86u as a main with a 68u as a node with a Hdd media attached. for a casual user like me this update is really good and very stable.
 

VANT

Very Senior Member
now gui is work fast and smoth, no cpu spike

86_ok.png


THX Asus
 

citrixscu

Occasional Visitor
Deployed this after dirty flashing Merlin's latest a few days ago. Did a factory reset / init. No issues so far.
 

OzarkEdge

Part of the Furniture
WLCEVENTD errors are spamming the log.

I upgrade my 2xRT-AC86U AiMesh, removed the remote node to reset it, webUI Restore w/Initialize the router, configured the router (no Smart Connect), added the remote node, and have been humming along just fine so far. I did not have to cycle power on my cable modem... that was unusual.

I have these events recorded in the log since bringing in my mobile from roaming around the yard and setting it aside to sleep:

Sep 5 17:04:20 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth5: Disassoc 90:C7:D8:90:85:59, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep 5 17:04:20 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth5: Disassoc 90:C7:D8:90:85:59, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep 5 17:04:22 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth5: Auth 90:C7:D8:90:85:59, status: 0, reason: d11 RC reserved (0)
Sep 5 17:04:22 wlceventd: WLCEVENTD wlceventd_proc_event(430): eth5: ReAssoc 90:C7:D8:90:85:59, status: 0, reason: d11 RC reserved (0)
Sep 5 17:06:52 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth5: Disassoc 90:C7:D8:90:85:59, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep 5 17:06:52 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth5: Disassoc 90:C7:D8:90:85:59, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep 5 17:06:52 roamast: eth5: disconnect weak signal strength station [90:c7:d8:90:85:59]
Sep 5 17:06:52 roamast: eth5: remove client [90:c7:d8:90:85:59] from monitor list
Sep 5 17:07:05 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth5: Auth 90:C7:D8:90:85:59, status: 0, reason: d11 RC reserved (0)
Sep 5 17:07:05 wlceventd: WLCEVENTD wlceventd_proc_event(430): eth5: ReAssoc 90:C7:D8:90:85:59, status: 0, reason: d11 RC reserved (0)
Sep 5 17:15:49 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth5: Disassoc 90:C7:D8:90:85:59, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep 5 17:15:49 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth5: Disassoc 90:C7:D8:90:85:59, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep 5 17:15:49 roamast: eth5: disconnect weak signal strength station [90:c7:d8:90:85:59]
Sep 5 17:15:49 roamast: eth5: remove client [90:c7:d8:90:85:59] from monitor list
Sep 5 17:16:16 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth5: Auth 90:C7:D8:90:85:59, status: 0, reason: d11 RC reserved (0)
Sep 5 17:16:16 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth5: Assoc 90:C7:D8:90:85:59, status: 0, reason: d11 RC reserved (0)
Sep 5 17:16:42 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth5: Disassoc 90:C7:D8:90:85:59, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep 5 17:16:42 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth5: Disassoc 90:C7:D8:90:85:59, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Sep 5 17:16:42 roamast: eth5: disconnect weak signal strength station [90:c7:d8:90:85:59]
Sep 5 17:16:42 roamast: eth5: remove client [90:c7:d8:90:85:59] from monitor list
Sep 5 17:19:12 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth5: Auth 90:C7:D8:90:85:59, status: 0, reason: d11 RC reserved (0)
Sep 5 17:19:12 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth5: Assoc 90:C7:D8:90:85:59, status: 0, reason: d11 RC reserved (0)


OE
 

OzarkEdge

Part of the Furniture
ASUS must fire their Firmware Development and Engineering Team. Is this time to move to Netgear?

You should start your own topic to discuss this with other users.

OE
 

Zardoz

New Around Here
My initial impression is that this might have solved some irritating problems for me with AiMesh.
Probably too early to be certain but it "feels" better.
 

VANT

Very Senior Member
WLCEVENTD errors are spamming the log.
same for me.
I see continous this for my 68u node
Code:
Sep  6 06:45:11 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth5: Assoc 2C:xx:A1:xx:69:xx, status: 0, reason: d11 RC reserved (0)
Sep  6 06:45:19 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind 2C:xx:A1:xx:69:xx, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Sep  6 06:45:21 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth5: Auth 2C:xx:A1:xx:69:xx, status: 0, reason: d11 RC reserved (0)
Sep  6 06:45:21 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth5: Assoc 2C:xx:A1:xx:69:xx, status: 0, reason: d11 RC reserved (0)
Sep  6 06:45:23 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth5: Disassoc 2C:xx:A1:xx:69:xx, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)

and in wireles log my node is not authorized in 2,4GHz band

Code:
----------------------------------------
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:02
 
Last edited:

RMerlin

Asuswrt-Merlin dev
same for me.
I see continous this for my 68u node
Code:
Sep  6 06:45:11 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth5: Assoc 2C:xx:A1:xx:69:xx, status: 0, reason: d11 RC reserved (0)
Sep  6 06:45:19 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind 2C:xx:A1:xx:69:xx, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Sep  6 06:45:21 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth5: Auth 2C:xx:A1:xx:69:xx, status: 0, reason: d11 RC reserved (0)
Sep  6 06:45:21 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth5: Assoc 2C:xx:A1:xx:69:xx, status: 0, reason: d11 RC reserved (0)
Sep  6 06:45:23 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth5: Disassoc 2C:xx:A1:xx:69:xx, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)

and in wireles log my node is not authorized in 2,4GHz band

Code:
----------------------------------------
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:02

Try resetting the node and readding it. There's been a large jump in version, there might have been changes to AiMesh as well requiring re-adding nodes.
 

VANT

Very Senior Member
i jump from 81039, and with 81039 i have no problem with my node.

strange....
my node end of mac is xx:40, but in log i see xx.41

its normal ?

readding node not help, now 2,4GHz on node is not avaible....only node restart will help for some time
for me AIMesh in this release is not stable
 
Last edited:

ForkWNY

Regular Contributor
Upgraded via "firmware upgrade" button within UI...no problems so far. CPU usage seems normal and the Web UI works as expected.
 

Georg Norrbom

New Around Here
Running 81049 since announced in this forum on my 2 x RT-AC86u AiMesh and now the AiMesh node is offline for the second time.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top