384.14_2 on AC86U | Disassociated because sending station is leaving...

[RickyPullan]

Just picked up an AC86U and discovered the AsusMerlin firmware, and this forum along with it. You all are AWESOME! So impressed with all of the great knowledge here, and hoping that I can get some help. On AsusMerlin 384.14_2, I consistently see the following errors in the log:

Jan 31 23:14:29 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind SamsungTV, status: 0, reason: Disassociated due to inactivity (4)
Jan 31 23:14:29 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth6: Disassoc SamsungTV, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jan 31 23:14:29 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind SamsungTV, status: 0, reason: Class 3 frame received from nonassociated station (7)
Jan 31 23:14:29 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind SamsungTV, status: 0, reason: Class 3 frame received from nonassociated station (7)
Jan 31 23:14:29 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind SamsungTV, status: 0, reason: Class 3 frame received from nonassociated station (7)​

I see these errors every minute or so with most devices on my network, but especially with my SamsungTV and my Google Chromecast and Google Home devices, all connected to my 5GHz network.
The TV would randomly error out saying that it couldn't connect to Wifi, and my Google devices would always respond with, "Hold on, let me get connected to WiFi". After a while (sometimes a minute, sometimes 5 or so), the devices would come back up and reconnect, no problem.

I've seen this particular error posted a few times around the forum, and have seen various fixes: turn off airtime fairness, adjust channels, dropping to a lower firmware version, etc.

In the end, I ended up having to drop back down to version 384.13_0 before these errors went away. Is this a known issue with these newer versions? Is there some silver bullet out there that I've missed in the forums?

 

[ColinTaylor]

@EventPhotoMan I don't know whether that's the reply from Asus that you intended to post, but that reply has nothing at all to do with WiFi issues.

 

[Maverickcdn]

Personally I have all kinds of issues with the 5ghz network on my 86U but I was able to solve them by disabling all the beamforming,multiuser mimo, and airtime fairness in the wireless-->professional-->5Ghz tab. I also have the 2.4 radio disabled.

And are those devices using a static IP or DHCP?

 

[RickyPullan]

Personally I have all kinds of issues with the 5ghz network on my 86U but I was able to solve them by disabling all the beamforming,multiuser mimo, and airtime fairness in the wireless-->professional-->5Ghz tab. I also have the 2.4 radio disabled.

And are those devices using a static IP or DHCP?

I've got everything under static IPs.

I'm going to upgrade to the newest firmware, reset to factory defaults set it all up again, and try playing around with the settings you've suggested to see what happens. I'll report back here.

 

[RickyPullan]

I've got everything under static IPs.

I'm going to upgrade to the newest firmware, reset to factory defaults set it all up again, and try playing around with the settings you've suggested to see what happens. I'll report back here.

Thank you Maverickcdn! Turning off beamforming seemed to have fixed the issue! Bummed that I'll lose out on the extra performance but a few Mpbs drop in performance is worth full-time connectivity.

Thanks again!

EDIT: The problems started up again this AM with all of it turned off. Back to square one...

 

[Maverickcdn]

Thank you Maverickcdn!

Hopefully it stays working well for you!

 

[DarkKnight75]

I just reverted back to 384.14 from 384.14.2
My note 9 disconnected out of the 5ghz range for no reaaon..chromecast was working fine and today it started disappearing from my google home app and youtube as well. Had no issues prior to. I did a full reset and initialized after upgrading again.

 

[RickyPullan]

I just reverted back to 384.14 from 384.14.2
My note 9 disconnected out of the 5ghz range for no reaaon..chromecast was working fine and today it started disappearing from my google home app and youtube as well. Had no issues prior to. I did a full reset and initialized after upgrading again.

I'm going to try that today to see if it helps.

 

[RickyPullan]

Hopefully it stays working well for you!

Problems came back this AM... going to revert back one revision and see what happens.

 

[Maverickcdn]

Problems came back this AM... going to revert back one revision and see what happens.

Bummer.

Do you manually select a channel or is it on Auto? And what channel width are you using and is that width supported by your client device? Do you only have the one 86u as an access point on your network? And do your clients have any other access points configured on them

 

[SheikhSheikha]

I've got everything under static IPs.

I'm going to upgrade to the newest firmware, reset to factory defaults set it all up again, and try playing around with the settings you've suggested to see what happens. I'll report back here.

You might want to search this forum for user L&LD who has summarized all the goodies to do a proper firmware upgrade (M&M configuration). Following his directions will save you a lot of trouble and provide you with a true stabile flashed firmware on your Asus router.

 

[DarkKnight75]

I went back to 384.13 as 384.14 was also causing the same issue OP posted. This release IMO doesn't seem to be playing nice with an AC86U and hopefully these errors/bugs can be corrected in next release. I'll definitely not be upgrading my AC86U upon release of new firmware.

 

[DarkKnight75]

My router was running for 2 + months on 384.13 before a reboot and had no issues whatsoever.

 

[DarkWolfSLV]

Having similar issues on my RT-AC86U running v384.14, but in my case all my devices eventually experience a problem.
I have smart connect ON since I noticed that everything was using 2.4GHz no matter what.

