RT-AX86U - system log spam from Tuya Smart device

[slurmsmckenzie]

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):

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?

 

[maxbraketorque]

I've found that any wifi device that has the same name as the router host name (in the LAN IP) section will constantly get bumped from the wireless network.

 

[slicktux]

It's strange because I am getting the same log entries from a Tuya device as well. 18:698:XX:XX:XX
Problem is the mac address does NOT belong to any of my devices.
I've tried changing my SSID with no avail.
Any ideas why I am getting these log entries for a device that is unknown to me?

 

[slurmsmckenzie]

Yes it is strange, I only have one "smart" device which is a Tommee Tippee Connected Smart Clock. It shows as being connected to my 2.4GHz network under the MAC 105:61:nn:nn:nn.

In addition to that I see these constant auth / de-auth messages in the system log relating to 1C:90:FF:aa:bb:cc and 1C:90:FF:xx:yy:zz - a MAC lookup shows these as being Tuya smart devices which I thought was related to the Tommee Tippee clock (which is also a Tuya smart device) but turns out they are not related.

Whilst it is annoying to know that something is causing all of this spam, it doesn't bother me too much apart from the fact that every 7-8 days my router is becoming unresponsive, losing the WAN connection and having to be manually powered off and on again. Given that these auth / de-auth messages are happening 5 times per second I am wondering it they are literally gumming up the router until it falls over. Even if this isn't the case they are filling up the system log with nonsense so I can't easily diagnose what the actual problem might be.

I wonder if it would help to use the Wirless MAC Filter to block the additional addresses?

 

[slicktux]

Yes it is strange, I only have one "smart" device which is a Tommee Tippee Connected Smart Clock. It shows as being connected to my 2.4GHz network under the MAC 105:61:nn:nn:nn.

In addition to that I see these constant auth / de-auth messages in the system log relating to 1C:90:FF:aa:bb:cc and 1C:90:FF:xx:yy:zz - a MAC lookup shows these as being Tuya smart devices which are associated with the Tommee Tippee clock. But that is already connected under a completely different MAC (currently showing 60+ hours connection time).

My theory is that the additional Tuya MACs are related to the messy way that the smart clock connects to the network. You have to use a phone app and normally have to connect your phone to the smart clock's own wifi to get it to work, it just suggests to me that the device has more than a single network connection.

Whilst it is annoying to know that the "smart" clock is causing all of this spam, it doesn't bother me too much apart from the fact that ever 7-8 days my router is becoming unresponsive, losing the WAN connection and having to be manually powered off and on again. Given that these auth / de-auth messages are happening 5 times per second I am wondering it they are literally gumming up the router until it falls over. Even if this isn't the case they are filling up the system log with nonsense so I can't easily diagnose what the actual problem might be.

I wonder if it would help to use the Wirless MAC Filter to block the additional addresses?

Wireless MAC Filter will work. . .as I had set it to reject that MAC address and I stopped seeing those log entries but mind you just because I can't see them in my logs does not mean my routers NOT having to constantly reject that MAC spamming the hell out of it.

You may be right that the clocks might have dual network cards but that is unlikely as it would cost more money to have two cards. While it is also possible to change the MAC address via software I don't see why they would need to do that for phone configuration as the same MAC could be used for connecting and setup.

Again I am getting the same log entries as you with exception of the interface: my deauth and auth are both happening on eth2 (2.4GHz band). . .it might be the same for you but just named differently.

Anyway, I am not taking this lightly and will further investigate why this random unknown device keeps trying to log into my router. . .at least that is what I am deducting from the log entries.

For now I turned off the 2.4GHz band so that I would not have to worry about it while I investigate. Before turning off the band I had changed my SSID and password and I even had PMF set to required and I was still getting spammed by that same freaken device. So 5GHz band for now until I can find out what is going on.

If anyone here could further elaborate what

Dec 15 18:00:40 wlceventd: wlceventd_proc_event(685): eth2: Auth 18:69:D8:XX:XX:XX, status: Successful (0), rssi:0
Dec 15 18:00:42 wlceventd: wlceventd_proc_event(645): eth2: Deauth_ind 18:69:D8:XX:XX:XX, status: 0, reason: Unspecified reason (1), rssi:0

means and the numbers inside the parentheses that would greatly help.

