Asus RT-AC88U Drops HomeKit Devices WLCEVENTD

[StephenHCable]

I just wanted to hop on and say I had these same issues and finally was able to remedy them. My log was ate up with the WLCEVNTD errors. For background purposes I have a GT-AX11000 as my main router with 2 RT-AC88U AI-mesh nodes set up. I have a large home with many "smart" devices accessing WiFi and Ethernet at all times. After tracking down the mac address to the devices causing the issues from the error log I found that my Ring chime device was disconnected from the ring hub causing one of the constant disassociation's and associations. The other was my KEEN home smart vent wireless bridge.
For reference the error logs always showed ETH6, ETH7, ETH8, however the mac address showed it was WiFi devices and Ethernet. Not just Ethernet.

To remedy the issues I pulled up my log and left it active on my laptop as I reconnected the device (mac address). Once I seen it disappear from the log I reset the log and continued to the next. The Keen smart bridge connects all of my furnace vents (14 devices) so it was throwing a ton of errors. Both bridges are hardwired to my Ethernet ports on the AC88u's (1 on each). I simply unplugged power to each bridge for 5 mins and reconnected. Cleared my log again and have had no issues for several days.

Hope this helps someone.

 

[ka81]

• LAN > IPTV > Enable multicast routing (IGMP Proxy) > Enable
• Wireless > Professional > Enable IGMP Snooping > Enable

Could someone tell - whether these should be Enabled or Disabled?

 

[StephenHCable]

Could someone tell - whether these should be Enabled or Disabled?

Changing these did nothing but slow down my overall speed. I went from 480 to 125 over WiFi after system reset and stabilization with those changes.

 

[ka81]

Uhmm.. Soo it both should be Enabled?

 

[StephenHCable]

Uhmm.. Soo it both should be Enabled?

It’s honestly trial and error per your needs.

 

[Submit]

I have this extremely annoying thing where my router keeps dropping all my wifi devices for a few seconds then reconnects again.


----- This are the last events, no edit between them ----
Jan 12 20:51:15 WLCEVENTD: eth1: Disassoc 40:CB:C0:76:5A:33
Jan 12 21:13:03 WLCEVENTD: eth1: Assoc 40:CB:C0:76:5A:33
Jan 12 21:36:21 WLCEVENTD: eth2: Assoc 54:BD:79:05:87:76
Jan 12 21:52:29 WLCEVENTD: eth1: Assoc D4:90:9C:ED:9A:70
Jan 12 22:01:01 WLCEVENTD: eth1: Disassoc D4:90:9C:ED:9A:70
Jan 12 22:55:50 WLCEVENTD: eth1: Disassoc A0:9D:C1:20:3B6
Jan 12 22:55:50 WLCEVENTD: eth1: Assoc A0:9D:C1:20:3B6
Jan 12 22:55:58 WLCEVENTD: eth1: Disassoc 00:7E:56:77:30:11
Jan 12 22:55:58 WLCEVENTD: eth1: Assoc 00:7E:56:77:30:11



This is what shows up in the logs. Every single homekit devices resets at this point, lights turn on (the default state) and homekit outlets reset, turning off and on (no idea why they turn off but whatever). Its really annoying, had this router for about 1 year and didn't have any problems with it..it just started doing this sh*t few weeks ago.

Anyone else knows whats up with these WLCEVENTD events? and how can they be fixed?

Thank you...Asus has sh*tty support so I have no luck with them besides sending this to warranty and waiting 2 weeks to prob get it back.

If you want to escape from a long explanation, this is for short: look for a WiFi repeater or range extender in your wireless network and unplug it, then see if there is a change in the system log.

I tried turning off WPS and UPnP services, buying a new ONT (optical network terminal) cable, upgrade and downgrade ASUS firmware, enabling en disabling MAC filter, treated as Wi-Fi deauthentication attack... even light a candle.