Example below of my smart speaker.

Feb 5 11:25:20 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth6: Auth D4:F5:47:3A:BE:BF, status: 0, reason: d11 RC reserved (0)
Feb 5 11:25:20 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth6: Assoc D4:F5:47:3A:BE:BF, status: 0, reason: d11 RC reserved (0)
Feb 5 11:25:20 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth5: Disassoc D4:F5:47:3A:BE:BF, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 5 11:25:20 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth5: Disassoc D4:F5:47:3A:BE:BF, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
!
Feb 5 12:08:30 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind D4:F5:47:3A:BE:BF, status: 0, reason: Disassociated due to inactivity (4)
Feb 5 12:08:30 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth6: Disassoc D4:F5:47:3A:BE:BF, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)

I had similar problems with the previous version my router was on (which I do not remember which was it was) but I'll follow the suggestion and go back to 384.13

 

[DarkKnight75]

Having similar issues on my RT-AC86U running v384.14, but in my case all my devices eventually experience a problem.
I have smart connect ON since I noticed that everything was using 2.4GHz no matter what.

Example below of my smart speaker.

Feb 5 11:25:20 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth6: Auth D4:F5:47:3A:BE:BF, status: 0, reason: d11 RC reserved (0)
Feb 5 11:25:20 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth6: Assoc D4:F5:47:3A:BE:BF, status: 0, reason: d11 RC reserved (0)
Feb 5 11:25:20 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth5: Disassoc D4:F5:47:3A:BE:BF, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 5 11:25:20 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth5: Disassoc D4:F5:47:3A:BE:BF, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
!
Feb 5 12:08:30 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind D4:F5:47:3A:BE:BF, status: 0, reason: Disassociated due to inactivity (4)
Feb 5 12:08:30 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth6: Disassoc D4:F5:47:3A:BE:BF, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)

I had similar problems with the previous version my router was on (which I do not remember which was it was) but I'll follow the suggestion and go back to 384.13

Yes, go back to 384.13 and devices should behave normal again (that's been my experience).

384.14 & 384.14_2 firmware was based & compiled on ASUS GPL Version 3.0.0.4.384.81351 which was known to have some performance & 5ghz issues. Also, it seems to be ASUS bug in their code that has been around for awhile, but for some reason it's been alot worse in 384.14 & 384.14_2

 

[dave14305]

Yes, go back to 384.13 and devices should behave normal again (that's been my experience).

384.14 & 384.14_2 firmware was based & compiled on ASUS GPL Version 3.0.0.4.384.81351 which was known to have some performance & 5ghz issues. Also, it seems to be ASUS bug in their code that has been around for awhile, but for some reason it's been alot worse in 384.14 & 384.14_2

The WLCEVENTD messages aren't problems themselves; they are just extra debug output for what is already happening in your wireless network(s). You may still have some of the same issues back on 384.13, but you don't know it because the extra log messages aren't there. Is the Wireless driver for the AC86U the same or different between 384.13 and 384.14_2? Check on Tools page.

 

[DarkKnight75]

The WLCEVENTD messages aren't problems themselves; they are just extra debug output for what is already happening in your wireless network(s). You may still have some of the same issues back on 384.13, but you don't know it because the extra log messages aren't there. Is the Wireless driver for the AC86U the same or different between 384.13 and 384.14_2? Check on Tools page.

If the messages are running in the background, they aren't affecting my router the way they were on 384.14. On 384.14, these messages would flood my log and actually cause 2.4ghz and 5ghz clients to drop and re-associate every 15-20 minutes. I made several Wifi tweaks which is currently running on 384.13 with no issues and didnt make a diff on 384.14

Check this post from Merlin: https://www.snbforums.com/threads/release-asuswrt-merlin-384-13-is-now-available.57860/page-36 (Indeed, the RT-AC68U wifi is pretty stable with 45717. 81049 is actually more problematic. Its acsd seems to rescan the airwaves every 15 minutes (flooding syslog every single time), and in my case, it kept changing the 2.4 GHz channel nearly every single time it ran.)

 

[jackiechun]

Yes, go back to 384.13 and devices should behave normal again (that's been my experience).

384.14 & 384.14_2 firmware was based & compiled on ASUS GPL Version 3.0.0.4.384.81351 which was known to have some performance & 5ghz issues. Also, it seems to be ASUS bug in their code that has been around for awhile, but for some reason it's been alot worse in 384.14 & 384.14_2

Same experience as me. 384.13 is rock solid on my AC86U.

 

[DarkWolfSLV]

dave14305 is correct, after the downgrade I still have some WLCEVENTD, but I do not thing they are "normal" since the devices disconnecting are Smart Speakers (2) and my cellphone to list a few.

I'll keep a close eye to the performance and report back.
Regards.

 

[DarkKnight75]

dave14305 is correct, after the downgrade I still have some WLCEVENTD, but I do not thing they are "normal" since the devices disconnecting are Smart Speakers (2) and my cellphone to list a few.

I'll keep a close eye to the performance and report back.
Regards.

Interesting...my ac86u not generating any after 7hrs uptime.