Qual é a conseqüência da reutilização de valores BSSID?

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

O último ponto é violado pelo hostap gerado pelo LEDE 17.01.2 :(. As múltiplas interfaces foram criadas usando a interface web LUCI. Eu não acredito que isso tenha mudado desde o OpenWrt 15.05.

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

Por que o hostapd diz que requer BSSIDs distintos? Quais são os possíveis resultados de violar isso?

Nas versões anteriores, tive problemas até na criação de várias redes Wi-Fi como esta. Depois de mudar para esta versão LEDE, parece capaz de criar as redes OK. No entanto, afastando-se do ponto de acesso para a sala B, muitas vezes uma rede aparece, mas não a outra. (Cliente é o Fedora 26 com uma placa wireless Intel). Mas isso está dentro do alcance utilizável, e se eu já tivesse me conectado a uma das redes, acho que é sempre capaz de permanecer conectado quando estou indo para a sala B. Então, estou um pouco desconfiado sobre esse negócio com BSSIDs.

    
por sourcejedi 28.08.2017 / 00:48

1 resposta

0

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

Ah. O que me confundiu é que você tem que verificar a parte que eu esperava ser o OUI.

O Netgear OUI original parece ser 74:44:01 , como usado no meu WNDR3800. Isso é usado em wlan0 (2.4Ghz), wlan1 (5Ghz) e 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

As outras interfaces parecem usar diferentes OUIs que não são mostradas como sendo registradas. Mas isso ocorre porque o bit Universal / Local, 0x02, foi definido (significando atribuído localmente). Cada BSSID é distinto.

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

A sequência de endereços MAC gerados não está clara para mim. No entanto, parece se reproduzir se eu excluir a última rede e, em seguida, recriá-lo.

Eu não tenho certeza porque eth0 / br-lan recebeu o mesmo endereço MAC que wlan0-1, ou se isso poderia causar algum problema outro . br-lan não inclui wlan0-1; o único membro da ponte é eth0.1.

    
por 28.08.2017 / 10:15

Tags