2

hostapd.conf:

# 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>). If a BSSID is configured for
# every secondary BSS, this limitation is not applied at hostapd and other
# masks may be used if the driver supports them (e.g., swap the locally
# administered bit)
#
# 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

The last point is violated by hostap generated by LEDE 17.01.2 :(. The multiple interfaces were created using the LUCI web interface. I don't believe this changed since OpenWrt 15.05 either.

interface=wlan0
ctrl_interface=/var/run/hostapd
disassoc_low_ack=1
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
wpa_passphrase=hunter2
auth_algs=1
wpa=2
wpa_pairwise=CCMP
ssid=VOYAGER2091-90-jenkins
wpa_key_mgmt=WPA-PSK
okc=0
disable_pmksa_caching=1
bssid=74:44:01:86:42:d4


bss=wlan0-1
ctrl_interface=/var/run/hostapd
disassoc_low_ack=1
preamble=1
wmm_enabled=1
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
wpa_passphrase=hunter2
auth_algs=1
wpa=2
wpa_pairwise=CCMP
ssid=VOYAGER2091-alan
wpa_key_mgmt=WPA-PSK
okc=0
disable_pmksa_caching=1
bssid=76:44:01:86:42:d4

Why does hostapd say it requires distinct BSSIDs? What are the possible results of violating this?

In previous versions, I've had problems even creating multiple wifi networks like this. After switching to this LEDE release, it seems able to create the networks OK. However, moving away from the access point to room B, often one network shows up but not the other. (Client is Fedora 26 with an Intel wireless card). But this is within usable range, and if I had already connected to one of the networks, I think it is always able to remain connected when moving to room B. So I'm slightly suspicious about this business with BSSIDs.

  • 1
    Ummm they look distinct to be, one starts 74 the other 76? – user1998586 Aug 28 '17 at 7:16
0

Ummm they look distinct to me, one starts 74 the other 76? – user1998586

Ah. What confused me is that you have to check the part which I expected to be the OUI.

The original Netgear OUI appears to be 74:44:01, as used on my WNDR3800. This gets used on wlan0 (2.4Ghz), wlan1 (5Ghz), and eth1 (WAN).

103: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 74:44:01:86:42:d4 brd ff:ff:ff:ff:ff:ff
107: wlan1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 74:44:01:86:42:d6 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000
    link/ether 74:44:01:86:42:d5 brd ff:ff:ff:ff:ff:ff

The other interfaces appear to use different OUIs which do not show as being registered. But this is because the Universal/Local bit, 0x02, has been set (meaning Locally assigned). Each BSSID is distinct.

104: wlan0-1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 76:44:01:86:42:d4 brd ff:ff:ff:ff:ff:ff
108: wlan1-1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 76:44:01:86:42:d6 brd ff:ff:ff:ff:ff:ff
109: wlan1-2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 72:44:01:86:42:d6 brd ff:ff:ff:ff:ff:ff
113: wlan1-3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 7e:44:01:86:42:d6 brd ff:ff:ff:ff:ff:ff
121: wlan1-4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 7a:44:01:86:42:d6 brd ff:ff:ff:ff:ff:ff
161: wlan1-5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 66:44:01:86:42:d6 brd ff:ff:ff:ff:ff:ff

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000
    link/ether 76:44:01:86:42:d4 brd ff:ff:ff:ff:ff:ff
65: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 76:44:01:86:42:d4 brd ff:ff:ff:ff:ff:ff
66: eth0.1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether 76:44:01:86:42:d4 brd ff:ff:ff:ff:ff:ff

The sequence of generated MAC addresses is not quite clear to me. However it seems to reproduce if I delete the last network and then re-create it.

I'm not sure why eth0 / br-lan has been assigned the same MAC address as wlan0-1, or whether that could cause some other problem. br-lan does not include wlan0-1; the only member of the bridge is eth0.1.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.