cancel
Showing results for 
Search instead for 
Did you mean: 

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

dpwhite
Level 9
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
1,990 Views
11 REPLIES 11

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...

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