pfSense

The code responsible for this is in the function eth_get in usr.sbin/wpa/l2_packet.c of the FreeBSD source code. It simply takes the name of the device and a buffer that the address will be copied into.

From ifconfig code:

        DEF_CLONE_CMD_ARG("wlanaddr",   set80211clone_wlanaddr),
        DEF_CLONE_CMD_ARG("wlanbssid",  set80211clone_wlanbssid),

so the ifconfig command should be

ifconfig $wlan_clone wlanbssid $bssid
ifconfig $wlan_cloen wlanaddr $macaddr

It seems it actually can create a clone with a different bssid if you specify a value for wlanaddr when you create it. However, the parent MAC must match when you create the clone, and this workaround only works for the first one.

One other possible workaround is to make sure ether and bssid match before running hostapd and only change ether after. I had implemented a variation of this at one point when a workaround had been required for hostapd to work on multiple VAP's at all.

This is not something that was ever resolved. Either hostapd should be fixed or a workaround should be put in place (one that works for multiple access points on the same card). If it won't be fixed for 2.0, then the target version should be changed.

Can you state an example of this?

If i get you right and this is the same as form vlan interfaces than its by design that a clone cannot have a different mac than its hw. This is true even for vlans so do not look around for it and it needs patches for it to work.

Each wireless clone has two different types of MAC addresses - in ifconfig, one is labeled ether and one is labeled bssid. By default it gets both from the parent when the clone is created, but we only allow changing the one labeled ether. This is fine, because the clones shouldn't be given a bssid other than what ifconfig gives them anyway (they don't need to be the same, but all have to match a certain mask).

When hostapd used to read the MAC from the wrong interface (the parent instead of the clone), it was easy to change what MAC address hostapd would receive without changing either MAC on the clone. During this time before it was fixed, I had done tests for what was needed for hostapd to function correctly. In all cases where I made hostapd get the same value as the bssid of the clone, it would work properly, regardless of the value of ether reported by ifconfig.

My hypothesis is that hostapd only needs to know the wireless MAC (the bssid) because it only works on the whole wireless frames, not the packets contained within, so it doesn't need to know the addresses within.

One way to test this: you can start hostapd with ether matching bssid and once started you can change ether to anything you want and clients can still connect regardless of whether ether is still matching bssid. If you start hostapd with ether not matching bssid, clients will not be able to connect, and changing ether to match bssid afterward will still not allow them to connect, since it only reads this value at startup.

The fact that it only reads the value at startup is not the issue, however. The issue is that it is simply reading the wrong value. It must always be using whatever bssid is; the MAC that ifconfig calls ether is not supposed to have any relevance to whether it is working or not.

If you use an unpatched hostapd, it makes this easier to test to see what is going on, because you can directly affect what MAC value it will get at startup by modifying the MAC of the parent interface (after you've already created the clones).

It doesn't really need more testing, though. I've already tested this extensively; I just don't know enough to make working code that gets the bssid, to use in the function I had stated earlier. When I've made separate test utilities to get the bssid, taking code from other programs, they've only crashed.

Well by just reading the supplied config file it states

##### Multiple BSSID support ##################################################
#
# Above configuration is using the default interface (wlan#, or multi-SSID VLAN
# interfaces). Other BSSIDs can be added by using separator 'bss' with
# default interface name to be allocated for the data packets of the new BSS.
#
# hostapd will generate BSSID mask based on the BSSIDs that are
# configured. hostapd will verify that dev_addr & MASK == dev_addr. If this is
# not the case, the MAC address of the radio must be changed before starting
# hostapd (ifconfig wlan0 hw ether <MAC addr>).
#
# BSSIDs are assigned in order to each BSS, unless an explicit BSSID is
# specified using the 'bssid' parameter.
# If an explicit BSSID is specified, it must be chosen such that it:
# - results in a valid MASK that covers it and the dev_addr
# - is not the same as the MAC address of the radio
# - is not the same as any other explicitly specified BSSID
#
# Please note that hostapd uses some of the values configured for the first BSS
# as the defaults for the following BSSes. However, it is recommended that all
# BSSes include explicit configuration of all relevant configuration items.
#
#bss=wlan0_0
#ssid=test2
# most of the above items can be used here (apart from radio interface specific
# items, like channel)

#bss=wlan0_1
#bssid=00:13:10:95:fe:0b

To me it sounds reasonable!
So the bssid should be in a mask of the ether address?!

Keep in mind that hostapd was designed as a tool to use for every aspect of configuring the wireless interface on Linux. As far as I know, the FreeBSD version only supports a small subset of the features supported on Linux. I'll try it anyway, though. If this can at least tell it which BSSID to use internally, overriding what it would have read with its eth_get function, it would be sufficient to use for a workaround.

However, assuming it does anything at all, if it only changes the BSSID and still uses eth_get to read the value it is going to use internally, this will accomplish nothing.

Tried that hostapd configuration setting and got "bssid item not allowed for the default interface and this driver", so it is apparently one of the options that isn't supported by the FreeBSD version.

When using this patch it causes issues when hostapd is run at startup, preventing clients from associating. When hostapd is run again later, it doesn't have the issue, though. I'm unsure of the exact cause, but currently the patch is not ready to be used.