What's new

RT-AX86U - system log spam from Tuya Smart device

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

Will setting up a Guest 2.4 Ghz network special for IoT devices like Tuya a good idea?
I think it would for sure. The annoying Tommee Tippee clock has a way of connecting to wifi which makes this tricky but generally I think it is a good idea. But I guess it doesn't help if the devices are unknown!
 
I think it would for sure. The annoying Tommee Tippee clock has a way of connecting to wifi which makes this tricky but generally I think it is a good idea. But I guess it doesn't help if the devices are unknown!
Yes, let's try it .
 
I have a similar problem with my RT-AX5400 router. Some 2.4Ghz devices ends-up disconnecting and reconnecting all the time. It can work well for hours or days without this problem, but eventually the problem comes back and the logs get flooded. A reboot usually fixes it for some time.

In the example below, it's an appliance that's connected to a 2.4GHz Guest network which keeps disconnecting. But I get similar problems with an Epson printer (connected to another separate 2.4GHz Guest network) and with a Sonos speaker that's connected to the main 2.4Ghz network (which uses Smart Connect).

It's my first Asus router, so it's possible I have something that's not properly set. But I'm not impressed with the stability up to now. Note that I'm using the native Asuswrt firmware (not Merlin).

Please share anything you find. I would really like to solve these issues.

