Many log events - WLCEVENTD

[eriddler]

Trying to figure out what is going on....hundreds of these occurring. I have AiMesh active with one main router and two nodes. Does this have anything to do with Roaming assistant?

Feb 18 19:03:02 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind 4C:ED:FB:7F:CA:29, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 18 19:03:02 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind 4C:ED:FB:7F:CA:29, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 18 19:03:02 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind 4C:ED:FB:7F:CA:29, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 18 19:03:04 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth 4C:ED:FB:7F:CA:29, status: 0, reason: d11 RC reserved (0)
Feb 18 19:03:04 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc 4C:ED:FB:7F:CA:29, status: 0, reason: d11 RC reserved (0)
Feb 18 19:03:05 roamast: determine candidate node [4C:ED:FB:7F:CA:28](rssi: -48dbm) for client [7C:2E:BD:52:06:97](rssi: -93dbm) to roam
Feb 18 19:03:05 roamast: eth1: disconnect weak signal strength station [7c:2e:bd:52:06:97]
Feb 18 19:03:05 roamast: eth1: remove client [7c:2e:bd:52:06:97] from monitor list
Feb 18 19:03:05 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind 7C:2E:BD:52:06:97, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Feb 18 19:03:12 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind 4C:ED:FB:7F:CA:29, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Feb 18 19:03:14 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth 7C:2E:BD:52:06:97, status: 0, reason: d11 RC reserved (0)
Feb 18 19:03:14 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc 7C:2E:BD:52:06:97, status: 0, reason: d11 RC reserved (0)
Feb 18 19:03:14 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth 4C:ED:FB:7F:CA:29, status: 0, reason: d11 RC reserved (0)
Feb 18 19:03:14 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc 4C:ED:FB:7F:CA:29, status: 0, reason: d11 RC reserved (0)
Feb 18 19:03:15 syslog: WLCEVENTD wlceventd_proc_event(401): eth1: Disassoc 4C:ED:FB:7F:CA:29, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 18 19:03:16 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth 4C:ED:FB:7F:CA:29, status: 0, reason: d11 RC reserved (0)
Feb 18 19:03:16 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc 4C:ED:FB:7F:CA:29, status: 0, reason: d11 RC reserved (0)
Feb 18 19:03:24 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind 4C:ED:FB:7F:CA:29, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Feb 18 19:03:26 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth 4C:ED:FB:7F:CA:29, status: 0, reason: d11 RC reserved (0)
Feb 18 19:03:26 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc 4C:ED:FB:7F:CA:29, status: 0, reason: d11 RC reserved (0)
Feb 18 19:03:26 syslog: WLCEVENTD wlceventd_proc_event(401): eth1: Disassoc 4C:ED:FB:7F:CA:29, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 18 19:03:28 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth 4C:ED:FB:7F:CA:29, status: 0, reason: d11 RC reserved (0)
Feb 18 19:03:28 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc 4C:ED:FB:7F:CA:29, status: 0, reason: d11 RC reserved (0)
Feb 18 19:03:35 roamast: determine candidate node [4C:ED:FB:7F:CA:28](rssi: -59dbm) for client [7C:2E:BD:52:06:97](rssi: -90dbm) to roam
Feb 18 19:03:35 roamast: eth1: disconnect weak signal strength station [7c:2e:bd:52:06:97]
Feb 18 19:03:35 roamast: eth1: remove client [7c:2e:bd:52:06:97] from monitor list
Feb 18 19:03:35 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind 7C:2E:BD:52:06:97, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)

 

[wouterv]

Trying to figure out what is going on....hundreds of these occurring. I have AiMesh active with one main router and two nodes. Does this have anything to do with Roaming assistant?

This is introduced due a firmware change some time ago and is related to the setting for the kind of messages to show in the System Log.
The kind of messages shown is defined with the severity level, the higher the number the more message types are shown.
In current firmware the default severity level is 6, this causes the WLCEVENTD messages.
A severity level of 5 will hide those messages.

