A month ago I tried to upgrade my TP-Link Archer C7 V2 to 18.06-RC1. My first tests failed as my Oneplus3 phone cannot connect to the wireless network. Then I rolled-back to the stable version.
Now I upgraded to 18.06-Final and the issue is still there. I did some more troubleshooting:
Hidden SSID and enabled MAC filtering -> phone cannot join
Non-hidden SSID and enabled MAC filtering -> working fine
Hidden SSID and disabled MAC filtering -> working fine
It seems newer android and iOS versions doing MAC randomization to increase privacy. So they are using random MAC address while they scanning for saved/known networks. If they find the network they using the unique/built-in MAC address to connecting the network.
It seems something changed in the behavior of LEDE/OpenWRT. Earlier Hidden-SSID and MAC filtering was working. Maybe MAC filtering only blocked authentication/connection packages and not the scanning packages. Now it seems both are blocked by MAC filtering.
I noticed something like this today from one of the mobile users that have a MI android phone. Last update on that device was on the 01-07-2018.
I noticed this exact same issue as soon as upgraded my Access Point Comfast CF-E380ACv2 to 18.06. However so far only this user has an issue connecting. What i did to test was.. I created a new Wi-Fi network, and i put all settings the same and disabled MAC Address filtering. As soon as i did that, the phone could connect. When I re-enabled MAC Address filtering and re-added the user's MAC, immediately i saw that this user could not connect again.
Again i repeat that this does not affect all devices.
However I think that this could definitely be a bug.
I would like the direct link where i could report this issue.
Likely that hostapd has been changed to not respond to probe requests from disallowed MACs. That isn't necessarily a bug, it could be considered a security enhancement. Questions about this should be sent to the hostapd developers.
Though hidden SSIDs and MAC filters offer no real enhancement to security. A userspace app like WiFi Analyzer will reveal the existence of hidden APs. The AP's SSID and (once connected) the client's real MAC are also transmitted in the clear over the air by clients.
This happened to me as well today, only in another scenario.
After an Android update on my Samsung phone it was not able to connect to my OpenWRT 18.06.0 AP anymore. It worked fine before the android update though.
My results are the same as:
Hidden SSID and enabled MAC filtering -> phone cannot join
Non-hidden SSID and enabled MAC filtering -> working fine
Hidden SSID and disabled MAC filtering -> working fine
Funny thing is, the AP was running 18.06.0 already and everything worked fine before the Android update, but after the update issues started to arise.
I'm having the same problem with OpenWrt 18.06.1 (r7258-5eb055306f). I have the problem only when connecting with MacBook Pro 2017. I noticed that when MAC filtering is enabled the MBP is unable to connect to the network (no network found). I can see it connecting with a (random) MAC address - if I add the address to the MAC filter, it connects OK - but only until next connect. It was working fine with Chaos Calmer.
And btw... about the suggestions on MAC filtering not being secure (that's the first response each time someone mentions MAC filtersing / Hidden SSID). My use case is this: if someone shares my wifi password with someone else - he won't be able to use it unless he changes his MAC address. It's not a protection against real hackers, though.
I'd also like to know if this is by design or a bug... I'm considering switching to an older version.
@mk24 Do you know in which version of openwrt/lede hostapd was updated?
In 18.06.1 I have:
# hostapd -v
hostapd v2.7-devel
User space daemon for IEEE 802.11 AP management,
IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator
Copyright (c) 2002-2017, Jouni Malinen <j@w1.fi> and contributors
I do see something related to "no_probe_resp" in 2.6 though it doesn't say it's for the MAC filter.
The issue is more of hiding the SSID than MAC filtering. Clients need to probe a hidden AP specifically by SSID (which reveals the SSID on the air(*), making a hidden SSID very trivial security). It would make sense to not respond to probes from unknown or unwanted clients.
It should work to unhide the SSID though you can continue MAC filtering. This is going to be more secure than using an old version. Hidden SSID is absolutely no protection against someone who knows the SSID because one of your friends told them.
Your own device will broadcast probes containing your hidden SSID (albeit with a random MAC) wherever you go whenever the radio is on but not connected,