Thanks in advance!

 

[slicktux]

UPDATE:
Upon further investigation I was able to identify a rogue station that keeps hopping from network to network looking for open networks.

The RSSI of the culprit is -81 in the area my router was in originally. I've since moved it to the opposite side of my home and have also lowered the Tx and the deauth/auth logs have disapeared.

I hope if anyone encounters this problem, and its coming from a unknown device, that you can mitigate the spamming.
I've seen several posts of people having these same 'strange' logs with deauth and auths coming from a Tuya device and while many were coming from their own Tuya devices; the same can be coming from outside the network Tuya devices (as was the case for me) and being that its an IoT I would not trust their security.

Cheers!

 

[slurmsmckenzie]

So it could be that they aren't related to my existing smart device after all, maybe I've been assuming that where I shouldn't. I'll see if I can turn it off for a bit and check if the spam keeps happening, maybe it is coming from a neighbour. If so then they'll be going on the MAC block list!

EDIT - yep, unplugged the smart clock and the spam kept coming. No idea where these Tuya devices are that are trying to connect and weird that a few of us have noticed this issue recently. I can't really change the location of my router so I'm going to try adding them to the wireless MAC block list and see if it makes any difference.

EDIT #2 - adding the MACs to the wireless filter block list did nothing. In the end I have been able to stop the messages by turning off SSID broadcast of the guest network I setup specifically for the SolarEdge PV inverter. I am wondering whether the Tuya devices are related to the energy monitoring of the PV system. Still not sure whether these constant auth / de-auth events are causing issues or are anything to be concerned about, would appreciate any views on that?

 

[slicktux]

So it could be that they aren't related to my existing smart device after all, maybe I've been assuming that where I shouldn't. I'll see if I can turn it off for a bit and check if the spam keeps happening, maybe it is coming from a neighbour. If so then they'll be going on the MAC block list!

EDIT - yep, unplugged the smart clock and the spam kept coming. No idea where these Tuya devices are that are trying to connect and weird that a few of us have noticed this issue recently. I can't really change the location of my router so I'm going to try adding them to the wireless MAC block list and see if it makes any difference.

EDIT #2 - adding the MACs to the wireless filter block list did nothing. In the end I have been able to stop the messages by turning off SSID broadcast of the guest network I setup specifically for the SolarEdge PV inverter. I am wondering whether the Tuya devices are related to the energy monitoring of the PV system. Still not sure whether these constant auth / de-auth events are causing issues or are anything to be concerned about, would appreciate any views on that?

I looked into and found this problem because I kept getting connectivity issues; I noticed the constant log entries for deauth/auth and down the rabbit hole I went.

After the re-location I've since not had any problems with my connectivity because the spamming brute forces have stopped. You can setup a firewall to help mitigate any connectivity issues but your only taking up more resources because of a rogue device.

It's essentially a DoS attack, in a way, and because I can't find any information on the wlceventd_proc_event() function I can only try to replicate what the device is doing with a device of my own; that is continuous login attempts as I determined. (maybe I'll delve into the Merlin source for info on wlceventd_proc_event())

Or setup a honeypot and hope it connects, and stays connected, so that it can stop spamming your router?? ***Potentially illegal so tongue in cheek***

Or get a directional antenna and see if you can pin point that device and have its owner notified?? I might just do that myself but don't have the drive for that at the moment.

 

[slurmsmckenzie]

It seems strange to me that we would even see these events for devices that have not been given the SSID / passphrase for our networks, that is why I was thinking it might be part of the Solar Panel installation we had recently - we have connected a SolarEdge inverter to a guest wifi and there are energy monitors in the system which could be Tuya.

But also the "Unspecified reason (1), rssi:0" part does not seem great either, not very helpful. I found another thread which discusses it but it seems mainly to related to known devices that should be connecting and are being disconnected instead of unknown devices: https://www.snbforums.com/threads/r...deauth_ind-reason-unspecified-reason-1.84899/

@AdrianS - I see you had very similar problems recently, did you ever solve them? Were they related to known or unknown devices on the network?

What doesn't exactly help is that the main Wirless log file never shows the correct number of devices (e.g. the Network Map Client List shows 7 devices on 2.4GHz and 10 devices on 5GHz, Wireless log shows 4 devices on 2.4GHz and 6 devices on 5GHz).

 

[follower]

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):

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. The MAC addresses involved are linked to a "Tommee Tippee Connected Sleep Clock" that we use for my daughter and that I don't really have a choice about (WAF stuff). However the main clock connection uses a different MAC address and this stays connected just fine. The other two MAC addresses that are causing the spam are from the same device but I don't know what they are doing, it is probably linked to the janky wifi connection method they force you to use via an app (shudder).

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?