In my case a NetGear WN2500RP was causing that mess... if you do not have such devices, maybe this helps you trying something else. I have an ASUS RT-AC3100 with Firmware version 3.0.0.4.384.81116 (19-sept-2019), originally the error log reads as follows:

Jan 20 14:18:39 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind 04:A1:51:E8:3B:24, status: 0, reason: Class 3 frame received from nonassociated station (7)

First let’s “read” the log:

• Jan 20 14:18:39 syslog: says (time of the event) syslog
• WLCEVENTD: Wireless LAN Controller Event Daemon
• wlceventd_proc_event(386): indicates an error event 386 regarding a synchronization problem that occurs when you use the default database
• eth1: location of the error in the Ethernet interface 1, in this case is the second wireless because wlan0 is the name of the first wireless network interface in the system
• Deauth_ind 04:A1:51:E8:3B:24, status: 0: Deauthenticated indicates (address) status zero
  • 04:A1:51:xx:xx:xx is “format 1” Assigned MAC range to NETGEAR Vendor
• Class 3 frame received from nonassociated station (7): according to 802.11 Deauth Reason Codes definition is “station is leaving (or has left) IBSS or ESS

Putting all together, the error log indicates the time of error in the second wireless local area network regarding a synchronization event caused by the use of a default database, specifically in the second wireless ethernet interface using a NETGEAR assigned MAC address. Also says that this device is been de- authenticated because the station is not associated to station seven or has left it.

Finally, after studied and learned to read the log, and only if you know all the details of your network, it sends you directly to the problem.

 

[ka81]

Could someone please help with identifying the cause of that problem?
DC:A9:71:5D:F4:7B - I guess it's my laptop, connected to router with 2.4 GHz

