88W8964 issues with multiple SSID

[kubrickfr]

Driver / hardware properties:

driver name: mwlwifi
chip type: 88W8964
hw version: 7
driver version: 10.3.4.0-20170512
firmware version: 0x09020105
power table loaded from dts: no
firmware region code: 0x30
mac address: 60:38:e0:b6:97:ca
2g: disable
5g: enable
antenna: 4 4
irq number: 45
ap macid support: 0000ffff
sta macid support: 00010000
macid used: 00000003
radio: enable
iobase0: e0e00000
iobase1: e1080000
tx limit: 1024
rx limit: 16384

On LEDE, with multiple SSID on the 5GHz channels, only one SSID is usable at a time, connection is dropped when another device connects to another SSID.

[ad019]

@BrainSlayer Sorry my mistake. I meant created 2 virtual interfaces with 2 different SSIDs on 2.4 Ghz radio. The radio refused to start up. Tried reboots and power cycled the router. Had to finally connect on the 5Ghz radio, delete one of the virtual interface and then the 2.4Ghz radio came up.

[yuhhaurlin]

Normally if radio can't bring up, it is possible that hostapd is not running. You need to check if there is something wrong in configuration file of hostapd. I can reproduce problem of three SSIDs.

1. Creations of three SSIDs.
2. If disable one of these three SSIDs, it works well.
3. If re-enable this SSID, only the last one can work. From sniffer, only the last one will reply authentication from client. I will check it. Thanks.

[BrainSlayer]

okay. i tested on 5 ghz and it worked. i will redo the test on 2.4 ghz (even if this is curious)

[BrainSlayer]

consider that i only checked if the ssid broadcasts. no functional test

[BrainSlayer]

okay. issue is present on 2.4 ghz interface only. i checked it and it doesnt work. hostapd is running and looks okay so far

[BrainSlayer]

so this looks like a firmware problem for me since the driver should not make any difference between 2.4 and 5 ghz here, or am i wrong?

[ad019]

Exactly. Before you reboot, the router broadcasts all 3 SSIDs. But it did not allow me to connect to the primary SSID. The LEDs for 2.4 GHz stopped blinking. Then I rebooted and the 2.4 Ghz did not come up. I knocked off one SSID and rebooted and both the bands were functioning.

[yuhhaurlin]

I will fix three SSIDs problem first. There should be no difference between 2.4g and 5g.

@ad019 So your problem is the same as three SSIDs, right? Devices are up and running but you just can't connect to the first two SSIDs?

[ad019]

My problem is different. I have enabled 1 primary and 2 virtual SSIDs on 2.4 Ghz radio. I cannot connect to any. The router shows 3 SSIDs broadcasting. If I reboot the router, the radio stops working. I disable one virtual SSID and the radio works normally with 1 primary and 1 virtual SSID.

[yuhhaurlin]

I will fix three SSIDs problem first. After that, I will test on 2.4g band. Thanks.

[BrainSlayer]

@ad019 thats the same problem we are talking about. so lets wait what yuhhaurlin finds

[yuhhaurlin]

@BrainSlayer The problem is that for 88W8964, vendor will reserve enough MAC addresses for VAPs, so you need to modify last byte not the first byte of MAC address (every VAP increases 1 of last byte of interface MAC address). I think it needs to modify the script file to resolve this kind of problem.

[yuhhaurlin]

Assignment of MAC addresses of VAPs for 88W8964: macaddr[5] = wlpptr->hwData.macAddr[5] + ((index+1) & 0xf); => for VAPs. macaddr[0] |= 0x02; //Usse local administration bit for STA => for client.

That is the least significant 4 bits of last byte of interface MAC address are used for VAPs. (16 available addresses). Client uses local administration bit of interface MAC address. Thanks.

[yuhhaurlin]

Once if the assignment of MAC address is fixed for 88W8964, this problem should be gone. Otherwise, management packets will be filtered by firmware and only the last one will allow management packets to pass through.

Two VAPs can work is due to local administration bit will be ignored by firmware.

[yuhhaurlin]

I close this one. If you still find any problems, please let me know. Thanks.