The severity level can be shown and set with SSH commands:

1. nvram get log_level
2. nvram set log_level=5
3. nvram commit
4. reboot

 

[Drifter]

I had the same issue with my AC 2900 last day.

I searched here and did few changes, don't know which change made the difference and continuous logging of WLCEVENTD disappeared

 

[Butterfly Bones]

Trying to figure out what is going on....hundreds of these occurring. I have AiMesh active with one main router and two nodes. Does this have anything to do with Roaming assistant?

Feb 18 19:03:02 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind 4C:ED:FB:7F:CA:29, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 18 19:03:02 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind 4C:ED:FB:7F:CA:29, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 18 19:03:02 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind 4C:ED:FB:7F:CA:29, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Feb 18 19:03:04 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth 4C:ED:FB:7F:CA:29, status: 0, reason: d11 RC reserved (0)
Feb 18 19:03:04 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc 4C:ED:FB:7F:CA:29, status: 0, reason: d11 RC reserved (0)
Feb 18 19:03:05 roamast: determine candidate node [4C:ED:FB:7F:CA:28](rssi: -48dbm) for client [7C:2E:BD:52:06:97](rssi: -93dbm) to roam
Feb 18 19:03:05 roamast: eth1: disconnect weak signal strength station [7c:2e:bd:52:06:97]
Feb 18 19:03:05 roamast: eth1: remove client [7c:2e:bd:52:06:97] from monitor list
Feb 18 19:03:05 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind 7C:2E:BD:52:06:97, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Feb 18 19:03:12 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind 4C:ED:FB:7F:CA:29, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Feb 18 19:03:14 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth 7C:2E:BD:52:06:97, status: 0, reason: d11 RC reserved (0)
Feb 18 19:03:14 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc 7C:2E:BD:52:06:97, status: 0, reason: d11 RC reserved (0)
Feb 18 19:03:14 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth 4C:ED:FB:7F:CA:29, status: 0, reason: d11 RC reserved (0)
Feb 18 19:03:14 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc 4C:ED:FB:7F:CA:29, status: 0, reason: d11 RC reserved (0)
Feb 18 19:03:15 syslog: WLCEVENTD wlceventd_proc_event(401): eth1: Disassoc 4C:ED:FB:7F:CA:29, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 18 19:03:16 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth 4C:ED:FB:7F:CA:29, status: 0, reason: d11 RC reserved (0)
Feb 18 19:03:16 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc 4C:ED:FB:7F:CA:29, status: 0, reason: d11 RC reserved (0)
Feb 18 19:03:24 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind 4C:ED:FB:7F:CA:29, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Feb 18 19:03:26 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth 4C:ED:FB:7F:CA:29, status: 0, reason: d11 RC reserved (0)
Feb 18 19:03:26 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc 4C:ED:FB:7F:CA:29, status: 0, reason: d11 RC reserved (0)
Feb 18 19:03:26 syslog: WLCEVENTD wlceventd_proc_event(401): eth1: Disassoc 4C:ED:FB:7F:CA:29, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 18 19:03:28 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth 4C:ED:FB:7F:CA:29, status: 0, reason: d11 RC reserved (0)
Feb 18 19:03:28 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc 4C:ED:FB:7F:CA:29, status: 0, reason: d11 RC reserved (0)
Feb 18 19:03:35 roamast: determine candidate node [4C:ED:FB:7F:CA:28](rssi: -59dbm) for client [7C:2E:BD:52:06:97](rssi: -90dbm) to roam
Feb 18 19:03:35 roamast: eth1: disconnect weak signal strength station [7c:2e:bd:52:06:97]
Feb 18 19:03:35 roamast: eth1: remove client [7c:2e:bd:52:06:97] from monitor list
Feb 18 19:03:35 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind 7C:2E:BD:52:06:97, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)