Jan 21 13:26:01 acsd: eth1: NONACSD channel switching to channel spec: 0x1001 (1)
Jan 21 13:26:03 syslog: WLCEVENTD wlceventd_proc_event(401): eth1: Disassoc DC:A9:71:5D:F4:7B, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jan 21 13:26:03 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth DC:A9:71:5D:F4:7B, status: 0, reason: d11 RC reserved (0)
Jan 21 13:26:03 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc DC:A9:71:5D:F4:7B, status: 0, reason: d11 RC reserved (0)
Jan 21 13:27:11 acsd: COEX: downgraded chanspec 0x1903 to 0x1005: ext channel 1 used as ctrl channel by existing BSSs
Jan 21 13:27:11 acsd: COEX: downgraded chanspec 0x1904 to 0x1006: channel 1 used by exiting BSSs
Jan 21 13:27:11 acsd: COEX: downgraded chanspec 0x1905 to 0x1007: channel 1 used by exiting BSSs
Jan 21 13:27:11 acsd: COEX: downgraded chanspec 0x1906 to 0x1008: channel 1 used by exiting BSSs
Jan 21 13:27:11 acsd: COEX: downgraded chanspec 0x1907 to 0x1009: channel 2 used by exiting BSSs
Jan 21 13:27:11 acsd: COEX: downgraded chanspec 0x1908 to 0x100a: channel 3 used by exiting BSSs
Jan 21 13:27:11 acsd: COEX: downgraded chanspec 0x1909 to 0x100b: channel 4 used by exiting BSSs
Jan 21 13:27:11 acsd: COEX: downgraded chanspec 0x190a to 0x100c: channel 5 used by exiting BSSs
Jan 21 13:27:11 acsd: COEX: downgraded chanspec 0x190b to 0x100d: channel 6 used by exiting BSSs
Jan 21 13:27:11 acsd: COEX: downgraded chanspec 0x1803 to 0x1001: ctrl channel 1 SB not aligned with existing 40BSS
Jan 21 13:27:11 acsd: COEX: downgraded chanspec 0x1804 to 0x1002: channel 1 used by exiting BSSs
Jan 21 13:27:11 acsd: COEX: downgraded chanspec 0x1805 to 0x1003: channel 1 used by exiting BSSs
Jan 21 13:27:11 acsd: COEX: downgraded chanspec 0x1806 to 0x1004: channel 1 used by exiting BSSs
Jan 21 13:27:11 acsd: COEX: downgraded chanspec 0x1807 to 0x1005: channel 2 used by exiting BSSs
Jan 21 13:27:11 acsd: COEX: downgraded chanspec 0x1808 to 0x1006: channel 3 used by exiting BSSs
Jan 21 13:27:11 acsd: COEX: downgraded chanspec 0x1809 to 0x1007: channel 4 used by exiting BSSs
Jan 21 13:27:11 acsd: COEX: downgraded chanspec 0x180a to 0x1008: channel 5 used by exiting BSSs
Jan 21 13:27:11 acsd: COEX: downgraded chanspec 0x180b to 0x1009: channel 6 used by exiting BSSs
Jan 21 13:27:11 acsd: selected channel spec: 0x1002 (2)
Jan 21 13:27:11 acsd: Adjusted channel spec: 0x1002 (2)
Jan 21 13:27:11 acsd: selected channel spec: 0x1002 (2)
Jan 21 13:27:12 acsd: eth1: NONACSD channel switching to channel spec: 0x1002 (2)
Jan 21 13:27:12 syslog: WLCEVENTD wlceventd_proc_event(401): eth1: Disassoc DC:A9:71:5D:F4:7B, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jan 21 13:27:12 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth DC:A9:71:5D:F4:7B, status: 0, reason: d11 RC reserved (0)
Jan 21 13:27:13 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth DC:A9:71:5D:F4:7B, status: 0, reason: d11 RC reserved (0)
Jan 21 13:27:13 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc DC:A9:71:5D:F4:7B, status: 0, reason: d11 RC reserved (0)
Jan 21 13:28:23 acsd: COEX: downgraded chanspec 0x1903 to 0x1005: ext channel 1 used as ctrl channel by existing BSSs
Jan 21 13:28:23 acsd: COEX: downgraded chanspec 0x1904 to 0x1006: channel 1 used by exiting BSSs
Jan 21 13:28:23 acsd: COEX: downgraded chanspec 0x1905 to 0x1007: channel 1 used by exiting BSSs
Jan 21 13:28:23 acsd: COEX: downgraded chanspec 0x1906 to 0x1008: channel 1 used by exiting BSSs
Jan 21 13:28:23 acsd: COEX: downgraded chanspec 0x1907 to 0x1009: channel 2 used by exiting BSSs
Jan 21 13:28:23 acsd: COEX: downgraded chanspec 0x1908 to 0x100a: channel 3 used by exiting BSSs
Jan 21 13:28:23 acsd: COEX: downgraded chanspec 0x1909 to 0x100b: channel 4 used by exiting BSSs
Jan 21 13:28:23 acsd: COEX: downgraded chanspec 0x190a to 0x100c: channel 5 used by exiting BSSs
Jan 21 13:28:23 acsd: COEX: downgraded chanspec 0x190b to 0x100d: channel 6 used by exiting BSSs
Jan 21 13:28:23 acsd: COEX: downgraded chanspec 0x1803 to 0x1001: ctrl channel 1 SB not aligned with existing 40BSS
Jan 21 13:28:23 acsd: COEX: downgraded chanspec 0x1804 to 0x1002: channel 1 used by exiting BSSs
Jan 21 13:28:23 acsd: COEX: downgraded chanspec 0x1805 to 0x1003: channel 1 used by exiting BSSs
Jan 21 13:28:23 acsd: COEX: downgraded chanspec 0x1806 to 0x1004: channel 1 used by exiting BSSs
Jan 21 13:28:23 acsd: COEX: downgraded chanspec 0x1807 to 0x1005: channel 2 used by exiting BSSs
Jan 21 13:28:23 acsd: COEX: downgraded chanspec 0x1808 to 0x1006: channel 3 used by exiting BSSs
Jan 21 13:28:23 acsd: COEX: downgraded chanspec 0x1809 to 0x1007: channel 4 used by exiting BSSs
Jan 21 13:28:23 acsd: COEX: downgraded chanspec 0x180a to 0x1008: channel 5 used by exiting BSSs
Jan 21 13:28:23 acsd: COEX: downgraded chanspec 0x180b to 0x1009: channel 6 used by exiting BSSs
Jan 21 13:28:23 acsd: selected channel spec: 0x1001 (1)
Jan 21 13:28:23 acsd: Adjusted channel spec: 0x1001 (1)
Jan 21 13:28:23 acsd: selected channel spec: 0x1001 (1)
Jan 21 13:28:23 acsd: eth1: NONACSD channel switching to channel spec: 0x1001 (1)
Jan 21 13:28:25 syslog: WLCEVENTD wlceventd_proc_event(401): eth1: Disassoc DC:A9:71:5D:F4:7B, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jan 21 13:28:25 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth DC:A9:71:5D:F4:7B, status: 0, reason: d11 RC reserved (0)
Jan 21 13:28:25 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc DC:A9:71:5D:F4:7B, status: 0, reason: d11 RC reserved (0)
Jan 21 13:29:34 acsd: COEX: downgraded chanspec 0x1903 to 0x1005: ext channel 1 used as ctrl channel by existing BSSs
Jan 21 13:29:34 acsd: COEX: downgraded chanspec 0x1904 to 0x1006: channel 1 used by exiting BSSs
Jan 21 13:29:34 acsd: COEX: downgraded chanspec 0x1905 to 0x1007: channel 1 used by exiting BSSs
Jan 21 13:29:34 acsd: COEX: downgraded chanspec 0x1906 to 0x1008: channel 1 used by exiting BSSs
Jan 21 13:29:34 acsd: COEX: downgraded chanspec 0x1907 to 0x1009: channel 2 used by exiting BSSs
Jan 21 13:29:34 acsd: COEX: downgraded chanspec 0x1908 to 0x100a: channel 3 used by exiting BSSs
Jan 21 13:29:34 acsd: COEX: downgraded chanspec 0x1909 to 0x100b: channel 4 used by exiting BSSs
Jan 21 13:29:34 acsd: COEX: downgraded chanspec 0x190a to 0x100c: channel 5 used by exiting BSSs
Jan 21 13:29:34 acsd: COEX: downgraded chanspec 0x190b to 0x100d: channel 6 used by exiting BSSs
Jan 21 13:29:34 acsd: COEX: downgraded chanspec 0x1803 to 0x1001: ctrl channel 1 SB not aligned with existing 40BSS
Jan 21 13:29:34 acsd: COEX: downgraded chanspec 0x1804 to 0x1002: channel 1 used by exiting BSSs
Jan 21 13:29:34 acsd: COEX: downgraded chanspec 0x1805 to 0x1003: channel 1 used by exiting BSSs
Jan 21 13:29:34 acsd: COEX: downgraded chanspec 0x1806 to 0x1004: channel 1 used by exiting BSSs
Jan 21 13:29:34 acsd: COEX: downgraded chanspec 0x1807 to 0x1005: channel 2 used by exiting BSSs
Jan 21 13:29:34 acsd: COEX: downgraded chanspec 0x1808 to 0x1006: channel 3 used by exiting BSSs
Jan 21 13:29:34 acsd: COEX: downgraded chanspec 0x1809 to 0x1007: channel 4 used by exiting BSSs
Jan 21 13:29:34 acsd: COEX: downgraded chanspec 0x180a to 0x1008: channel 5 used by exiting BSSs
Jan 21 13:29:34 acsd: COEX: downgraded chanspec 0x180b to 0x1009: channel 6 used by exiting BSSs
Jan 21 13:29:35 acsd: selected channel spec: 0x1002 (2)
Jan 21 13:29:35 acsd: Adjusted channel spec: 0x1002 (2)
Jan 21 13:29:35 acsd: selected channel spec: 0x1002 (2)
Jan 21 13:29:35 acsd: eth1: NONACSD channel switching to channel spec: 0x1002 (2)
Jan 21 13:29:35 syslog: WLCEVENTD wlceventd_proc_event(401): eth1: Disassoc DC:A9:71:5D:F4:7B, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jan 21 13:29:35 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth DC:A9:71:5D:F4:7B, status: 0, reason: d11 RC reserved (0)
Jan 21 13:29:35 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc DC:A9:71:5D:F4:7B, status: 0, reason: d11 RC reserved (0)

 

