How to block a MAC from connecting to GS-AX3000?

[dpwhite]

I was working to try and resolve an entirely different issue and I happened to look at the list of DHCP leases shown in the System Log area of my GS-AX3000. I saw the following entry.

* 192.168.1.210 cc:4b:73:9a:90:a8 162:08:30

The IP address was immediately unfamiliar as I assign almost 100% of my devices manually. Looking in the system log I see entries like these

Sep 13 11:55:50 wlceventd: wlceventd_proc_event(527): eth6: Auth CC:4B:73:9A:90:A8, status: Successful (0), rssi:-20
Sep 13 11:55:50 wlceventd: wlceventd_proc_event(556): eth6: Assoc CC:4B:73:9A:90:A8, status: Successful (0), rssi:-20
Sep 13 11:55:53 wlceventd: wlceventd_proc_event(508): eth6: Disassoc CC:4B:73:9A:90:A8, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Sep 13 11:55:53 wlceventd: wlceventd_proc_event(508): eth6: Disassoc CC:4B:73:9A:90:A8, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Sep 16 09:39:51 wlceventd: wlceventd_proc_event(527): eth6: Auth CC:4B:73:9A:90:A8, status: Successful (0), rssi:-21
Sep 16 09:39:51 wlceventd: wlceventd_proc_event(556): eth6: Assoc CC:4B:73:9A:90:A8, status: Successful (0), rssi:-21
Sep 16 09:39:54 wlceventd: wlceventd_proc_event(508): eth6: Disassoc CC:4B:73:9A:90:A8, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Sep 16 09:39:54 wlceventd: wlceventd_proc_event(508): eth6: Disassoc CC:4B:73:9A:90:A8, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0

I don't know what this is. But I sure do not want it connecting and it makes me wonder... On my old Netgear R6400, I was able to specifically deny access entirely to one or more, given MAC addresses. I cannot seem to find such a function on my new Asus router. I must be missing something. Please help.

I also presume, but do not really KNOW, that a DHCP lease is not created until/unless a device successfully connects - meaning it has passed in valid credentials. Is this true? Or could this just be the result of someone's phone passing by with wifi on in the street?

Thanks

[dpwhite]

I decided to google a dmesg error I was getting:

CFG80211-ERROR) wl_cfg80211_change_station : WLC_SCB_AUTHORIZE sta_flags_mask not set

and found this discussion. It suggested disabling protected management frames - about which I know NOTHING. But doing that solved the problem. Sorry for all the bother...

[dpwhite]

Murph_9000 wrote:
Auth and Assoc successful makes me think it's successfully authenticating to the wireless network. DHCP shouldn't be possible to an unauthenticated client (in a closed network, open obviously allows anyone past the gate). It's almost certainly a device that has the pre-shared key.

I just did a test with a foreign device. I tried to connect it to my wifi providing a key that is random and wrong. In the system log I see a series of the following:

Sep 19 09:10:32 wlceventd: wlceventd_proc_event(527): eth5: Auth 5C:AF:06:65:F3:EF, status: Successful (0), rssi:0
Sep 19 09:10:32 wlceventd: wlceventd_proc_event(556): eth5: Assoc 5C:AF:06:65:F3:EF, status: Successful (0), rssi:-42
Sep 19 09:10:36 wlceventd: wlceventd_proc_event(491): eth5: Deauth_ind 5C:AF:06:65:F3:EF, status: 0, reason: Deauthenticated because sending station is leaving (or has left) IBSS or ESS (3), rssi:-44

And no IP is ever assigned. So I am forced to concur that the MAC in question is from a device having the pre-shared key.

Thanks