What's new

[Release] Asuswrt-Merlin 384.14 (and 384.13_2) are now available

  • 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!

Status
Not open for further replies.
Hello!
What is it and how to get rid of it from the event log?

Jan 9 11:24:58 wlceventd: WLCEVENTD wlceventd_proc_event(401): eth6: Disassoc 70:8B:CD:C8:52:90, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jan 9 11:25:01 wlceventd: WLCEVENTD wlceventd_proc_event(386): eth6: Deauth_ind 70:8B:CD:C8:52:90, status: 0, reason: Class 3 frame received from nonassociated station (7)
Jan 9 11:25:04 wlceventd: WLCEVENTD wlceventd_proc_event(420): eth6: Auth 70:8B:CD:C8:52:90, status: 0, reason: d11 RC reserved (0)
Jan 9 11:25:04 wlceventd: WLCEVENTD wlceventd_proc_event(449): eth6: Assoc 70:8B:CD:C8:52:90, status: 0, reason: d11 RC reserved (0)


AC86U + 384.14_2

PS: On version 14, there really was some kind of strange floating problem with Internet monitoring. I had active ping on google. So sometimes the router ceases to be allowed on the Internet, connections with the provider are established. A full reboot helped. As soon as I turn off Internet monitoring - everything is OK, well, or return to version 13. Paradox.
I have the same messages in my log
WLCEVENTD = WireLess Client EVENT Daemon.

ASUS (intentionally or otherwise) turned on some excess debugging messages in the closed source section of the code (i.e. there is nothing RMerlin can do about it). The only way to "get rid of it" is to install scribe which replaces the system logger (syslogd) with a more robust logger (syslog-ng). Syslog-ng allows capturing various messages and putting them in their own log file (or discarding them altogether). One of scribe's default filters is for the WLCEVENTD messages.

Or, just ignore them, they're harmless.
 
WLCEVENTD = WireLess Client EVENT Daemon.

ASUS (intentionally or otherwise) turned on some excess debugging messages in the closed source section of the code (i.e. there is nothing RMerlin can do about it). The only way to "get rid of it" is to install scribe which replaces the system logger (syslogd) with a more robust logger (syslog-ng). Syslog-ng allows capturing various messages and putting them in their own log file (or discarding them altogether). One of scribe's default filters is for the WLCEVENTD messages.

Or, just ignore them, they're harmless.

I wouldn't say they're all harmless, and you should just ignore them. As I get these type of errors in my log, and when I do, my Galaxy S9+ briefly drops wifi to my RT-AC3100, and reconnects. I have tried all kinds of setting changes on the router, forgot wifi on the phone itself, reset it multiple times, and reconnected to it. Still the random drops are happening. So that tells me there's some kind of wireless driver conflict between the router, and my S9+.

This wasn't an issue a few months ago, so I feel there was likely a wireless driver change within the last 6 months for the RT-AC3100, causing this to happen. As it has been a while since the last big update happen on the phone itself.
 
I'm not one of those 'Me Too' kinda posters but it in this case I think it's important to mention this since 384.14_2 should have fixed the traffic spikes but I've not seen anyone else mention still having the problem.

My uptime is closing in on 6 days and this is the first time i recall seeing this since upgrading, though I admit I've not looked for days.

My setup is a RT-AC86U (with a 68U mesh node).

upload_2020-1-9_13-38-4.png
 
Hello!

How to get the RT-AX88U CPU/2.4GHz/5.0GHz temperatures from the command line?

Thanks in advance
Regards
 
RT-AC68U: dirty upgrade from .13 to .14. Upgrade itself went fine but am now hit with this:
disco.jpg

Went to the Administration->System page, no Network Monitoring was enabled. Tried Ping, no luck. Tried DNS Query, no luck. It appears to be a visual problem only, access to the internet is working.
I have the same problem with RT-AC88U
 
I wouldn't say they're all harmless, and you should just ignore them. As I get these type of errors in my log, and when I do, my Galaxy S9+ briefly drops wifi to my RT-AC3100, and reconnects. I have tried all kinds of setting changes on the router, forgot wifi on the phone itself, reset it multiple times, and reconnected to it. Still the random drops are happening. So that tells me there's some kind of wireless driver conflict between the router, and my S9+.