Know issue.
https://www.snbforums.com/threads/r...13-is-now-available.57860/page-35#post-515660

https://www.snbforums.com/threads/a...384-45149-12-05-2018.50232/page-9#post-470731

 

[tallytr]

This is introduced due a firmware change some time ago and is related to the setting for the kind of messages to show in the System Log.
The kind of messages shown is defined with the severity level, the higher the number the more message types are shown.
In current firmware the default severity level is 6, this causes the WLCEVENTD messages.
A severity level of 5 will hide those messages.

The severity level can be shown and set with SSH commands:

1. nvram get log_level
2. nvram set log_level=5
3. nvram commit
4. reboot

Thank you!
I don't know why these WLCEVENTD messages bothered me but I changed the level to 5 using PuTTY SSH and they disappeared.

 

[wouterv]

Thank you!
I don't know why these WLCEVENTD messages bothered me but I changed the level to 5 using PuTTY SSH and they disappeared.

Good to hear.
I learned that the background of the issue is slightly different and shall be considered as a bug, but I didn't like the System Log consuming memory either.
By the way: Windows 10 by default supports SSH, no additional app is required.

 

[bertilak]

I get a few WLCEVENTD messages like this:

Aug 28 07:15:03 syslog: WLCEVENTD wlceventd_proc_event(529): eth1: Assoc 00:BB:3A:C9:03:BE, status: Successful (0)
Aug 28 09:45:01 syslog: WLCEVENTD wlceventd_proc_event(500): eth1: Auth 44:91:60:F3:F1:A4, status: Successful (0)
Aug 28 09:45:01 syslog: WLCEVENTD wlceventd_proc_event(481): eth2: Disassoc 44:91:60:F3:F1:A4, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Aug 28 09:45:01 syslog: WLCEVENTD wlceventd_proc_event(529): eth1: Assoc 44:91:60:F3:F1:A4, status: Successful (0)
Aug 28 09:45:01 syslog: WLCEVENTD wlceventd_proc_event(481): eth2: Disassoc 44:91:60:F3:F1:A4, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)

I put it down to wireless clients coming and going and figure it is OK.

The MAC addresses seem like reasonable things to check in and out (e.g. 00:BB:3A:C9:03:BE is for a kindle).

My Log Level is set to default=info and log only more urgent than info.

 

[tallytr]

Makes you wonder why Asus wouldn't offer a simple pull down menu right in the router > Change logging level

 

[wags1]

Any downside in changing the log level to 5?

 

[NAB]

Hi,

As new to this forum and ending up here after 500 hours of dr Google I just wanted to contribute with some information that helped me with the exact same issues both regarding system log and wlcevent after using an extender as aimesh and also as a extender.
Solution was to set fixed channel in my case 48 on 5g net as the extender talks with main router on that bw.

channels to try would be 36,40,44 or 48. I tried 36 same issues and switched to 48 and since no log entries or connection issues.

Hope this may help someone spare some useless hours searching

 

[NAB]

Update, was wrong for me it was two different issues.
1. Connectionissues solved with fixed port
2. log spam was Samsung multiroom wifi speakers that was registered as offline while streaming and as such no authentication, will try using their hub and see if it solves that issue.

 

[noah way]

This is introduced due a firmware change some time ago and is related to the setting for the kind of messages to show in the System Log.
The kind of messages shown is defined with the severity level, the higher the number the more message types are shown.
In current firmware the default severity level is 6, this causes the WLCEVENTD messages.
A severity level of 5 will hide those messages.

The severity level can be shown and set with SSH commands:

1. nvram get log_level
2. nvram set log_level=5
3. nvram commit
4. reboot

I've been searching for days to resolve this - thank you!

 

[Deleted member 51572]