Code:
Dec 28 13:40:11 wlceventd: wlceventd_proc_event(645): wl0.2: Deauth_ind __MAYTAG_01__, status: 0, reason: Unspecified reason (1), rssi:-38
Dec 28 13:40:11 wlceventd: wlceventd_proc_event(685): wl0.2: Auth __MAYTAG_01__, status: Successful (0), rssi:-38
Dec 28 13:40:11 wlceventd: wlceventd_proc_event(722): wl0.2: Assoc __MAYTAG_01__, status: Successful (0), rssi:-38
Dec 28 13:40:38 wlceventd: wlceventd_proc_event(645): wl0.2: Deauth_ind __MAYTAG_01__, status: 0, reason: Unspecified reason (1), rssi:-39
Dec 28 13:40:38 wlceventd: wlceventd_proc_event(685): wl0.2: Auth __MAYTAG_01__, status: Successful (0), rssi:-39
Dec 28 13:40:38 wlceventd: wlceventd_proc_event(722): wl0.2: Assoc __MAYTAG_01__, status: Successful (0), rssi:-39
Dec 28 13:41:05 wlceventd: wlceventd_proc_event(645): wl0.2: Deauth_ind __MAYTAG_01__, status: 0, reason: Unspecified reason (1), rssi:-37
Dec 28 13:41:05 wlceventd: wlceventd_proc_event(685): wl0.2: Auth __MAYTAG_01__, status: Successful (0), rssi:-37
Dec 28 13:41:05 wlceventd: wlceventd_proc_event(722): wl0.2: Assoc __MAYTAG_01__, status: Successful (0), rssi:-37
Dec 28 13:41:32 wlceventd: wlceventd_proc_event(645): wl0.2: Deauth_ind __MAYTAG_01__, status: 0, reason: Unspecified reason (1), rssi:-37
Dec 28 13:41:32 wlceventd: wlceventd_proc_event(685): wl0.2: Auth __MAYTAG_01__, status: Successful (0), rssi:-37
Dec 28 13:41:32 wlceventd: wlceventd_proc_event(722): wl0.2: Assoc __MAYTAG_01__, status: Successful (0), rssi:-37
Dec 28 13:41:55 wlceventd: wlceventd_proc_event(645): wl0.2: Deauth_ind __MAYTAG_01__, status: 0, reason: Disassociated due to inactivity (4), rssi:-43
Dec 28 13:41:58 wlceventd: wlceventd_proc_event(685): wl0.2: Auth __MAYTAG_01__, status: Successful (0), rssi:0
Dec 28 13:41:58 wlceventd: wlceventd_proc_event(722): wl0.2: Assoc __MAYTAG_01__, status: Successful (0), rssi:-37
Dec 28 13:42:25 wlceventd: wlceventd_proc_event(645): wl0.2: Deauth_ind __MAYTAG_01__, status: 0, reason: Unspecified reason (1), rssi:-42
Dec 28 13:42:25 wlceventd: wlceventd_proc_event(685): wl0.2: Auth __MAYTAG_01__, status: Successful (0), rssi:-42
Dec 28 13:42:25 wlceventd: wlceventd_proc_event(722): wl0.2: Assoc __MAYTAG_01__, status: Successful (0), rssi:-42
Dec 28 13:42:48 wlceventd: wlceventd_proc_event(645): wl0.2: Deauth_ind __MAYTAG_01__, status: 0, reason: Disassociated due to inactivity (4), rssi:-43
Dec 28 13:42:52 wlceventd: wlceventd_proc_event(685): wl0.2: Auth __MAYTAG_01__, status: Successful (0), rssi:0
Dec 28 13:42:52 wlceventd: wlceventd_proc_event(722): wl0.2: Assoc __MAYTAG_01__, status: Successful (0), rssi:-42
Dec 28 13:43:10 wlceventd: wlceventd_proc_event(645): wl0.2: Deauth_ind __MAYTAG_01__, status: 0, reason: Disassociated due to inactivity (4), rssi:-46
Dec 28 13:43:19 wlceventd: wlceventd_proc_event(685): wl0.2: Auth __MAYTAG_01__, status: Successful (0), rssi:0
Dec 28 13:43:19 wlceventd: wlceventd_proc_event(722): wl0.2: Assoc __MAYTAG_01__, status: Successful (0), rssi:-41
Dec 28 13:43:45 wlceventd: wlceventd_proc_event(645): wl0.2: Deauth_ind __MAYTAG_01__, status: 0, reason: Unspecified reason (1), rssi:-41
Dec 28 13:43:45 wlceventd: wlceventd_proc_event(685): wl0.2: Auth __MAYTAG_01__, status: Successful (0), rssi:-41
Dec 28 13:43:45 wlceventd: wlceventd_proc_event(722): wl0.2: Assoc __MAYTAG_01__, status: Successful (0), rssi:-41
Dec 28 13:44:10 wlceventd: wlceventd_proc_event(645): wl0.2: Deauth_ind __MAYTAG_01__, status: 0, reason: Disassociated due to inactivity (4), rssi:-43
Dec 28 13:44:12 wlceventd: wlceventd_proc_event(685): wl0.2: Auth __MAYTAG_01__, status: Successful (0), rssi:0
Dec 28 13:44:12 wlceventd: wlceventd_proc_event(722): wl0.2: Assoc __MAYTAG_01__, status: Successful (0), rssi:-43
Dec 28 13:44:35 wlceventd: wlceventd_proc_event(645): wl0.2: Deauth_ind __MAYTAG_01__, status: 0, reason: Disassociated due to inactivity (4), rssi:-46
Dec 28 13:44:39 wlceventd: wlceventd_proc_event(685): wl0.2: Auth __MAYTAG_01__, status: Successful (0), rssi:0
Dec 28 13:44:39 wlceventd: wlceventd_proc_event(722): wl0.2: Assoc __MAYTAG_01__, status: Successful (0), rssi:-42
Dec 28 13:44:54 wlceventd: wlceventd_proc_event(645): wl0.2: Deauth_ind __MAYTAG_01__, status: 0, reason: Disassociated due to inactivity (4), rssi:-44
Dec 28 13:45:05 wlceventd: wlceventd_proc_event(685): wl0.2: Auth __MAYTAG_01__, status: Successful (0), rssi:0
Dec 28 13:45:05 wlceventd: wlceventd_proc_event(722): wl0.2: Assoc __MAYTAG_01__, status: Successful (0), rssi:-40
Dec 28 13:45:32 wlceventd: wlceventd_proc_event(645): wl0.2: Deauth_ind __MAYTAG_01__, status: 0, reason: Unspecified reason (1), rssi:0
Dec 28 13:45:32 wlceventd: wlceventd_proc_event(685): wl0.2: Auth __MAYTAG_01__, status: Successful (0), rssi:0
Dec 28 13:45:32 wlceventd: wlceventd_proc_event(722): wl0.2: Assoc __MAYTAG_01__, status: Successful (0), rssi:-41
Dec 28 13:45:57 wlceventd: wlceventd_proc_event(645): wl0.2: Deauth_ind __MAYTAG_01__, status: 0, reason: Disassociated due to inactivity (4), rssi:-49
Dec 28 13:45:58 wlceventd: wlceventd_proc_event(645): wl0.2: Deauth_ind __MAYTAG_01__, status: 0, reason: Disassociated due to inactivity (4), rssi:0
Dec 28 13:45:59 wlceventd: wlceventd_proc_event(685): wl0.2: Auth __MAYTAG_01__, status: Successful (0), rssi:0
Dec 28 13:45:59 wlceventd: wlceventd_proc_event(722): wl0.2: Assoc __MAYTAG_01__, status: Successful (0), rssi:-39
Dec 28 13:46:18 wlceventd: wlceventd_proc_event(645): wl0.2: Deauth_ind __MAYTAG_01__, status: 0, reason: Disassociated due to inactivity (4), rssi:-41
Dec 28 13:46:26 wlceventd: wlceventd_proc_event(685): wl0.2: Auth __MAYTAG_01__, status: Successful (0), rssi:0
Dec 28 13:46:26 wlceventd: wlceventd_proc_event(722): wl0.2: Assoc __MAYTAG_01__, status: Successful (0), rssi:-41
Dec 28 13:46:52 wlceventd: wlceventd_proc_event(645): wl0.2: Deauth_ind __MAYTAG_01__, status: 0, reason: Unspecified reason (1), rssi:-39
Dec 28 13:46:52 wlceventd: wlceventd_proc_event(685): wl0.2: Auth __MAYTAG_01__, status: Successful (0), rssi:-39
Dec 28 13:46:52 wlceventd: wlceventd_proc_event(722): wl0.2: Assoc __MAYTAG_01__, status: Successful (0), rssi:-39
 