This wasn't an issue a few months ago, so I feel there was likely a wireless driver change within the last 6 months for the RT-AC3100, causing this to happen. As it has been a while since the last big update happen on the phone itself.
Interesting, I'm not experiencing that. I too have a log full of WLCEVENTD notices (I have AC86U), but my Galaxy S8 doesn't drop WiFi.

Also, all wifi code is closed source, and there isn't anything RMerlin can do about it.
 
Upgraded to 384.14_2 RT-AC68U default gateway did not change but I am running as an AP.

OK, I see. I run in router mode, with NAT and all that. The WAN link is just regular Ethernet, no PPPoE or anything. There is Ethernet uplink in the apartment to some router that hands public IP/default GW via DHCPv4.
 
Switching to 384.14 then 384.14_2 from AIMesh has been great for me so far on two RT-AC1900P (router/AP) - 30 devices or so.
 
Unfortunately I had a number of problems with .14 and .14_2 on AC86U (with 2 AC68U in Mesh) - examples: Mesh stopped working, reboot of the 2 AC68U made them invisible, reboot of AC86U removed all settings. Even after proper factory reset of all devices and upgrade to.14_2 on all of them no stable Mesh connectivity.

I am back now on .13 for the hub and 3.0.0.4.384.81351 for the 2 AC68U - system is now as great and stable as before.
I had all those types of issues on .13 on my 86U hub, but am getting none on the .14. (my mesh nodes are a rt-ac68u and a dsl-ac68u). I was getting mesh disconnections, and then mesh nodes vanishing without a trace.

I've found that if the 86U isn't rebooted at least weekly, then things start going pear shaped. Soft reboot doesn't count, it needs to be a full power cycle.

I suspect these sorts of mesh issues are highly sensitive to lots of factors, and they appear like they hit randomly.
 
@Chris121284, try testing by setting up a new (Guest) SSID that you've never used (ever) before that contains between 8 and 16 alphanumeric characters with no smiley faces, punctuation or special characters (in both the SSID and the password).

Do all devices work now? If they do; either use that new SSID/password combination on your main network or 'forget' and re-associate all your devices individually.

It is physically impossible for a client device to 'not get signal' when others do. They are simply confused somehow. :)

Well, it was fun while it lasted. Same problems started happening again. So I factory reset again, created a whole new SSID, whole new password, both never used before, nothing but letters and numbers. Forgot the old network on every device, set every device back up on the new network. Everything worked perfect for about 5 hours, now it's right back to doing the same things. Getting basically no speed on random select devices. Distance from the router seems to have no relevance as my phone won't get wifi two feet from the router while one of my nest cameras downstairs will. The other downstairs nest camera is almost exactly the same distance but it's struggling to stay connected. Can't seem to find a permanent fix.

EDIT:

Update: I tried the above method one more time for good measure. It worked for about 2 minutes, did a second speed test, speed drop to about half of what it had been before. Did a third speed test, dropped about half again. Fourth speed test a few minutes later, back to getting <1mbps for good now.
 
Last edited:
I've been having issues with "Internet Status: Disconnected" on the Network Map, even when the network is working normally and Internet connectivity has been confirmed. I used to get that issue only occasionally, and a reboot of the network would fix it, but now it's persisting.

I've also been having more WiFi devices saying there's no connection, whereas other ones on the network work normally.
I'm on 384.14_2 with AC68U.

I've also read that both DNS and Ping should be enabled under Network Monitoring, so I enabled DNS.
Also tried disabling Network Monitoring completely. But I'm still getting the "Disconnected" message.

And possibly unrelated, but I'm also noticing a decrease in speed when I do speed tests from my wired machine. It struggles to reach the max line speed, which is definitely not normal for my network.
 
Same problem with 13_2 on RT-AC87U. In the end, I flashed back to 12.0 and no problem so far. Will stay on 12.0 for now.

I've been having issues with "Internet Status: Disconnected" on the Network Map, even when the network is working normally and Internet connectivity has been confirmed. I used to get that issue only occasionally, and a reboot of the network would fix it, but now it's persisting.

I've also been having more WiFi devices saying there's no connection, whereas other ones on the network work normally.
I'm on 384.14_2 with AC68U.