[OzarkEdge]

Could someone please help with identifying the cause of that problem?
DC:A9:71:5D:F4:7B - I guess it's my laptop, connected to router with 2.4 GHz

I recommend:

o Start with a factory default reset and configure from scratch;

o Leave the default settings unless noted otherwise;

o Use separate WiFi SSIDs and fixed channels as noted in my install notes;

o Start your own topic in the Asuswrt-Merlin sub forum to discuss any issues you encounter using that firmware.

OE

 

[Submit]

Could someone please help with identifying the cause of that problem?
DC:A9:71:5D:F4:7B - I guess it's my laptop, connected to router with 2.4 GHz

Could someone please help with identifying the cause of that problem?
DC:A9:71:5D:F4:7B - I guess it's my laptop, connected to router with 2.4 GHz

Why don’t you try “Enable Smart Connect”?... it will handle 2GHz and 5GHz client’s links.

I get that you probably need to separate Bands however, your devices will handle switching better if you use “dual-band smart connect”.

The error “acsd: COEX: downgraded chanspec 0x1909 to 0x100b: channel 4 used by exiting BSSs” says that “channel 4” is in conflict, probably same channel is been used by near wireless devices... I would let “Control Channel” set in “auto”.

Enabling option “Enable IGMP Snooping” will handle multicast traffic.