interestingly, the log level on my RT-AC86U was already set to 5 (nvram get log_level) but WLCEVENTD messages were still flooding the system log. however (as @wouterv posted above) after entering: nvram set log_level=5; nvram commit; service restart_logd the WLCEVENTD messages have stopped (although i've not rebooted the 86U yet).

update: the WLCEVENTD messages are back. seems one client in particular, as he roams between APs with his iPhone, the 86U generates a lot of these messages for his MAC address, repeatedly. seems service restart_logd had no effect, so i probably need to reboot the router? it is in use atm, so i'll reboot later tonight, and report back.

 

[Butterfly Bones]

RMerlin explained this previously -

wlceventd is unrelated to DHCP. It's a daemon Asuswrt runs to detect wireless client connecting/disconnecting. There's a bug in the closed source code that has debugging output getting logged even if debugging is disabled (it doesn't properly check the debug flag state).

[Release] Asuswrt-Merlin 384.13 is now available

I believe that should work. My stubby.yml has the 127.0.0.1@53 entry too. Following is what I was using for the stubby installer asuswrt-merlin script: Yes, I wondered. But the native stubby at FW Merlin has only marked the IPV4 range. By default, IPV6 is disabled. But in my scenario, i enable...

www.snbforums.com

 

[Deleted member 51572]

RMerlin explained this previously -

[Release] Asuswrt-Merlin 384.13 is now available

I believe that should work. My stubby.yml has the 127.0.0.1@53 entry too. Following is what I was using for the stubby installer asuswrt-merlin script: Yes, I wondered. But the native stubby at FW Merlin has only marked the IPV4 range. By default, IPV6 is disabled. But in my scenario, i enable...

www.snbforums.com

so explicitly setting the router log level to 5 will not prevent these debugging messages from being logged, because the WLCEVENTD daemon doesn't respect debug flag state? got it, thanks. should be an easy fix, pity Asus hasn't bothered.

 

[wouterv]

interestingly, the log level on my RT-AC86U was already set to 5 (nvram get log_level) but WLCEVENTD messages were still flooding the system log. however (as @wouterv posted above) after entering: nvram set log_level=5; nvram commit; service restart_logd the WLCEVENTD messages have stopped (although i've not rebooted the 86U yet).

update: the WLCEVENTD messages are back. seems one client in particular, as he roams between APs with his iPhone, the 86U generates a lot of these messages for his MAC address, repeatedly. seems service restart_logd had no effect, so i probably need to reboot the router? it is in use atm, so i'll reboot later tonight, and report back.

Yes, you must reboot the router to take effect, the original post did tell you:

The severity level can be shown and set with SSH commands:

1. nvram get log_level
2. nvram set log_level=5
3. nvram commit
4. reboot

 

[noah way]

After setting log level to 5, uiDivStats stopped showing info. Diversion still worked but the reporting failed.

Re-enabled log level 6 and uiDivStats are back.

 

[Deleted member 51572]

Yes, you must reboot the router to take effect, the original post did tell you:

The severity level can be shown and set with SSH commands:

1. nvram get log_level
2. nvram set log_level=5
3. nvram commit
4. reboot

so i rebooted the 86U after explicitly setting the log level = 5 (the level was already set to 5) but WLCEVENTD log messages (Authorizations, Disassociations and ReAssociations) are still filling up the system log. the involved MAC addresses are all associated with iPhones.

anyway, @Butterfly Bones posted the explanation above, thanks.

 

[noah way]

Another observation on the repetition of WLCEVENTD Authorizations, Disassociations and ReAssociations:

IOS 14 has a private WiFi setting (for anti-tracking) that seems to be the cause of this. Disabling private WiFi in IOS stops the WLCEVENTD cycling.

 

[Deleted member 51572]

Another observation on the repetition of WLCEVENTD Authorizations, Disassociations and ReAssociations:

IOS 14 has a private WiFi setting (for anti-tracking) that seems to be the cause of this. Disabling private WiFi in IOS stops the WLCEVENTD cycling.

iOS 14 is not the issue in our case, no iOS devices on our network have Private MAC Address enabled, i made sure of that already