[BrainSlayer]

@yuhhaurlin : nope. this is why the first byte is masked with 0x2 in case of a vap. then its a private space mac address. this behaviour is a industry standard which used by almost all vendors

[yuhhaurlin]

@BrainSlayer Only client uses local administration bit. For VAPs, Belkin should reserve enough MAC addresses for them. This is what firmware of 88W8964 did. Please modify the script file to fix this problem.

[BrainSlayer]

the formula in lede/openwrt and dd-wrt used since many years is hwbuff[0] ^= ((vapid - 1) << 2) | 0x2;

this way wont collide with official mac addresses

[BrainSlayer]

but i can change this way for "marvell only" devices for sure.

[yuhhaurlin]

This is the previous way to do that. For 88W8964, it should reserve enough MAC addresses for VAPs and this is the firmware of 88W8964 did. Please only modify it for 88W8964 and keep original way for 88W8864. Thanks.

[BrainSlayer]

okay

[yuhhaurlin]

Thanks. If after the modification, you still find any problems, please let me know.

[BrainSlayer]

will compile and test now

[BrainSlayer]

positive result. seems to work now. thanks for sharing the secret :-)

[yuhhaurlin]

Can you send the patch to me? I want to update my LEDE build. Thanks.

[BrainSlayer]

dd-wrt is written in pure C code. lede is written in shell scripts. there is basicly no code relation between these projects. but i can look what needs to be changed in lede. gimme some minutes

[yuhhaurlin]

O.K. Maybe I can check how to modify it later. Thanks.

[BrainSlayer]

try the included patch in zip file. 88w8964.zip

[yuhhaurlin]

Thanks. I will try it if someone still reports problem about Multi-BSSID.

[BrainSlayer]

for sure this patch works only for 88w8964 and may cause problems on any other chipset

[BrainSlayer]

official way for lede. there are 2 sysfs entries. address_mask and addresses. if address_mask is 00:00:00:00:00:00 and addresses contains a list of mac addresses. lede will choose the mac address by vapidx from this list

[BrainSlayer]

this must be implemented into the driver

[yuhhaurlin]

No, VAP is created dynamically, the MAC address must be assigned by upper layer.

[ad019]

@BrainSlayer Looks good at first test. 1+2 SSIDs are up and connecting.

Thanks for the quick fix.

[BrainSlayer]

@yuhhaurlin you missunderstand me. the driver is able to provide a mac address list for all possible vap's by sysfs. lede uses this for assigning the mac addresses. its very easy to implent and lede doesnt need to be changed for that. i talked with a lede developer about this and they want to avoid to implement special quirks for a single chipset. so the driver has to provide the mac address list by sysfs

[BrainSlayer]

so the list just need to contain a generated list of mac addresses based on your algorithm. no matter if the vap was created or not.

[yuhhaurlin]

I will check it. Thanks.

[Voltara]

If I'm reading the suggested MAC generation code correctly, the AP should not set the 0x2 bit in the first octet for VAP addresses. If that's true, the LEDE patch attached above is incorrect.

