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!

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

started some time in early december, the date of this thread was started december 13th.
so your on a rt ax88u and getting these things so it gets even wider not just a rt ax86u.

you also have a different address to us yours is showing as fc:67 but still links to tuya when mac lookup is used.



See what disabling wifi6 on the 2.4 Ghz band does for you.
wifi 6 disabled here on the 2.4 - still get spam.
 
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

started some time in early december, the date of this thread was started december 13th.
so your on a rt ax88u and getting these things so it gets even wider not just a rt ax86u.

you also have a different address to us yours is showing as fc:67 but still links to tuya when mac lookup is used.




wifi 6 disabled here on the 2.4 - still get spam.


FC:67 was one of the other Tuya OUI's I was seeing

By the way this spam is nothing todo with the router/AP you are using, any vendors AP/Router would see these same floods. My test AP was a Ruckus AP, the APs out in production that I first spotted this on were Huawei.

Its purely a broken, buggy client
 
See what disabling wifi6 on the 2.4 Ghz band does for you.
Thanks, I will try. Initially I blocked the mac with the wifi mac filtering, but that's probably not a great solution. I don't think I'd be using 2.4 Ghz on wifi 6 anyway, so nothing lost by disabling it.
Although I stopped blocking the mac and the spamming hasn't come back yet. I'll wait until it does and then disable wifi 6
 
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.
Where you still seeing the auth flood spam in the logs when it occurred?

If so, then yes this behaviour given the number of frames these things send out could well cause OOM issues on the AP/router and cause processes to crash.
 
Thanks, I will try. Initially I blocked the mac with the wifi mac filtering, but that's probably not a great solution. I don't think I'd be using 2.4 Ghz on wifi 6 anyway, so nothing lost by disabling it.
Although I stopped blocking the mac and the spamming hasn't come back yet. I'll wait until it does and then disable wifi 6
Disabling wifi6 on 2.4Ghz wont make any difference - it still auth floods the BSSID. Same with setting the SSID as hidden.
 
Where you still seeing the auth flood spam in the logs when it occurred?

If so, then yes this behaviour given the number of frames these things send out could well cause OOM issues on the AP/router and cause processes to crash.
Yes indeed, the first few lines of the log I pasted show the run-up to the crash - 8 auth/deauths in a single second! At least I can feel pretty confident about what the cause is, just wish I could do something about it
 
Disabling wifi6 on 2.4Ghz wont make any difference - it still auth floods the BSSID.
Evidenced by what/whom?
It's worked very well for myself as well as others here for tuya and esp32 devices.
I only suggested to try it. I never cr##ped on anyone else's thoughts. You found a fix for your particular problem - that doesn't make it a fix-all solution.
 
Hi, sorry, wasnt trying to crap on anyones thoughts , was just saying it wouldnt make any difference - see packet capture etc below:

frame highlighted is being sent to BSSID 70:ca:97:77:ec:94 by the Tuya device. 2nd screenshot is from wifi explorer showing the properties of that BSSID which shows it as a hidden SSID and g/n so not wifi6

1704457904807.png
 

Attachments

  • 1704457708649.png
    1704457708649.png
    133.7 KB · Views: 19
there are more threads here on the forum

 
[SOLVED] I have the exact same router (I have the Pro version) and I had the exact same issue.

My Network Info:
Router: RT-AX86U Pro
Firmware: 3.0.0.4.388_24199
AiMesh System w/ RT-AX3000 & RT-AX1800S Nodes:
1709442735027.png


Story Time:
I was going crazy trying to pin-point the exact device on my network causing the issue.

Here is what my System Logs were getting spammed with (pretty much once per second):
Mar 2 19:30:04 wlceventd: wlceventd_proc_event(685): wl0.1: Auth A0:92:08:98:C5:87, status: Successful (0), rssi:0
Mar 2 19:30:05 wlceventd: wlceventd_proc_event(645): wl0.1: Deauth_ind A0:92:08:98:C5:87, status: 0, reason: Unspecified reason (1), rssi:0
Mar 2 19:30:05 wlceventd: wlceventd_proc_event(685): wl0.1: Auth A0:92:08:98:C5:87, status: Successful (0), rssi:0
Mar 2 19:30:06 wlceventd: wlceventd_proc_event(645): wl0.1: Deauth_ind A0:92:08:98:C5:87, status: 0, reason: Unspecified reason (1), rssi:0