It's a compatibility issue. It's not Hacking at all.

 

[follower]

I looked into and found this problem because I kept getting connectivity issues; I noticed the constant log entries for deauth/auth and down the rabbit hole I went.

After the re-location I've since not had any problems with my connectivity because the spamming brute forces have stopped. You can setup a firewall to help mitigate any connectivity issues but your only taking up more resources because of a rogue device.

It's essentially a DoS attack, in a way, and because I can't find any information on the wlceventd_proc_event() function I can only try to replicate what the device is doing with a device of my own; that is continuous login attempts as I determined. (maybe I'll delve into the Merlin source for info on wlceventd_proc_event())

Or setup a honeypot and hope it connects, and stays connected, so that it can stop spamming your router?? ***Potentially illegal so tongue in cheek***

Or get a directional antenna and see if you can pin point that device and have its owner notified?? I might just do that myself but don't have the drive for that at the moment.

No, it's not an attack.

 

[follower]

I can say that it's not Hacking. Tuya is from China. Many companies are using Tuya's devices, codes and protocols with different brands, usually never heard unknown cheap brands. You don't even know it's from Tuya actually. Almost all of Codes are from Tuya. Anyone can modify their Codes easily, because it's like Open source code. That's why you guys can see Tuya something on your network even if you don't have any name of Tuya brand. 'Tommee Tippee Clock' is from Tuya actually. Their devices are always connected to Tuya's cloud server(China), Tommee Tippee too. Tuya devices have a lot of vulnerabilities that are never fixed. Tuya owners are always victims of attack, they don't even know they get hacked. I never recommend using Chinese devices.

 

[slurmsmckenzie]

It's a compatibility issue. It's not Hacking at all.

Thanks, I don't remember saying it was hacking though. I'm just trying to find out why I'm seeing these events so often and if they could be the cause of my router gumming up every 7-8 days and needing a manual reboot.

 

[follower]

Thanks, I don't remember saying it was hacking though. I'm just trying to find out why I'm seeing these events so often and if they could be the cause of my router gumming up every 7-8 days and needing a manual reboot.

Read my another reply please.

 

[slurmsmckenzie]

It's a compatibility issue. It's not Hacking at all.

I tried to politely point out that I never said it was hacking.

Read my another reply please.

I did read your other reply, I'm still not sure what you are saying regarding hacking (which I never mentioned anyway).

I can say that it's not Hacking.

Tuya owners are always victims of attack, they don't even know they get hacked

I appreciate any and all help but I'm not really sure what you are getting at here. But maybe I'm beyond help.

 

[follower]

I tried to politely point out that I never said it was hacking.

I did read your other reply, I'm still not sure what you are saying regarding hacking (which I never mentioned anyway).


I appreciate any and all help but I'm not really sure what you are getting at here. But maybe I'm beyond help.

I told you. It's a compatibility issue. How many times do I have to tell you about it? Your attitude is so strange. Don't you know the meaning of Compatibility?. 'Hacking' parts was for both you and slicktux. You guys were talking about it. He said it's like Hacking, not real Hacking but acting like Hacking. Anyway...

You have four options.
How to solve a compatibility issue?
1. Remove the issued device from the network.
2. Downgrade firmware.
3. Buy well known devices.
4. Modify and Rewrite the firmware of your Clock.

Me? I'll choose NO.1.

 

[sfx2000]

Well @follower - I don't think OP can change - the WAF factor, so he has to make it work...

Since this is a 2.4Ghz device, the normal caveats apply...

• Consider disabling 802.11ax for 2.4Ghz, there are compatibility issues here with devices that might not expect beacon and management frames with 11ax extended info
• If AirTime Fairness is an option - try toggling it - there are known issues with Asus/Broadcom and certain IoT oriented chipsets
• SmartConnect - not sure if this applies, but something to look at - I don't have an AX86U handy, so I'm not sure if this option is even present - but the deauth event suggests it might be trying to do something here...
• BeamForming - this is kind of a default fix - but try disabling explict/implicit beamforming for the 2.4GHz radios

Keep in mind that forum members here try to help, but this is all voluntary - worst case it reach out to Asus directly at their support address - if this is a product compat issue, it's something they should be made aware of...

 

[slicktux]

@slurmsmckenzie
Verify that that MAC address is indeed coming from one of your devices. . .if so its a "compatibility issue" and maybe try enabling b/n/g support in your router. Whatever the case the router should work with older devices as most are backwards compatible. If you do have PMF set to "required" that could be causing certain devices to try to connect constantly which would cause those log entries. . .set it to optional. . .or off.
In short, trust but verify...

If it is NOT a mac address that belongs to any of your devices then I'd say your in the same boat I was. This will require some forensics tools to determine whats going on in the air. If you can't move the router then mac filter should work just set it to reject that one culprit MAC address. . .try that again...keep an eye on your logs and try to find out why and when your router is 'glitching'

 

[slurmsmckenzie]

He said it's like Hacking, not real Hacking but acting like Hacking. Anyway...

Yes slicktux did mention that, but I didn't, which is why I responded as I did. You replied to my original post saying "it is not hacking" when I never said it was, that is all. I do appreciate all help and apologise if I have a strange attitude.

EDIT - yep, unplugged the smart clock and the spam kept coming.

Even though I originally thought it was the smart clock I now know that it is not. I don't really know what these devices are or how to find out so it is somewhat of a mystery to me and not clear that I want to solve the compatibility issue and allow these devices on the network. It also means I don't have the option to remove them as I don't know what/where they are. My question was about why I was seeing ~10 auth / de-auth events per second and if this could cause the router to stop working after 7-8 days - the answer that it is a compatibility issue is helpful but doesn't really answer that.

My best guess at the behaviour at this point is that the devices are bouncing between the 2.4GHz (eth6) and Guest network (wl0.1) and whenever the device gets an auth on one it de-auths from the other. But why this would happen and how these unknown devices would ever be able to auth with my 2.4GHz network when I have never given them the SSID / password, I do not know. I guess I'll never find out.

• Consider disabling 802.11ax for 2.4Ghz, there are compatibility issues here with devices that might not expect beacon and management frames with 11ax extended info
• If AirTime Fairness is an option - try toggling it - there are known issues with Asus/Broadcom and certain IoT oriented chipsets
• SmartConnect - not sure if this applies, but something to look at - I don't have an AX86U handy, so I'm not sure if this option is even present - but the deauth event suggests it might be trying to do something here...
• BeamForming - this is kind of a default fix - but try disabling explict/implicit beamforming for the 2.4GHz radios

Verify that that MAC address is indeed coming from one of your devices. . .if so its a "compatibility issue" and maybe try enabling b/n/g support in your router. Whatever the case the router should work with older devices as most are backwards compatible. If you do have PMF set to "required" that could be causing certain devices to try to connect constantly which would cause those log entries. . .set it to optional. . .or off.
In short, trust but verify...

If it is NOT a mac address that belongs to any of your devices then I'd say your in the same boat I was. This will require some forensics tools to determine whats going on in the air. If you can't move the router then mac filter should work just set it to reject that one culprit MAC address. . .try that again...keep an eye on your logs and try to find out why and when your router is 'glitching'

Thanks both, can confirm I have the following settings which was largely done to keep my Logitech Squeezeboxes happy:

• 802.11ax is disabled for 2.4GHz
• Wireless mode is auto with "b/g protection" enabled
• PMF is set to disabled
• SmartConnect and Roaming Assistant are both off
• BeamForming / MIMO are all off for 2.4GHz
• AirTime Fairness is off
• I have tried adding the MACs to the wireless filter to "reject" but it made no difference

I've not considered downgrading the firmware simply from a security perspective, is it common and advised to run firmware with known vulnerabilities?

I guess I'll just need to accept what is happening and maybe schedule a reboot of the router every 6-7 days and hope that this stops the issue where it falls apart and forces a manual reboot. Thanks all for help / thoughts.

 

[Diablo99]

Will setting up a Guest 2.4 Ghz network special for IoT devices like Tuya a good idea?