everyone must be getting these spam cause i see it aswell in my log as 1C:90.....

when auth 1c:90 spams - my log does not show any of my devices normal auth messages.

i think its just a default/fallback auth address showing instead of your devices.

I restore/reset and still see that auth mac. theres a problem on the latest stock firmware for sure.
 
Last edited:
Hello, I would appreciate thoughts on whether some constant spam from a Tuya Smart device in my system log could be linked to the router falling over every 7-8 days? I've only noticed this problem since upgrading to 3.0.0.4.388_24231 although I don't know whether it is definitely linked.

The entries I see are like this (I've partially masked the two MAC addresses involved):

Code:
Dec 13 15:30:21 wlceventd: wlceventd_proc_event(685): eth6: Auth 1C:90:FF:aa:bb:cc, status: Successful (0), rssi:0
Dec 13 15:30:22 wlceventd: wlceventd_proc_event(685): wl0.1: Auth 1C:90:FF:xx:yy:zz, status: Successful (0), rssi:0
Dec 13 15:30:22 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind 1C:90:FF:xx:yy:zz, status: 0, reason: Unspecified reason (1), rssi:0
Dec 13 15:30:22 wlceventd: wlceventd_proc_event(685): eth6: Auth 1C:90:FF:xx:yy:zz, status: Successful (0), rssi:0
Dec 13 15:30:22 wlceventd: wlceventd_proc_event(645): wl0.1: Deauth_ind 1C:90:FF:xx:yy:zz, status: 0, reason: Unspecified reason (1), rssi:0
Dec 13 15:30:22 wlceventd: wlceventd_proc_event(685): wl0.1: Auth 1C:90:FF:xx:yy:zz, status: Successful (0), rssi:0
Dec 13 15:30:22 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind 1C:90:FF:xx:yy:zz, status: 0, reason: Unspecified reason (1), rssi:0
Dec 13 15:30:22 wlceventd: wlceventd_proc_event(645): wl0.1: Deauth_ind 1C:90:FF:xx:yy:zz, status: 0, reason: Unspecified reason (1), rssi:0
Dec 13 15:30:22 wlceventd: wlceventd_proc_event(685): eth6: Auth 1C:90:FF:xx:yy:zz, status: Successful (0), rssi:0
Dec 13 15:30:22 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind 1C:90:FF:xx:yy:zz, status: 0, reason: Unspecified reason (1), rssi:0
Dec 13 15:30:22 wlceventd: wlceventd_proc_event(685): eth6: Auth 1C:90:FF:xx:yy:zz, status: Successful (0), rssi:0
Dec 13 15:30:25 wlceventd: wlceventd_proc_event(685): wl0.1: Auth 1C:90:FF:aa:bb:cc, status: Successful (0), rssi:0
Dec 13 15:30:25 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind 1C:90:FF:aa:bb:cc, status: 0, reason: Unspecified reason (1), rssi:0
Dec 13 15:30:25 wlceventd: wlceventd_proc_event(685): eth6: Auth 1C:90:FF:aa:bb:cc, status: Successful (0), rssi:0
Dec 13 15:30:25 wlceventd: wlceventd_proc_event(645): wl0.1: Deauth_ind 1C:90:FF:aa:bb:cc, status: 0, reason: Unspecified reason (1), rssi:0
Dec 13 15:30:25 wlceventd: wlceventd_proc_event(685): wl0.1: Auth 1C:90:FF:aa:bb:cc, status: Successful (0), rssi:0
Dec 13 15:30:25 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind 1C:90:FF:aa:bb:cc, status: 0, reason: Unspecified reason (1), rssi:0
Dec 13 15:30:25 wlceventd: wlceventd_proc_event(685): eth6: Auth 1C:90:FF:aa:bb:cc, status: Successful (0), rssi:0
Dec 13 15:30:25 wlceventd: wlceventd_proc_event(645): wl0.1: Deauth_ind 1C:90:FF:aa:bb:cc, status: 0, reason: Unspecified reason (1), rssi:0
Dec 13 15:30:25 wlceventd: wlceventd_proc_event(685): wl0.1: Auth 1C:90:FF:aa:bb:cc, status: Successful (0), rssi:0
Dec 13 15:30:25 wlceventd: wlceventd_proc_event(645): wl0.1: Deauth_ind 1C:90:FF:aa:bb:cc, status: 0, reason: Unspecified reason (1), rssi:0
Dec 13 15:30:25 wlceventd: wlceventd_proc_event(685): wl0.1: Auth 1C:90:FF:aa:bb:cc, status: Successful (0), rssi:0
Dec 13 15:30:25 wlceventd: wlceventd_proc_event(645): wl0.1: Deauth_ind 1C:90:FF:aa:bb:cc, status: 0, reason: Unspecified reason (1), rssi:0

It goes on like this constantly with ~10 entries per second. I thought that the MAC addresses involved are linked to a "Tommee Tippee Connected Sleep Clock" but I later found out this is not the case. I don't know for sure what / where the devices are and how they are auth-ing with my wireless network.

It is very annoying because it makes it hard to identify issues in the system log as it gets immediately full of these entries. I am also wondering if the entries and/or whatever is causing them could be the reason the router seems to fall apart every 7-8 days and just stop responding, needing a power off & on to get it working again?
I've just noticed this thread. I am having a similar issue with my new RT-AX86U Pro router. In my case, the entries are referring to my son's playstation (see my recent thread for further details). I agree, it's annoying, for the same reason you have stated. It also occurs if using Merlin firmware.
 
Hi all,


just found this thread on google. I work for a UK ISP and for the last month we've been seeing wifi auth floods against our APs from Tuya Smart Inc devices at buildings we provide services to. We've identified at our particular buildings they appear to be Caldo heaters which look to be tuya smart inc based. I ran a wireless packet capture and basically the devices in an unconfigured factory default state send out repeated auth requests to any SSID they see broadcasting - clearly a firmware bug.

in our case there are 100s of these devices installed across the building and they are essentially DoSing every AP - great fun.

Enclosed an extract from the packet capture if anyone is curious

1704378860748.png



Just thought id post this for anyone else seeing these auth floods.

thanks


Jamie
 
I ran a wireless packet capture and basically the devices in an unconfigured factory default state send out repeated auth requests to any SSID they see broadcasting - clearly a firmware bug.
Thank you very much for this, I think it helps to explain a lot - when you say DoSing every AP do you mean they are crashing them? I'm still not sure what is causing my AX68U to gum up but did wonder if it was this auth spam!
 
Thank you very much for this, I think it helps to explain a lot - when you say DoSing every AP do you mean they are crashing them? I'm still not sure what is causing my AX68U to gum up but did wonder if it was this auth spam!
Yeah, in our case due to the overwelming amount of auth's hitting the APs its causing them to drop any connected clients on both radios. When I had that unit plugged in at home for testing my Macbook was getting disassociated from my home Ruckus AP.. and that was with just a single heater plugged in.

So theres a good chance it is that.
 
I'm glad I'm not the only one with the mac log spam confirming its a wider issue and not just me.

I don't own any of these Tuya Smart devices or caldo heaters.
No new devices has been added/connected on my network.

The 1C:90 log spam MAC belongs to nothing that I have connected.
Like mentioned in my last post a clean reset didn't fix it so i loaded my previous settings back.

Ive blocked the MAC in [ Wireless MAC Filter ] set to reject in both 2g and 5g wireless bands.
My log is back to normal showing my connected devices. temp fix i guess.


The only thing that has updated over the past month is [ "Signature version" 2.384 Updated : 2023/10/18 03 ] I'm not sure if that can bring these problems.

j4mbob

mentions a UK ISP. My virgin hub 5 updated at some point to the latest firmware.
 
Last edited:
It could be another IoT product thats Tuya Smart Inc based but sold under a different brand name, hence the Tuya MAC OUI. Also these things just appear to spam any SSID they can hear - its not forced to be a device within your house - if any neighbours etc have any of these devices and your AP/router is within range it'll spam auth frames at it - so changing your SSID for instance wont make any difference. its really, really shi*ty behaviour.

Regarding blocking, I'm not sure if it will fully work - the log entries might have gone but the device is still sat there sending auth frames and mostly likely consuming resources on the AP/Router having to deal with it.
 
I didn't have much success in blocking the MACs in the end, I thought it worked but turned out it didn't. I agree about the sh!tty behaviour, makes it basically impossible to do anything about it if the devices aren't yours or under you control.

I only noticed it recently, about the same time I updated my AX68U to 3.0.0.4.388_24231 and we got solar panels installed - but I can't be sure it is linked to either of these things, could be a neighbour getting some new smart devices or something. Doesn't help that my logs always show the rssi as 0 so I can't try to determine how far they are from the router.
 
So with the Caldo heater at least, this issue only manifests when the device is in its factory default unconfigured state. Configuring the device via the manufactuers App and giving it a specific network to connect to stops it spamming and it connects to that particular network and functions correctly
 
So with the Caldo heater at least, this issue only manifests when the device is in its factory default unconfigured state. Configuring the device via the manufactuers App and giving it a specific network to connect to stops it spamming and it connects to that particular network and functions correctly
can you confirm if your getting spammed from the 1c:90 address.

hiding the SSID broadcast might help also - depends if it a global issue regarding these heaters. for now i cant say if my neighbor has one, bit of random question to ask them but its going to get asked next time i see them.
 
I'm not sure if I'm emailing the right company but well see when this company replys.

email sent
ticket created through support

service@tuya.com
(001)844-672-5646
 
Last edited:
I use a set of Feit smart bulbs which are labeled Tuya Smart, and I saw the same type of activity with repeated DHCP request activity at a fixed time like 2 minutes way before 1/2 of lease. Lots of NTP too. I watched as more and more devices developed the same activity. Not all of them bulbs or from that manufacturer. WAN response was down per speed test. I took the time to:
1 - RESET all devices and left them off the network
1a - Reset the router and reinitialized disk; clean setup using new router name and DDNS name
2 - Created a guest net without LAN access
3 - disabled B and made 2.4 GHz N only
4- reinitialized the devices from #1 onto the guest network via bluetooth.
5 - set a country ban list in SkyNet

That quieted everything down, and I noticed that the initial problem device which would NOT reconnect without a router reboot if the ISP rebooted the cable modem now reconnects when router or/and modem reboots. I ran several scans on laptops etc. because the activity LOOKED like a hack, but I didn't have anything solid. AND I get consistently 1gb+ speed tests results.
 
Last edited:
Yeah the 1c:90 oui was the main one I was seeing. Was two others but not in front of laptop at the moment to grab em.

And yes that’s the right company. I also tried using their contact us form earlier to see if I get any kind of response back.


can you confirm if your getting spammed from the 1c:90 address.

hiding the SSID broadcast might help also - depends if it a global issue regarding these heaters. for now i cant say if my neighbor has one, bit of random question to ask them but its going to get asked next time i see them.
 
Will setting up a Guest 2.4 Ghz network special for IoT devices like Tuya a good idea?
That's what I did. Yes...and be sure to use Bluetooth to add the device so you don't have to give the network LAN access.
 
Just as I was catching up with this thread a few minutes ago my router rebooted itself (which is not what normally happens, it normally grinds to a halt and has to be manually rebooted) - here are some system log extracts:

Code:
Jan  4 23:11:13 wlceventd: wlceventd_proc_event(685): wl0.1: Auth 1C:90:FF:24:44:0A, status: Successful (0), rssi:0
Jan  4 23:11:13 wlceventd: wlceventd_proc_event(645): wl0.1: Deauth_ind 1C:90:FF:24:44:0A, status: 0, reason: Unspecified reason (1), rssi:0
Jan  4 23:11:13 wlceventd: wlceventd_proc_event(685): wl0.1: Auth 1C:90:FF:24:44:0A, status: Successful (0), rssi:0
Jan  4 23:11:13 wlceventd: wlceventd_proc_event(645): wl0.1: Deauth_ind 1C:90:FF:24:44:0A, status: 0, reason: Unspecified reason (1), rssi:0
Jan  4 23:11:13 wlceventd: wlceventd_proc_event(685): wl0.1: Auth 1C:90:FF:24:44:0A, status: Successful (0), rssi:0
Jan  4 23:11:13 wlceventd: wlceventd_proc_event(645): wl0.1: Deauth_ind 1C:90:FF:24:44:0A, status: 0, reason: Unspecified reason (1), rssi:0
Jan  4 23:11:13 wlceventd: wlceventd_proc_event(685): wl0.1: Auth 1C:90:FF:24:44:0A, status: Successful (0), rssi:0
Jan  4 23:11:13 wlceventd: wlceventd_proc_event(645): wl0.1: Deauth_ind 1C:90:FF:24:44:0A, status: 0, reason: Unspecified reason (1), rssi:0
Jan  4 23:11:15 acsd: eth7: Selecting 5g band ACS policy
Jan  4 23:11:15 acsd: acs_init_run(1111): acs_start eth7 cannot select chanspec with the wrong info
Jan  4 23:11:15 wlceventd: wlceventd_proc_event(685): wl0.1: Auth 1C:90:FF:24:14:13, status: Successful (0), rssi:0
Jan  4 23:11:15 wlceventd: wlceventd_proc_event(645): wl0.1: Deauth_ind 1C:90:FF:24:14:13, status: 0, reason: Unspecified reason (1), rssi:0
May  5 06:05:06 crashlog: LOG
...
May  5 06:05:06 crashlog: <4>
May  5 06:05:06 kernel: Virtual kernel memory layout:
May  5 06:05:06 crashlog: <4>
May  5 06:05:06 kernel:     vmalloc : 0xffffff8000000000 - 0xffffffbdffff0000   (   247 GB)
May  5 06:05:06 crashlog: <4>hotplug triggered out of memory codition (oom killer not called): gfp_mask=0x201da, order=0, oom_score_adj=0
May  5 06:05:06 kernel:     vmemmap : 0xffffffbe00000000 - 0xffffffbfc0000000   (     7 GB maximum)
May  5 06:05:06 crashlog: <4>
May  5 06:05:06 crashlog: <4>CPU: 0 PID: 9876 Comm: hotplug Tainted: P           O    4.1.52 #2
May  5 06:05:06 kernel:               0xffffffbe00000000 - 0xffffffbe00e00000   (    14 MB actual)
May  5 06:05:06 crashlog: <4>Hardware name: Broadcom-v8A (DT)
May  5 06:05:06 kernel:     fixed   : 0xffffffbffabfd000 - 0xffffffbffac00000   (    12 KB)
...
May  5 06:05:06 crashlog: <6>[ pid ]   uid  tgid total_vm      rss nr_ptes nr_pmds swapents oom_score_adj name
...
May  5 06:05:06 crashlog: <6>[15923]     0 15923   130988   130164     260       2        0             0 acsd2

The log shows a table of processes and it looks to me like acsd2 is taking up by far the most memory if I am reading it correctly - no idea what that process is or does though. When I search for the "out of memory" string I get the following results:

Code:
May  5 06:05:06 crashlog: <4>hotplug triggered out of memory codition (oom killer not called): gfp_mask=0x201da, order=0, oom_score_adj=0
May  5 06:05:06 crashlog: <4>swmdk triggered out of memory codition (oom killer not called): gfp_mask=0x201da, order=0, oom_score_adj=0
May  5 06:05:06 crashlog: <4>eapd triggered out of memory codition (oom killer not called): gfp_mask=0x201da, order=0, oom_score_adj=0
May  5 06:05:06 crashlog: <4>date triggered out of memory codition (oom killer not called): gfp_mask=0x200da, order=0, oom_score_adj=0
May  5 06:05:06 crashlog: <4>acsd2 triggered out of memory codition (oom killer not called): gfp_mask=0x201da, order=0, oom_score_adj=0
May  5 06:05:06 crashlog: <0>Kernel panic - not syncing: Reboot due to persistent out of memory codition..

Does anyone know whether this kind of crash could be caused by the auth / deauth spam we've been discussing here? I could attach the complete system log if it would help.
 
Just checked the system log on my ASUS RT-AX88U and I am also getting spammed with this stuff constantly!

I don't have any Tuya devices and the mac address doesn't appear to be one of mine.
Code:
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:48:51 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:51 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:48:51 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:51 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:48:51 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:51 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:48:56 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:56 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:48:56 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:56 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:49:01 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:49:01 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:49:06 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:49:06 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:49:11 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:49:11 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0

Need to see if I can find out how long this has been going on for
 
Just checked the system log on my ASUS RT-AX88U and I am also getting spammed with this stuff constantly!

I don't have any Tuya devices and the mac address doesn't appear to be one of mine.
Code:
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:46 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:48:51 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:51 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:48:51 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:51 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:48:51 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:51 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:48:56 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:56 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:48:56 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:48:56 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:49:01 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:49:01 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:49:06 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:49:06 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0
Jan  5 20:49:11 wlceventd: wlceventd_proc_event(645): eth6: Deauth_ind FC:67:1F:C5:69:CF, status: 0, reason: Unspecified reason (1), rssi:0
Jan  5 20:49:11 wlceventd: wlceventd_proc_event(685): eth6: Auth FC:67:1F:C5:69:CF, status: Successful (0), rssi:0

Need to see if I can find out how long this has been going on for
See what disabling wifi6 on the 2.4 Ghz band does for you.
 

Similar threads

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