I've also read that both DNS and Ping should be enabled under Network Monitoring, so I enabled DNS.
Also tried disabling Network Monitoring completely. But I'm still getting the "Disconnected" message.

And possibly unrelated, but I'm also noticing a decrease in speed when I do speed tests from my wired machine. It struggles to reach the max line speed, which is definitely not normal for my network.
 
Same problem with 13_2 on RT-AC87U. In the end, I flashed back to 12.0 and no problem so far. Will stay on 12.0 for now.
I do not have it, ever.

For other routers, I think it it fixed in .15 alpha...
 
Are you on 13_1 or 13_2? I noticed this problem 3 times while on 13_2. Will wait for 15 release then.
Haven't changed signature until now, I am on 384.13_2, and did not have it prior either.
 
8 days on 14_2 with no issues.

Thanks again for all the hard work.
 
Thank you Merlin for all your hard work. Just did dirty upgrade to 384.14_2 from 384.13 on my RT-AC1900P (main router) and everything is working very smooth so far (basic/vanilla setup). The only thing I always do after an upgrade I did power down the router for 5 minutes.
 
I had been running 384.14 for several months on my AC88U without issue. I updated to 384.14_2 and hard reset it afterwards. It was fine for a week, but I just left for a 3 week trip and now all my devices are showing as offline, including hardwired devices. I can’t ping my router and I can’t VPN into it as it won’t connect. I think the network on the router is dead. That is very bad timing. I haven’t seen that for a long time and only once with 384.14 which a hard reset fixed.
 
Last edited:
hello

im with RTac88U and 384.14_2
i having problems with this line
WLCEVENTD wlceventd_proc_event(386)


and here is part of my log
Jan 10 23:38:40 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind BC:76:, status: 0, reason: Class 3 frame received from nonassociated station (7)
Jan 10 23:38:40 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind BC:76:, status: 0, reason: Class 3 frame received from nonassociated station (7)
Jan 10 23:38:40 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind BC:76:, status: 0, reason: Class 3 frame received from nonassociated station (7)
Jan 10 23:38:40 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind BC:76xxxxxxxx, status: 0, reason: Class 3 frame received from nonassociated station (7)
Jan 10 23:38:40 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind BC:76xxxxxxxx:, status: 0, reason: Class 3 frame received from nonassociated station (7)
Jan 10 23:38:40 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind BC:76xxxxxxxx:, status: 0, reason: Class 3 frame received from nonassociated station (7)
Jan 10 23:38:40 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind BC:76xxxxxxxx:, status: 0, reason: Class 3 frame received from nonassociated station (7)
Jan 10 23:38:40 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind BC:76xxxxxxxx:, status: 0, reason: Class 3 frame received from nonassociated station (7)
Jan 10 23:38:40 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind BC:76xxxxxxxx:, status: 0, reason: Class 3 frame received from nonassociated station (7)
Jan 10 23:38:40 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind BC:76xxxxxxxx, status: 0, reason: Class 3 frame received from nonassociated station (7)
Jan 10 23:38:40 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind BC:76xxxxxxxx, status: 0, reason: Class 3 frame received from nonassociated station (7)
Jan 10 23:38:40 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind BC:76xxxxxxxx:, status: 0, reason: Class 3 frame received from nonassociated station (7)

and this repeat till the end

im having problems with ramdom drops in the 5ghz band,
like this
Jan 10 19:19:26 syslog: WLCEVENTD wlceventd_proc_event(386): eth1: Deauth_ind 7C:DBxxxxxxxx, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Jan 10 19:19:26 syslog: WLCEVENTD wlceventd_proc_event(401): eth1: Disassoc 7C:DBxxxxxxxx:, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)
Jan 10 19:19:27 syslog: WLCEVENTD wlceventd_proc_event(420): eth1: Auth 7C:DBxxxxxxxx:, status: 0, reason: d11 RC reserved (0)
Jan 10 19:19:27 syslog: WLCEVENTD wlceventd_proc_event(449): eth1: Assoc 7C:DBxxxxxxxx:, status: 0, reason: d11 RC reserved (0)


please, could someone help me?
 
Last edited:
Status
Not open for further replies.

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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

Staff online

Top