Closed lantis1008 closed 5 years ago
I don't have any mvebu devices, but tested on ar71xx and ipq40 and yes, still working.
root@Gargoyle:~# iw dev
phy#1
Interface wlan1-1
ifindex 20
wdev 0x100000004
addr ce:ea:ce:03:63:a1
ssid Guests 5GHz
type AP
channel 36 (5180 MHz), width: 20 MHz, center1: 5180 MHz
txpower 14.00 dBm
Interface wlan1
ifindex 18
wdev 0x100000003
addr 64:66:b3:4b:0e:98
ssid Gargoyle
type AP
channel 36 (5180 MHz), width: 20 MHz, center1: 5180 MHz
txpower 14.00 dBm
phy#0
Interface wlan0-1
ifindex 21
wdev 0x4
addr 22:99:23:b7:a9:f2
ssid Guests
type AP
channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz
txpower 18.00 dBm
Interface wlan0
ifindex 19
wdev 0x3
addr 64:66:b3:4b:0e:97
ssid Gargoyle
type AP
channel 11 (2462 MHz), width: 20 MHz, center1: 2462 MHz
txpower 18.00 dBm
That's good enough for me for now. Thanks! Also i appreciate your continued support, i hope you don't mind me calling on you for assistance/code review from time to time?
On mvebu devices with the 88W8964 wireless chip, the MAC address of any VAP must be within the mask 'FD:FF:FF:FF:FF:F0' of the first registered MAC on the interface (usually an AP). If we don't do this, the firmware will reject the packets, and we will be either unable to connect to the AP or the VAP depending on which order they got registered in. Not all mvebu devices are prone to this error, however testing for the specific wireless chipset would be more difficult and this behaviour will not adversely affect the other devices in this target.
The getRandomMac function has a new wrapper getRandomMacWithMask, which allows us to limit the variability of these random macs produced. As a result of this limitation, we now also check that the (not so) randomly generated mac is indeed unique to the other existing interfaces, to avoid us ebtables blocking our entire LAN into oblivion.
I've also altered the getRandomMac function and provided a slightly more robust explanation about why hostapd was rejecting certain mac addresses, and given us the ability to generate them anyway if you might need to do so in the future.
References:
@obsy I'd appreciate your comments/testing on this one if you have the time please. I don't know if you have any mvebu devices, but specifically it would be great to test it on some non-mvebu devices as well to make sure it all still behaves.