Finally, I found no benefits disabling “Airtime Fairness”, “Multi-User MIMO” nor “Universal Beamforming”.

 

[ka81]

Why don’t you try “Enable Smart Connect”?... it will handle 2GHz and 5GHz client’s links.

I get that you probably need to separate Bands however, your devices will handle switching better if you use “dual-band smart connect”.
.

Everyone everywhere suggest to separate it...
I'll try Smart..

The error “acsd: COEX: downgraded chanspec 0x1909 to 0x100b: channel 4 used by exiting BSSs” says that “channel 4” is in conflict, probably same channel is been used by near wireless devices... I would let “Control Channel” set in “auto”.

But I set channel to 9 and 100. There's no 4 in settings.. ?

Enabling option “Enable IGMP Snooping” will handle multicast traffic.

Finally, I found no benefits disabling “Airtime Fairness”, “Multi-User MIMO” nor “Universal Beamforming”.

Ok, I'll try it enabled..


Thank you!

 

[GuruGuy]

Everyone everywhere suggest to separate it...
I'll try Smart..


But I set channel to 9 and 100. There's no 4 in settings.. ?



Ok, I'll try it enabled..


Thank you!

Devices will NOT handle it better using smart connect. It does work for some, but for most it's a pain and a gimmick. Letting the router force a client to one band or the other is not the best way and in the end the client is going to do what it thinks best and move to where it wants to be. No sense in having to fight the router in doing so. I would do as OE suggested and reset to factory settings, set it up as Separate SSID's when doing so (don't choose smart connect) and then have separate SSID's and fixed channels. Leave the defaults alone and see how things are. All the tips about tweaking this and that are what causes most issues that people have.

 

[ka81]

made reset, default, Smart Connection disabled.
For 5 - channle 132
for 2.4 - Auto

Every minute like that:

Jan 22 15:52:56 syslog: WLCEVENTD wlceventd_proc_event(401): eth1: Disassoc DC:A9:71:5D:F4:7B, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jan 22 15:52:56 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth DC:A9:71:5D:F4:7B, status: 0, reason: d11 RC reserved (0)
Jan 22 15:52:56 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc DC:A9:71:5D:F4:7B, status: 0, reason: d11 RC reserved (0)
Jan 22 15:52:59 acsd: eth1: NONACSD channel switching to channel spec: 0x1001 (1)
Jan 22 15:54:12 acsd: selected channel spec: 0x100b (11)
Jan 22 15:54:12 acsd: Adjusted channel spec: 0x100b (11)
Jan 22 15:54:12 acsd: selected channel spec: 0x100b (11)
Jan 22 15:54:13 syslog: WLCEVENTD wlceventd_proc_event(401): eth1: Disassoc DC:A9:71:5D:F4:7B, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jan 22 15:54:13 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth DC:A9:71:5D:F4:7B, status: 0, reason: d11 RC reserved (0)
Jan 22 15:54:13 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc DC:A9:71:5D:F4:7B, status: 0, reason: d11 RC reserved (0)
Jan 22 15:54:14 acsd: eth1: NONACSD channel switching to channel spec: 0x100b (11)
Jan 22 15:55:36 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth 40:B8:37:C0:5F2, status: 0, reason: d11 RC reserved (0)
Jan 22 15:55:36 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc 40:B8:37:C0:5F2, status: 0, reason: d11 RC reserved (0)
Jan 22 15:56:48 acsd: selected channel spec: 0x1001 (1)
Jan 22 15:56:48 acsd: Adjusted channel spec: 0x1001 (1)
Jan 22 15:56:48 acsd: selected channel spec: 0x1001 (1)
Jan 22 15:56:49 syslog: WLCEVENTD wlceventd_proc_event(401): eth1: Disassoc DC:A9:71:5D:F4:7B, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jan 22 15:56:49 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth DC:A9:71:5D:F4:7B, status: 0, reason: d11 RC reserved (0)
Jan 22 15:56:49 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc DC:A9:71:5D:F4:7B, status: 0, reason: d11 RC reserved (0)
Jan 22 15:56:50 acsd: eth1: NONACSD channel switching to channel spec: 0x1001 (1)
Jan 22 15:56:57 syslog: WLCEVENTD wlceventd_proc_event(401): eth1: Disassoc 40:B8:37:C0:5F2, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jan 22 15:56:57 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth 40:B8:37:C0:5F2, status: 0, reason: d11 RC reserved (0)
Jan 22 15:56:57 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc 40:B8:37:C0:5F2, status: 0, reason: d11 RC reserved (0)
Jan 22 15:58:00 acsd: selected channel spec: 0x100b (11)
Jan 22 15:58:00 acsd: Adjusted channel spec: 0x100b (11)
Jan 22 15:58:00 acsd: selected channel spec: 0x100b (11)
Jan 22 15:58:02 syslog: WLCEVENTD wlceventd_proc_event(401): eth1: Disassoc DC:A9:71:5D:F4:7B, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jan 22 15:58:02 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth DC:A9:71:5D:F4:7B, status: 0, reason: d11 RC reserved (0)
Jan 22 15:58:02 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc DC:A9:71:5D:F4:7B, status: 0, reason: d11 RC reserved (0)
Jan 22 15:58:05 acsd: eth1: NONACSD channel switching to channel spec: 0x100b (11)
Jan 22 15:58:08 syslog: WLCEVENTD wlceventd_proc_event(401): eth1: Disassoc 40:B8:37:C0:5F2, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jan 22 15:58:08 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth 40:B8:37:C0:5F2, status: 0, reason: d11 RC reserved (0)
Jan 22 15:58:08 syslog: WLCEVENTD wlceventd_proc_event(430): eth1: ReAssoc 40:B8:37:C0:5F2, status: 0, reason: d11 RC reserved (0)
Jan 22 15:59:15 acsd: selected channel spec: 0x1001 (1)
Jan 22 15:59:15 acsd: Adjusted channel spec: 0x1001 (1)
Jan 22 15:59:15 acsd: selected channel spec: 0x1001 (1)
Jan 22 15:59:17 syslog: WLCEVENTD wlceventd_proc_event(401): eth1: Disassoc DC:A9:71:5D:F4:7B, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jan 22 15:59:17 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth DC:A9:71:5D:F4:7B, status: 0, reason: d11 RC reserved (0)
Jan 22 15:59:17 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc DC:A9:71:5D:F4:7B, status: 0, reason: d11 RC reserved (0)
Jan 22 15:59:18 acsd: eth1: NONACSD channel switching to channel spec: 0x1001 (1)
Jan 22 15:59:24 syslog: WLCEVENTD wlceventd_proc_event(401): eth1: Disassoc 40:B8:37:C0:5F2, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jan 22 15:59:24 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth 40:B8:37:C0:5F2, status: 0, reason: d11 RC reserved (0)
Jan 22 15:59:24 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc 40:B8:37:C0:5F2, status: 0, reason: d11 RC reserved (0)
Jan 22 16:00:40 acsd: selected channel spec: 0x100b (11)
Jan 22 16:00:40 acsd: Adjusted channel spec: 0x100b (11)
Jan 22 16:00:40 acsd: selected channel spec: 0x100b (11)
Jan 22 16:00:42 syslog: WLCEVENTD wlceventd_proc_event(401): eth1: Disassoc DC:A9:71:5D:F4:7B, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jan 22 16:00:42 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth DC:A9:71:5D:F4:7B, status: 0, reason: d11 RC reserved (0)
Jan 22 16:00:42 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc DC:A9:71:5D:F4:7B, status: 0, reason: d11 RC reserved (0)
Jan 22 16:00:45 acsd: eth1: NONACSD channel switching to channel spec: 0x100b (11)
Jan 22 16:02:45 acsd: selected channel spec: 0x1001 (1)
Jan 22 16:02:45 acsd: Adjusted channel spec: 0x1001 (1)
Jan 22 16:02:45 acsd: selected channel spec: 0x1001 (1)

 

[OzarkEdge]

made reset, default, Smart Connection disabled.
For 5 - channle 132
for 2.4 - Auto

Every minute like that:

Do as you like and live with it.

OE

 

[Luizlp10]

Dou you guys think those events have any real impact on performance or are just "annoying"? My AC86u log is filled with them.

 

[OzarkEdge]

Dou you guys think those events have any real impact on performance or are just "annoying"? My AC86u log is filled with them.

For me, if they go away with this advice, it's a 'don't care'... can't worry about everything that's not right in my world.

OE

 

[ShadowThief]

made reset, default, Smart Connection disabled.
For 5 - channle 132
for 2.4 - Auto

Every minute like that:

Hi.
is all your device that disconnects on same GHz? (2.5 or 5)
I had this problem mainly on 2.5 GHz (old chromecast) and I had to specify the channel. It worked well with 6.
One device disconnected like that on 5GHz so I do not use auto there either now.

 

[ka81]

Start with a factory default reset and configure from scratch;

Factory default reset: before, or after flashing?
Since the goal is to use the NEW default values that are included in the NEW firmware, the factory default reset must be done while the NEW firmware is already flashed. Doing so before flashing will leave you running the OLD default values.

Somebody, clarify that please.. I always thought restoring to defaults (reset) must be done BEFORE flashing new firmware.. No?

I make reseting, flash new firmware, and all the new default values from new firmware exists, no?

 

[ka81]

Perform router Restore w/Initialize and wait for it to settle (factory default reset w/initialization AFTER firmware upgrade)

How to go through that procedure?

 

[OzarkEdge]

Somebody, clarify that please.. I always thought restoring to defaults (reset) must be done BEFORE flashing new firmware.. No?

I make reseting, flash new firmware, and all the new default values from new firmware exists, no?

No. Reset AFTER installing new firmware. And do not restore a saved configuration to new firmware, generally speaking.

OE

 

[OzarkEdge]

How to go through that procedure?

Go to the firmware page in the router webUI, select Restore w/Initialize. This will reset like the button reset AND wipe old logged data... a tidier reset.

OE