WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind

[distilled]

I read here that this message can be ignored, but I don't think that is the case here.

I flashed several IoT plugs and bulbs with Tasmota firmware yesterday. Everything went well, but the darned things won't stay connected to my WiFi. Prior to flashing, they were fine. The devices are different brands, different things and in different rooms, the only thing they share is this firmware, and the fact that they are based on the ESP8266, and this malfunction. I tried different revisions of the firmware, to no avail. I think it is a configuration in my 86u somewhere. I also tried a clean Merlin flash and rebuilt from scratch, but that didn't help. I left an AIMesh node unconnected to eliminate the remote possibility that it was a point of failure. I am going to create an open guest network, to see if that helps. Obviously that is not a solution, but it may narrow down that is happening.

The log entry is:

wlceventd: WLCEVENTD wlceventd_proc_event(386): eth5: Deauth_ind 2C:F4:32:25:xx:xx:xx, status: 0, reason: Class 2 frame received from nonauthenticated station (6)

I get this error for the 4 MAC addresses of these devices *only* and they are the only devices having the issue, so I think it is related. The devices stay connected for a short time, get booted and resort to AP mode.

Might anyone be able to lend any thoughts on what is happening, or have any troubleshooting advice? I would love for these things to work, having them communicate with HA and my LAN is much safer than the cloud.

I am ready to go back to kerosene lamps and horse drawn carriages lately. Although I doubt my wife would feel good about sewing my clothes.

 

[Chris_J]

I wonder whether this is a total coincidence, but from around 7am this morning (confirmed by looking in my 86U system logs), I am having a similar problem to what you describe. Except, my devices (TECKIN smart socket) are constantly connecting and disconnecting. They do not fall into AP mode. Recent log entry:

Mar 31 12:57:11 wlceventd: WLCEVENTD wlceventd_proc_event(386): wl0.1: Deauth_ind XX:XX:XX:XX:XX:XX, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)

Mar 31 12:57:11 wlceventd: WLCEVENTD wlceventd_proc_event(386): wl0.1: Deauth_ind XX:XX:XX:XX:XX:XX, status: 0, reason: Class 3 frame received from nonassociated station (7)

I didn't change anything with my setup, it seemed to happen spontaneously. The result is, the IoT devices are now a bit 'flakey'.

I have a total of 5 AC plugs, but I am not running any custom firmware on them. Sorry if this isn't much help, but it may shed some light on where the problem lies - i.e. not necessarily with the firmware you are using.

 

[distilled]

Hmm, did that just start? What firmware are you running? I am on 384.16 beta2.

And here I had been thinking that it was CUSTOM-19, a new virus that infects custom firmwares like Merlin and Tasmoda. My "medical" vape better watch out, it runs Arctic Fox. And my Obihai, drones, smartphones, cameras, television...the end is nigh for tinkerers of all sort!

 

[peepsnet]

I am getting the same error thousands of times. The MAC is the same every time. For me its my Nintendo3DS only

 

[ColinTaylor]

I read here that this message can be ignored, but I don't think that is the case here.

I flashed several IoT plugs and bulbs with Tasmota firmware yesterday. Everything went well, but the darned things won't stay connected to my WiFi. Prior to flashing, they were fine.

This would seem to clearly indicate an issue with the client devices. The message in the router's log is just telling you what's happening, it doesn't suggest any problem with the router itself.

 

[distilled]

This would seem to clearly indicate an issue with the client devices.

Sure, I don't think there is a problem with the router, I do suspect the devices. Everything worked between the router and these same devices prior to updating the firmware, so it isn't the hardware. The only change has been Tasmoda, but the issue hasn't been common with Tasmoda users, and using different versions of the firmware hasn't helped.

However, I did create an (isolated) *open* guest network for these devices and they have not dropped from it once. I am not sure how to use this information to troubleshoot further, but it is something.

I am going to increase logging on the router temporarily, to try to get more information.

WOOPS spoke too soon, they fell off the open guest. Back to the drawing board.

 

[ilicitano]

In my case this issue started with the release of new firmwares. Last firmware working properly without this issue is 3.0.0.4.384.45717

 

[distilled]

In my case this issue started with the release of new firmwares. Last firmware working properly without this issue is 3.0.0.4.384.45717

That is two years old though, right? What are the exact symptoms you are having, are devices unable to stay connected, or are you just being flooded by that error? If the latter, you may be able to fix it by just changing the log level.

 

[Butterfly Bones]

In my case this issue started with the release of new firmwares. Last firmware working properly without this issue is 3.0.0.4.384.45717

Look at the second half of this reply, then contact ASUS about the issue.
https://www.snbforums.com/threads/r...13-is-now-available.57860/page-35#post-515660

 

[ilicitano]

That is two years old though, right? What are the exact symptoms you are having, are devices unable to stay connected, or are you just being flooded by that error? If the latter, you may be able to fix it by just changing the log level.

This firmware was released 2019/05/13 and is the last one that is working properly with my raspberry. Using latest firmwares I have wifi connectivity problems (lots of wlceventd events).

How can I change the log level?

 

[distilled]

How can I change the log level?

https://www.snbforums.com/threads/many-log-events-wlceventd.61920/#post-552948

It won't help actual disconnections though.

 

[peepsnet]

Those entries were only thrown by one device. I deleted the wifi settings on the device and reconnected to the network. No more entries so far

 

[distilled]

Hmm, apparently there are some issues with these firmwares and ASUSWRT defaults.

I followed the advice here, and also moved an AP much closer to improve signal strength. Not sure what specific thing helped, but it has managed to stay connected for an hour, and that is pretty legendary. Fingers crossed.

https://www.snbforums.com/threads/problems-with-esp8266-devices-using-merlin-rt-ac68u.55796/

 

[distilled]

OK still doesn't work.

The fix that I applied was more a workaround, but it worked. I flashed an old Netgear with OpenWRT, configured it as a 2.4 GHz AP and used an AC Powerline adapter as a backhaul. No need for speed here, MQTT flipping a few switches doesn't require rocket engines, so this is fine.

Apparently a small number of devices including Asus don't play nice with Tasmota. Rather than play Sisyphus during quarantine, I opt to just make the dang thing work. Pick your battles, right?

At the end of the day, results count, and I have 4, soon to be a dozen gadgets that no longer send analytical data to Big Brother. That is a result that puts a smile on my increasingly cabin fevered face.

Hope everyone is safe.

 

[distilled]

I recently made a (temporary) transition from Merlin to stock, and noticed that the (now 11) Tasmotized devices on my LAN happily joined the WiFi. It was a new SSID but out of curiosity, I put up a guest WiFi with the SSID the devices were expecting, and boom. They would not stay connected to Merlin.

I dusted off an old, out of service AC66u running Merlin 380.70 just for grins, and the devices happily connect and stay connected to it also.

Maybe there is a difference in default settings that I am overlooking.

 

[L&LD]

The difference is more likely in the microcode between the different wireless drivers.

A new router (or new firmware with updated drivers)? A new SSID!

 

[distilled]

They stay connected with a fresh new SSID and a stock firmware install, but they wouldn't stay connected to Merlin, even after a factory reset.

Frankly at this point, I expect that in a few days when I put Merlin back, everything will stay connected. I also believe an unrelated problem related to VPN CAs not saving will be resolved. I do not believe this for any finite, sensible reason, it is just that whole "very clean slate" thing that fixes so many things.

Maurice & Roy: "Have you tried shutting it off and back on?"