Also (and I can't test right now unfortunately) I suspect there will be additional headaches because of overlap in the generated address space between interfaces. On my router I have:

eth1: 60:xx:xx:xx:xx:98  (62:...:98 is eth0 which is LAN-side)
phy1: 60:xx:xx:xx:xx:99 (2.4 GHz)
phy0: 60:xx:xx:xx:xx:9a (5 GHz)
phy2: 60:xx:xx:xx:xx:9b

So 4 out of the 16 available addresses are already taken. And the VAP address generator needs some way to discover which addresses are in use and coordinate that across all of the phy (and the ethernet) devices.

[yuhhaurlin]

I will check and reply you later.

[yuhhaurlin]

BTW, this is the MAC address assignment of your WRT3200ACM?

[Voltara]

Correct, these are the addresses for my WRT3200ACM. The lowest-numbered address is :98 and is to the WAN port. The wireless interfaces are numbered :99, :9a, :9b (phy1, phy0, phy2).

Now that you mentioned it, I noticed my MAC addresses start at :x8, whereas the MAC address @kb3tbx pasted earlier suggests that his are numbered starting at :x0. This seems to imply the router's addresses are not actually reserved in blocks of 16.

[ValCher1961]

There's still MAC Bleutooth. Maybe we should take it into account so that there's no conflict?

[kb3tbx]

here is more from WRT3200ACM:

root@LEDE:~# ifconfig br-lan Link encap:Ethernet HWaddr 62:38:E0:B4:6B:80 eth0 Link encap:Ethernet HWaddr 62:38:E0:B4:6B:80 eth0.1 Link encap:Ethernet HWaddr 62:38:E0:B4:6B:80 eth1 Link encap:Ethernet HWaddr 60:38:E0:B4:6B:80 eth1.2 Link encap:Ethernet HWaddr 60:38:E0:B4:6B:80 ifb4eth1 Link encap:Ethernet HWaddr 1E:D0:5B:84:89:81

wlan0 Link encap:Ethernet HWaddr 60:38:E0:B4:6B:82 wlan0-1 Link encap:Ethernet HWaddr 62:38:E0:B4:6B:82 wlan0-2 Link encap:Ethernet HWaddr 66:38:E0:B4:6B:82

wlan1 Link encap:Ethernet HWaddr 60:38:E0:B4:6B:81 wlan1-1 Link encap:Ethernet HWaddr 62:38:E0:B4:6B:81 wlan1-2 Link encap:Ethernet HWaddr 66:38:E0:B4:6B:81 wlan1-3 Link encap:Ethernet HWaddr 6A:38:E0:B4:6B:81

wlan2 Link encap:Ethernet HWaddr 60:38:E0:B4:6B:83 wlan2-1 Link encap:Ethernet HWaddr 62:38:E0:B4:6B:83 wlan2-2 Link encap:Ethernet HWaddr 66:38:E0:B4:6B:83

[yuhhaurlin]

I will check and figure out the way to resolve the assignment of BSSID for VAPs.

[yuhhaurlin]

For Rango, Belkin reserved 8 Mac address for each radio. So, during MFG, each radio mac address end with x0 or x8 to prevent the MAC address confliction.

[yuhhaurlin]

If your MAC address assignment of phy0 and phy1 does not follow this rule, you need to check with Belkin. The script file to assign BSSID of VAPs should only take care about 8 VAPs, for station, it uses local administration bit of interface MAC address. I will check the way suggested by @BrainSlayer to prepare BSSIDs for VAPs via sysfs, but driver won't guarantee MAC address reservation of your device.

[yuhhaurlin]

1. The work for sysfs to support BSSID assignment of VAPs will be done later. From current code, it can work for two VAPs. If you need more VAPs, please modify the way to assign BSSID of VAPs.
2. MAC address of phy0 and phy1 should be ended with 0x0 or 0x8 to reserve 8 MAC address for VAPs. If your device does not follow the rule, you need to check with Belkin.
3. I need to mention one more time that phy2 is not mwlwifi. Please do not report problems related to phy2 for mwlwifi.

Thanks.

[Voltara]

Thanks again for looking into this.

For the purpose of implementing a BSSID assignment workaround, I did some experimentation to find out what works and what doesn't.

Here's what I found works: All interfaces for a given phy must have BSSID that match, given the bitmask fd:ff:ff:ff:ff:f0. If any of the masked bits differ, the only interfaces which function correctly are those with masked BSSID matching the last interface created. Whether or not this is a bug can be debated, but right now it sounds as if it's working as intended.

In testing, I was able to achieve the maximum of 16 functioning SSIDs per phy by assigning randomly generated ranges of locally administered unicast addresses (52:d8:75:54:e0:80 - 52:d8:75:54:e0:8f, and 36:b8:07:25:39:e0 - 36:b8:07:25:39:ef).

[yuhhaurlin]

@Voltara Yes. This bitmask fd:ff:ff:ff:ff:f0 is used by firmware to filter packets to driver. The base is the last BSSID you set to firmware.

[lewisdiamond]

@Voltara, how exactly did you assign those BSSIDs for testing?