Wireless maclist accept a wildcard character?

thedukesd · December 6, 2025, 8:05pm

Is there a wildcard character that can be used with maclist?
Something like
list maclist ‘ab:cd:ef:*’

purpose is to blacklist all mac addresses starting with ab:cd:ef to try to connect to the ap
reason is this:

daemon.debug hostapd: phy0-ap0: STA ab:cd:ed:uv:wx:yz IEEE 802.11: authentication OK (open system)
daemon.debug hostapd: phy0-ap0: STA ab:cd:ed:uv:wx:yz MLME: MLME-AUTHENTICATE.indication(ab:cd:ed:uv:wx:yz, OPEN_SYSTEM)
daemon.debug hostapd: phy0-ap0: STA ab:cd:ed:uv:wx:yz MLME: MLME-DELETEKEYS.request(ab:cd:ed:uv:wx:yz)
daemon.notice hostapd: phy0-ap0: STA ab:cd:ed:uv:wx:yz IEEE 802.11: did not acknowledge authentication response

a device that is not mine is spamming the logs with what u see above, blacklisting a single mac is bypassed by changing the uv:wx:yz while ab:cd:ed is always the same

L.E.:

changing the ap name does not help, looks to be done on purpose
finding the owner/location of the device is an impossible case
using a white list is not viable in this case (no control over some devices that need to connect to the ap that used random mac)

brada4 · December 6, 2025, 8:53pm

Upstream has no such functionality
REF: https://git.w1.fi/cgit/hostap/tree/hostapd/hostapd.conf#n313

Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button (red circle; this works best in the 'Markdown' composer view in the blue oval):

Remember to redact passwords, VPN keys, MAC addresses and any public IP addresses you may have:

ubus call system board
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall

slh · December 7, 2025, 4:00am

Apart from the cold hard facts above, MAC filters are the wrong answer anyways - regardless of the question.

thedukesd · December 7, 2025, 9:07am

config wifi-iface '123'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'edited'
        option encryption 'psk2+ccmp'
        option key 'edited'
        option short_preamble '0'
        option disassoc_low_ack '0'
        option wpa_group_rekey '86400'
        option wpa_strict_rekey '1'
        option isolate '1'
        option wpa_disable_eapol_key_retries '1'
        option tdls_prohibit '1'

this is the only relevant information and the fact that it's an ap on 2,4 Ghz band

I have no issue to share the mac of the offending device because it is not mine D8:D6:68:uv:wx:yz (uv:wx:yz is the part that is changing this is why i did not provided it because I do not even know what is the real one)

As i said in the initial post the log is flooded with:

daemon.debug hostapd: phy0-ap0: STA ab:cd:ef:uv:wx:yz IEEE 802.11: authentication OK (open system)
daemon.debug hostapd: phy0-ap0: STA ab:cd:ef:uv:wx:yz MLME: MLME-AUTHENTICATE.indication(ab:cd:ed:uv:wx:yz, OPEN_SYSTEM)
daemon.debug hostapd: phy0-ap0: STA ab:cd:ef:uv:wx:yz MLME: MLME-DELETEKEYS.request(ab:cd:ed:uv:wx:yz)
daemon.notice hostapd: phy0-ap0: STA ab:cd:ef:uv:wx:yz IEEE 802.11: did not acknowledge authentication response

after i added:

option macfilter 'deny'
list maclist 'd8:d6:68:ab:cd:ef'

all was good for 2 days, but after 2 days i started to see the same behaviour coming from d8:d6:68:uv:wx:yz , so clearly whoever does this saw that it got macfiltered and partially changed the mac. i do not know if this is some neighbour doing this or this is a compromise device, all I know is that this is not a device that i or someone else in the house is owning.

clearly going with deny is a no go, every x days, probably faster because other side is aware that i try to stop this, i will see another mac spamming the logs.
white list also does not work because i have some legit devices that I can not set to use a static mac and only operate on 2,4 Ghz band.

and when i say the log is flooded i mean that u see this in the log over and over with no delay:

Sun Nov 23 21:03:48 2025 daemon.debug hostapd: phy0-ap0: STA d8:d6:68:uv:wx:yz IEEE 802.11: authentication OK (open system)
Sun Nov 23 21:03:48 2025 daemon.debug hostapd: phy0-ap0: STA d8:d6:68:uv:wx:yz MLME: MLME-AUTHENTICATE.indication(d8:d6:68:uv:wx:yz, OPEN_SYSTEM)
Sun Nov 23 21:03:48 2025 daemon.debug hostapd: phy0-ap0: STA d8:d6:68:uv:wx:yz MLME: MLME-DELETEKEYS.request(d8:d6:68:uv:wx:yz)
Sun Nov 23 21:03:48 2025 daemon.notice hostapd: phy0-ap0: STA d8:d6:68:uv:wx:yz IEEE 802.11: did not acknowledge authentication response
Sun Nov 23 21:03:48 2025 daemon.debug hostapd: phy0-ap0: STA d8:d6:68:uv:wx:yz IEEE 802.11: authentication OK (open system)
Sun Nov 23 21:03:48 2025 daemon.debug hostapd: phy0-ap0: STA d8:d6:68:uv:wx:yz MLME: MLME-AUTHENTICATE.indication(d8:d6:68:uv:wx:yz, OPEN_SYSTEM)
Sun Nov 23 21:03:48 2025 daemon.debug hostapd: phy0-ap0: STA d8:d6:68:uv:wx:yz MLME: MLME-DELETEKEYS.request(d8:d6:68:uv:wx:yz)
Sun Nov 23 21:03:48 2025 daemon.notice hostapd: phy0-ap0: STA d8:d6:68:uv:wx:yz IEEE 802.11: did not acknowledge authentication response

elder_tinkerer · December 7, 2025, 9:25am

Do you mind to tell me more about this legit devices? I've never seen something like that, which will only use random MAC and can't be set to use a static MAC.
So i will know for the future which devices i have to avoid...

thedukesd · December 7, 2025, 9:35am

it is more then one:

wifi led strip
wifi outlets
wifi led light
i see them connecting to my wifi with random macs with no option to change this behaviour

2,4 ghz has a firewall rule to limit what those devices can access on internet, i would happy cut internet to them completly but some of them stop working...

replacing them come with the fact that I have no idea how the new devices will behave, i can get similar behaviour from the new ones.

yes I understand that using such devices can result in the wifi password getting compromised... there are some limitations in what can be done and what can't be done...

this 'd8:d6:68' is not my device, I blacklisted it first time after I checked that all other devices were happy working
in wifi connected devices u can happy see it as attempting to connect with no ip address assigned to it and this is what actually make me check what on earth is happening

brada4 · December 7, 2025, 10:16am

You can block them by bridge firewall, or inet firewall, there is a pull request for fw4 https://github.com/openwrt/firewall4/pull/74 to do that from GUI eventually.
But it will not stop hostapd logging.
You can use WPA3 or format strings in wifi AP name, have not heard of IoT doing well with those.