As everyone on this thread already knows: Tuya Smart Inc. owns the MAC Address range A0:92:08:00:00:00 - A0:92:08:FF:FF:FF

After ruling out of all my network devices 1 by 1, I came to the realization: this device was not mine! Probably a hacker or maybe an incompetent neighbor. Could also be a neighbor kid who thinks he is smart with some China-made wifi-hacker he bought off Temu/Alibaba, enough said.

Back at the ranch...
1. At one point I thought this was an issue with ASUS Smart Connect - so I disabled this feature and created separate 2.4 and 5 GHz SSIDs. I put all my IOT Devices on 2.4 GHz network.
(This Failed)
2. Doubling down on this possibility - I thought this could still be an issue with older IOT devices that may only support older authentication protocols (i.e. Smart TVs, Chromecasts, Apple TVs, Rokus, IP Cameras, Smart Plugs, Smart Switches, Ring Cameras, etc.) - So I spun up a guest network (2.4 GHz only) with WPA2-Personal Authentication. Since I didn't want to reconnect all these devices, I reused my existing SSID for this Guest Network, and created new SSIDs for my primary 2.4 and 5 GHz network - to be used exclusively for phones, laptops, and computers.
(This Failed)
3. Getting desperate now... I setup MAC Address Blacklist Filtering on both my 2.4 and 5 GHz networks.
(This Failed)
4. Admitting to myself I am not the smartest ASUS network geek out there; I turned to the interweb searching for help... I found this forum... It led me down a some rabbit holes [that I care not to expose], but I ultimately found the smoking gun:
wl0.1 is the Guest Network - Which has separate MAC Address Filter Settings!

@slurmsmckenzie - You too are getting spammed on your Guest Network SSID!

To fix the issue all you need to do is blacklist the problematic MAC Address on your Guest Network. This can be found in your Guest Network Settings as shown below:

Step 1:
1709442385415.png

Step 2:
1709442290137.png


I hope this post find you well. I fought this issue for months; I lost countless hours of sleep and stayed up many nights drinking beer and whiskey searching for answers. Tonight will be the first night I sleep sound!

Good luck, and have fun!

Rob
Cenero LLC - Control Systems Engineer
Knox Co - Manufacturing Engineer
Lucid Motors - NPI Project Engineer - Powertrain, High Voltage Electronics
 
I too had a bout with a Tuya Smart MAC address and the proverbial log spam. The MAC was: 70:89:76:BE:72:95
I was able to use the Wireless MAC filter to block it. That was over a month ago and now with the Wireless MAC filter off the problem has not come back...yet. I have a new neighbor and suspect it was one of their "Smart" devices that was not set up correctly.
 
I've seen this with Tuya smart sockets and I can reproduce it.

You start with up a new socket - or factory reset an existing one.

While it's in its "Fast flashing" mode (waiting for you to 'Add' it using the App) it spams your WiFi network with that MAC address, or a very similar one. You just see Auth / Deauth messages continuously.

It does that without even knowing the name of your WiFi network, so I'm guessing it just tries the strongest one it can see. (Unless there's some way to "broadcast" to all networks around you- I'm no expert on that)
 
Tuya manufactures various IoT devices, both under their own brand and under other brands like Merkury and Geeni.
 
Thanks for the updates, they sound encouraging - at the moment I am rebooting my AX68U on a schedule once per week to head off the crash that happens due to memory problems. I'll try the specific guest wifi filtering although I also get the spam on the main 2.4GHz SSID and filtering didn't help that as I recall.

I downloaded a Tuya app and searched for devices to add in my vicinity, came up with a smart light bulb so I think that is likely one of the offenders - some neighbour has bought a smart bulb and left it in pairing mode. Maybe I'll try and ask around!

If was able to filter out the guest network spam that might at least lessen the impact...
 
I downloaded a Tuya app and searched for devices to add in my vicinity, came up with a smart light bulb so I think that is likely one of the offenders - some neighbour has bought a smart bulb and left it in pairing mode.
Why don't you just connect to it with the app and put it in "Disco" mode.
See what happens.
I would.
 

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