I see one 'rogue' MAC address (EA:06:02:EB:04:5C) in your log excerpt. If it was a stranger walking by, their device would not be able to authenticate without your wifi password, but your log shows that authentication & association were successful for that unknown MAC.
A
OUI lookup on that MAC address (EA:06:02) produces no results (vendor ID not found), which could possibly mean the offending device, as Colin suggested, is using a spoofed/fake MAC address, aka
Private Address in iOS; and Randomized MAC in Android OS. The locally-assigned MAC address is unique to each network SSID, so as to
prevent tracking of your device across different networks & hotspots as you travel around. It's a smart idea to use random MACs with public wifi, but not so good on your private network, like at home with statically-assigned IPs, when you need to know whose devices are connecting to your wifi.
You could, as I have done, enable the Wireless MAC filter on the 2GHz band (in Accept Mode) and populate the filter list with the MACs of all of your known devices. This will prevent all
unknown devices from connecting on the 2.4GHz band. Since the 5GHz signal doesn't penetrate through walls or propagate nearly as far as 2GHz, I leave MAC filtering disabled on the 5GHz band, which will allow nearby devices to connect, whether known or unknown. Using this method, guest devices can connect to our 5GHz wifi
if they are within physical proximity of the access points, like inside of our building, but not from the outside.
Thanks. That was only a part of the log. There's a bunch of other devices I've seen that exhibit similar behaviour in the log, some of these do have vendors (samsung, apple, oneplus). Thing is, they show as associated but immediately get a deauth. I was just thinking its people walking by because it looks like its mostly mobile devices. The pattern in the logs for these unknown MACs are always the same. It associates, then deauth a few seconds later. This doesn't happen with my devices. Some more examples:
Oct 14 14:37:33 syslog: WLCEVENTD wlceventd_proc_event(500): eth1: Auth 64:9A:BE:3D:75:08, status: Successful (0)
Oct 14 14:37:33 syslog: WLCEVENTD wlceventd_proc_event(529): eth1: Assoc 64:9A:BE:3D:75:08, status: Successful (0)
Oct 14 14:37:47 syslog: WLCEVENTD wlceventd_proc_event(466): eth1: Deauth_ind 64:9A:BE:3D:75:08, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Oct 14 14:49:36 syslog: WLCEVENTD wlceventd_proc_event(500): eth1: Auth 8E:56:E3:A9:A0:73, status: Successful (0)
Oct 14 14:49:36 syslog: WLCEVENTD wlceventd_proc_event(529): eth1: Assoc 8E:56:E3:A9:A0:73, status: Successful (0)
Oct 14 14:49:50 syslog: WLCEVENTD wlceventd_proc_event(466): eth1: Deauth_ind 8E:56:E3:A9:A0:73, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Oct 14 08:01:31 syslog: WLCEVENTD wlceventd_proc_event(500): eth1: Auth 10:8E:E0:37:67:2C, status: Successful (0)
Oct 14 08:01:31 syslog: WLCEVENTD wlceventd_proc_event(529): eth1: Assoc 10:8E:E0:37:67:2C, status: Successful (0)
Oct 14 08:01:40 syslog: WLCEVENTD wlceventd_proc_event(466): eth1: Deauth_ind 10:8E:E0:37:67:2C, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3)
Oct 14 08:01:41 syslog: WLCEVENTD wlceventd_proc_event(466): eth1: Deauth_ind 10:8E:E0:37:67:2C, status: 0, reason: Class 3 frame received from nonassociated station (7)
Oct 14 08:01:41 syslog: WLCEVENTD wlceventd_proc_event(466): eth1: Deauth_ind 10:8E:E0:37:67:2C, status: 0, reason: Class 3 frame received from nonassociated station (7)
Oct 14 08:01:41 syslog: WLCEVENTD wlceventd_proc_event(466): eth1: Deauth_ind 10:8E:E0:37:67:2C, status: 0, reason: Class 3 frame received from nonassociated station (7)
Oct 14 08:01:41 syslog: WLCEVENTD wlceventd_proc_event(466): eth1: Deauth_ind 10:8E:E0:37:67:2C, status: 0, reason: Class 3 frame received from nonassociated station (7)
Oct 14 08:01:41 syslog: WLCEVENTD wlceventd_proc_event(466): eth1: Deauth_ind 10:8E:E0:37:67:2C, status: 0, reason: Class 3 frame received from nonassociated station (7)
Oct 14 08:01:41 syslog: WLCEVENTD wlceventd_proc_event(466): eth1: Deauth_ind 10:8E:E0:37:67:2C, status: 0, reason: Class 3 frame received from nonassociated station (7)
Oct 14 08:01:41 syslog: WLCEVENTD wlceventd_proc_event(466): eth1: Deauth_ind 10:8E:E0:37:67:2C, status: 0, reason: Class 3 frame received from nonassociated station (7)
Oct 14 08:01:41 syslog: WLCEVENTD wlceventd_proc_event(466): eth1: Deauth_ind 10:8E:E0:37:67:2C, status: 0, reason: Class 3 frame received from nonassociated station (7)
Oct 14 08:01:41 syslog: WLCEVENTD wlceventd_proc_event(466): eth1: Deauth_ind 10:8E:E0:37:67:2C, status: 0, reason: Class 3 frame received from nonassociated station (7)
Oct 14 08:01:41 syslog: WLCEVENTD wlceventd_proc_event(466): eth1: Deauth_ind 10:8E:E0:37:67:2C, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
Oct 14 08:01:41 syslog: WLCEVENTD wlceventd_proc_event(466): eth1: Deauth_ind 10:8E:E0:37:67:2C, status: 0, reason: Class 2 frame received from nonauthenticated station (6)
I'm thinking this has to do with an unauthorized range extender that was connected to my router a few months ago. No idea how it got connected in the first place. Maybe through WPS which I had turned on back then? I blocked the range extender from the router back then, but maybe these are devices trying to connect through that range extender? Does it make sense? Also would you know if they were actually connected, would it show in the connected clients or offline client list at all? The only device I saw in the offline client list from several months ago was that unknown range extender.
Either way I changed the SSID, passwords, and turned off the 2.4GHz radio, and turned on MAC filter for only my devices.