What's new

This is normal on my asus router ax 3000?

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

MrHai

Occasional Visitor
This is normal on my asus router ax 3000? fimrware 386.1_2

General Log

Feb 27 10:43:30 wlceventd: wlceventd_proc_event(505): eth5: Auth D4:E6:B7:93:59:69, status: Successful (0)
Feb 27 10:43:30 wlceventd: wlceventd_proc_event(534): eth5: Assoc D4:E6:B7:93:59:69, status: Successful (0)
Feb 27 10:45:08 wlceventd: wlceventd_proc_event(505): eth6: Auth D4:F4:6F:36:0F:19, status: Successful (0)
Feb 27 10:45:08 wlceventd: wlceventd_proc_event(515): eth6: ReAssoc D4:F4:6F:36:0F:19, status: Successful (0)
Feb 27 10:45:08 wlceventd: wlceventd_proc_event(486): eth5: Disassoc D4:F4:6F:36:0F:19, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 27 10:45:08 wlceventd: wlceventd_proc_event(486): eth5: Disassoc D4:F4:6F:36:0F:19, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 27 10:45:53 wlceventd: wlceventd_proc_event(505): eth6: Auth DA:2A:04:4C:56:68, status: Successful (0)
Feb 27 10:45:53 wlceventd: wlceventd_proc_event(515): eth6: ReAssoc DA:2A:04:4C:56:68, status: Successful (0)
Feb 27 10:45:53 wlceventd: wlceventd_proc_event(486): eth5: Disassoc DA:2A:04:4C:56:68, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 27 10:45:53 wlceventd: wlceventd_proc_event(486): eth5: Disassoc DA:2A:04:4C:56:68, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 27 11:00:33 wlceventd: wlceventd_proc_event(469): eth5: Deauth_ind 00:D2:79:13:5A:45, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Feb 27 11:00:33 wlceventd: wlceventd_proc_event(469): eth5: Deauth_ind 00:D2:79:13:5A:45, status: 0, reason: Class 3 frame received from nonassociated station (7)
Feb 27 11:00:37 wlceventd: wlceventd_proc_event(505): eth6: Auth 00:D2:79:13:5A:45, status: Successful (0)
Feb 27 11:00:37 wlceventd: wlceventd_proc_event(534): eth6: Assoc 00:D2:79:13:5A:45, status: Successful (0)
Feb 27 11:10:55 wlceventd: wlceventd_proc_event(505): eth6: Auth 8C:83:E1:52:F8:AA, status: Successful (0)
Feb 27 11:10:55 wlceventd: wlceventd_proc_event(534): eth6: Assoc 8C:83:E1:52:F8:AA, status: Successful (0)
Feb 27 11:11:24 wlceventd: wlceventd_proc_event(505): eth5: Auth 8C:83:E1:52:F8:AA, status: Successful (0)
Feb 27 11:11:24 wlceventd: wlceventd_proc_event(515): eth5: ReAssoc 8C:83:E1:52:F8:AA, status: Successful (0)
Feb 27 11:11:24 wlceventd: wlceventd_proc_event(486): eth6: Disassoc 8C:83:E1:52:F8:AA, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 27 11:11:24 wlceventd: wlceventd_proc_event(486): eth6: Disassoc 8C:83:E1:52:F8:AA, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 27 11:13:08 wlceventd: wlceventd_proc_event(505): eth5: Auth 08:3D:88:02:5F:9C, status: Successful (0)
Feb 27 11:13:08 wlceventd: wlceventd_proc_event(534): eth5: Assoc 08:3D:88:02:5F:9C, status: Successful (0)
Feb 27 11:18:48 wlceventd: wlceventd_proc_event(505): eth6: Auth 8C:F5:A3:FC:74:C3, status: Successful (0)
Feb 27 11:18:48 wlceventd: wlceventd_proc_event(534): eth6: Assoc 8C:F5:A3:FC:74:C3, status: Successful (0)
Feb 27 11:28:45 wlceventd: wlceventd_proc_event(505): eth6: Auth 3C:AB:8E:5A:1E:95, status: Successful (0)
Feb 27 11:28:45 wlceventd: wlceventd_proc_event(515): eth6: ReAssoc 3C:AB:8E:5A:1E:95, status: Successful (0)
Feb 27 11:28:45 wlceventd: wlceventd_proc_event(486): eth5: Disassoc 3C:AB:8E:5A:1E:95, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Feb 27 11:28:45 wlceventd: wlceventd_proc_event(486): eth5: Disassoc 3C:AB:8E:5A:1E:95, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
 
It's simply the log reporting connection/deconnection events from your clients.
 
It's simply the log reporting connection/deconnection events from your clients.

Is there a way to limit the generation of those logs ... ?
 
very funny, indeed ... and constructive

Okay, ask yourself this ;

Why do so many people have logging turned on so they can see events and messages , then complain when the log shows you exactly what you asked for?

ASUS can't win. For years people have whined that they can't see enough WiFi information in the logs , now they have that information given to them they whine again.

Those reported events will help you see what is connecting/failing/intruding on your system. They show you your router and clients interactions , great for trouble shooting.
 
Last edited:
Those reported events will help you see what is connecting/failing/intruding on your system. They show you your router and clients interactions , great for trouble shooting.
exactly. Asus left debugging turned on so that if/when customers have issues with AiMesh or WiFi in general, the logs can be sent to the development engineers without the customer having to faff about turning on logging and trying to re-create an issue.
 
Scribe and uiScribe are your best solution to this “issue”.

 
install scribe which includes a wireless log event filter out of the box.
Thanks. This is the kind of advice I was looking for (I did not ask to get rid of those messages (but to limit them), if that would have been the case then the suggestion to turn wifi off would have not been irrelevant )
 
Thanks. This is the kind of advice I was looking for (I did not ask to get rid of those messages (but to limit them), if that would have been the case then the suggestion to turn wifi off would have not been irrelevant )
i agree the main log is "messy" but I can see why Asus do it. I do support for a software company and logs are vital for some issues. scribe/syslog-ng give us a way to retain this information while presenting it in a cleaner manner
 
i agree the main log is "messy" but I can see why Asus do it. I do support for a software company and logs are vital for some issues. scribe/syslog-ng give us a way to retain this information while presenting it in a cleaner manner

Thanks, I understand your point & fully agree with you. BTW my question/post was not at all a criticism of ASUS: I do like their routers and Merlin software.
 
exactly. Asus left debugging turned on so that if/when customers have issues with AiMesh or WiFi in general, the logs can be sent to the development engineers without the customer having to faff about turning on logging and trying to re-create an issue.
i want ask you...

My log very much

Feb 27 20:00:44 wlceventd: wlceventd_proc_event(469): eth5: Deauth_ind 00:D2:79:13:5A:45, status: 0, reason: Class 3 frame received from nonassociated station (7)
Feb 27 20:00:44 wlceventd: wlceventd_proc_event(469): eth5: Deauth_ind 00:D2:79:13:5A:45, status: 0, reason: Class 3 frame received from nonassociated station (7)


Deauth_ind This is disconnect?

You can help me The meaning of some of the following words, i cant find it in google translation.

1) Disassoc ???
2) ReAssoc ???
3) Auth ???
4) Deauth_ind ???

What words report a serious error, what is not a serious error, and which one says it is disconnected?
 

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