If the MAC address of a wireless interface is set to something that does not match its BSSID, WPA does not work. Another related bug is that if the wireless clone is named with the parent interface name at the start (for example, ath0_wlan0), WPA will not work if the MAC address of the parent does not match the BSSID of the clone. They are both part of the same issue because it should be using the BSSID and not the MAC address.
This may also affect wpa_supplicant.
In usr.sbin/wpa/l2_packet.c: eth_get, it needs to get the BSSID of the interface instead of its MAC. hostapd appears to only read this information once, at startup. WPA works correctly if the MAC address matched the BSSID when hostapd was started. Changing it afterward seems to have no effect.
In the case of reading the MAC from the wrong interface, hostapd works if the parent's MAC matches the clone's BSSID, even if the clone's MAC does not match, showing that the clone's MAC does not need to match its BSSID for hostapd to function.
There is code for getting the BSSID in ifconfig's source code, though it is scattered a bit.
How-To-Repeat: Assign a different MAC address to a wireless clone interface and WPA does not work.
Or if you are naming the clones after the parent (ath0_wlan0, etc.):
If the parent's MAC address does not match the clone's BSSID, either from changing the parent's MAC or by having multiple clones created with the bssid option of ifconfig, WPA does not work.
new wireless mailing list
The file containing the code mentioned in the PR appears to have been
moved to contrib/wpa/src/l2_packet/l2_packet_freebsd.c and does still
use the code that causes hostapd to malfunction when the wireless MAC
and BSSID are configured to not be the same as each other.
This patch I made a while ago gets the BSSID instead of the
interface's ethernet MAC so that hostapd works even if the two do not
match. It is incomplete, however; because with this patch hostapd
does not work if the interface was not up already when hostapd was
started (it fails to acquire the BSSID). If there is some way to get
it without the interface being up, that would probably be better. It
must exist somewhere, because it is obviously already stored
somewhere, but I just do not know how to get it. If it is not
possible, it could be necessary to bring up the interface a bit sooner
For bugs that match the following
- Status Is In progress
- Untouched since 2018-01-01.
- Affects Base System OR Documentation
Reset to open status.
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.