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.

[Voltara]

@lewisdiamond I'm using LEDE. I did a kill -STOP on netifd (to prevent it from restarting hostapd), killed the hostapd processes, manually edited the hostapd configurations in /var/run, then manually started hostapd using the modified configs.

When I was finished testing, I killed my test hostapd instances, then did kill -CONT on netifd.

Edit: Sometimes the router will crash/reboot with a kernel panic (NULL pointer dereference, if I remember correctly; I didn't keep a copy of the crashlog) while hostapd is starting up. If that happens, just try again.

[haribert]

I just updated to Lede 17.01.02 and realised that this problem does still exist if you have more than 2 SSID. With two SSID it works fine.

Can someone explain to me why this issue is closed although the problem does still exist?

And can someone give a functional workaround? In the ideal case a step by step tutorial or script. It is unclear to me, which configs need to be modified.

If additional information is needed, I am happy to provide them.

Thanks

[lewisdiamond]

There's no fix or (reasonable) work around yet. I do not know why this issue is closed.

[Voltara]

Here's my understanding of the situation:

There were actually two separate issues; the originally issue which was reported involved the assignment of stnid numbers, and prevented even a 2-SSID configuration from working properly. This specific issue was fixed, and the ticket was closed.

After the ticket was closed, there were reports of a separate issue in how the firmware filters incoming traffic based on a mask which is incompatible with how DD-WRT and LEDE generate BSSIDs, and only affects configurations with 3 or more SSIDs. This should probably have been ticketed separately, but it was not apparent at the time that this was indeed a separate issue.

The BSSID generation scheme recommended by Marvell will not work because their idea of how the addresses should be assigned conflicts with how Belkin actually burned the addresses into the WRT3200ACM devices.

Assuming there is no solution for the burned-in address issue, here are some possible solutions/workarounds:

• Add a driver parameter to allow overriding the BSSID mask. LEDE/DD-WRT can then override the mask as needed. This avoids the fingerpointing between Marvell and Belkin, and allows LEDE/DD-WRT to use their existing BSSID generation code without resorting to adding support for hardware quirks. The drawback is it requires support in the 88W8964.bin firmware blob. If it were up to me, this is how I would resolve the issue.
• Write a custom mac80211_generate_mac (for LEDE, or whatever the DD-WRT equivalent is) specifically for the WRT3200ACM, that works within the constraints of both Marvell and Belkin's address schemes. Different device models using the 88W8964 may require different custom code.
• Ignore the burned-in MAC, and instead generate random "locally-administered" addresses for the wireless interfaces. This avoids the Belkin constraint, supports the maximum number of SSIDs per radio, and simplifies the BSSID generation (which still must be custom-written, but can be somewhat more generic.)

[haribert]

@Voltara Thanks for your explanation and summary, this was very useful.

Does someone has the permission to open this issue again (@yuhhaurlin ?) or do I have to create a new issue. I think a new ticket would make less sense, since all information is already collected in this ticket.

[yuhhaurlin]

Driver does not have problem. It is related to BSSID address assignment. I will check the way to support mac80211.sh to do BSSID address assignment. It will be done later. I don't think I need to reopen this one or create another one to track something not related to driver.

[haribert]

@yuhhaurlin Thanks for your information. It is not clear to me how you keep the overview of all open points if you close the tickets or don't want to create new ones with the open points.

For me as user it would be great to have an overview of all issues and features which are planed (it would be perfect if the priority or estimated date would be available too). This is not possible with the current approach.

Only 2 SSIDs restrict my current setup and a solution would be very useful.

[yuhhaurlin]

Solution is already described in this issue. I only need to add support for BSSID assignment. If you need to have more than two VAPs, you can try to assign BSSID to make it work. If you don't know how to do it, you can wait for the code to support BSSID assignment later.

[yuhhaurlin]

The code to support BSSID assignment of VAPs is completed: https://github.com/kaloz/mwlwifi/commit/0f023b7d5875effb092224400dc633e5a38b38fd.

[kubrickfr]

https://github.com/kaloz/mwlwifi/commit/0f023b7d5875effb092224400dc633e5a38b38fd Works great with 2 BSSID and original LEDE SSID assignment script

[yuhhaurlin]

Yes. Script file mac80211.sh will get BSSID from /sys/class/ieee80211/phy0 or phy1/addresses.

[Voltara]

I can confirm it is working as documented in the commit. Pay careful attention to "Note 1" because the documented behavior may be incompatible with your device:

root@LEDE:~# diff -y -W42 /sys/class/ieee80211/phy[01]/addresses
                    >   60:38:e0:b8:a9:99
60:38:e0:b8:a9:9a       60:38:e0:b8:a9:9a
60:38:e0:b8:a9:9b       60:38:e0:b8:a9:9b
60:38:e0:b8:a9:9c       60:38:e0:b8:a9:9c
60:38:e0:b8:a9:9d       60:38:e0:b8:a9:9d
60:38:e0:b8:a9:9e       60:38:e0:b8:a9:9e
60:38:e0:b8:a9:9f       60:38:e0:b8:a9:9f
60:38:e0:b8:a9:a0       60:38:e0:b8:a9:a0
60:38:e0:b8:a9:a1   |   62:38:e0:b8:a9:99
62:38:e0:b8:a9:9a   <

Edit: I should add that multiple SSID seems to be working without any obvious problems, despite the overlap in addresses between the two radios. My guess is because the overlapping addresses are in separate broadcast domains (5GHz vs 2.4GHz.)

[yuhhaurlin]

It is very strange, your WRT3200ACM does not reserve 8 MAC addresses!

[yuhhaurlin]

However, the MAC addresses ended with a0 and a1 can't work.

[BrainSlayer]

@yuhhaurlin according to the code and the shown list the local bitz (0x2) is also not set for all vap's as required. since each vap which is created uses the mac from this table by vap index it will not work as specified by you in a earlier discussion. from what i know the first entry in the mac table should be the devices standard mac address all following 8 members must set the local bit and the incremented last number by vapid & 0xf

[BrainSlayer]

Index: core.c
===================================================================
--- core.c  (revision 3479)
+++ core.c  (working copy)
@@ -721,14 +721,13 @@
        hw->wiphy->addresses =
            kzalloc(addr_num * sizeof(*mac_addr), GFP_KERNEL);

-       for (addr_num = 0; addr_num < 8; addr_num++) {
+       for (addr_num = 0; addr_num < 9; addr_num++) {
            mac_addr = &hw->wiphy->addresses[addr_num];
            ether_addr_copy(mac_addr->addr, priv->hw_data.mac_addr);
-           mac_addr->addr[5] += addr_num;
+           mac_addr->addr[5] += addr_num & 0xf;
+           if (addr_num)
+               mac_addr->addr[0] |= 0x2;
        }
-       mac_addr = &hw->wiphy->addresses[addr_num];
-       ether_addr_copy(mac_addr->addr, priv->hw_data.mac_addr);
-       mac_addr->addr[0] |= 0x2;
    }

    wiphy_info(hw->wiphy, 

[yuhhaurlin]

No. I had checked with our PM. WRT3200ACM will reserve 8 real MAC addresses for each interface. So the code will extend 8 real MAC addresses and only the programmed one with local admin bit if one more STA is created.

[BrainSlayer]

mmh why should a sta have set a local bit? that doesnt make sense. local bit makes only sense for a vap. and why does my code work? i mean dd-wrt uses clearly the algorithm you told me (which i also implemented in that patch) and guess what? its working. if it would be wrong, it would not work

[BrainSlayer]

for repeater scenario the sta is also normally the first interface and not the last (ninth) one

[BrainSlayer]

i will test to create 8 vap's later using my algorithm. let me see how it works.

[ad019]

I tried to create 8 VAP in dd-wrt on 2.4 Ghz. The interface allows only 7 VAPs and although I can see the 7 VAPs broadcasting, I cannot connect to either the primary SSID or any of the 7 VAPs.

[yuhhaurlin]

It does not matter if your code work or not. Because there are 8 real MAC addresses, so the assignment will be 8 real MAC addresses and one with local admin bit. If you create STA first, it will use the first one.

[BrainSlayer]

yes but using local bit for a vap is the correct behaviour how it should be. its a industry standard and does also prevent mac address collissions with other devices. consider that you bought 2 wrt3200acm devices. if they are from the same badge they use nearby mac addresses. if you do not set the local bit, both devices have colliding mac addresses and if you set both to run in the same network bridge (connected by switch for instance) you get STP and ARP problems

[BrainSlayer]

so if local bit works for all vap's. it MUST be set

[BrainSlayer]

i tested now 8 vap's with local bit set and its working. so please take care about my arguments.

[yuhhaurlin]

I told you every interface of WRT3200ACM is allocated 8 real MAC addresses.

[BrainSlayer]

yes and i told you that if its possible to set the local bit, its important todo so to avoid mac address collisions within a bridged network with multiple accesspoints. belkin does not take care about this pre allocation. they produce devices with a single mac address assigned and the next device you buy in store might be the same mac + 1. this is no fiction. i already bought multiple devices which had incremental mac addresses. they will collide with each other if you use vap's without local bit set

[yuhhaurlin]

The interface is allocated with 8 real and unique MAC addresses. It will end with 0 or 8 and the following addresses are allocated to this interface. So these MAC addresses won't be conflicted with other devices.

[BrainSlayer]

but they arent unique. it depends how belkin assigns then while manufacturing and they do not spare out 8 addresses between 2 devices. they only spare out a single mac

[yuhhaurlin]

I will check and reply you later.

[seragh]

btw, iw reports 16 and not 8 APs max per phy.

[BrainSlayer]

havent tested more than 8 yet. but can do it if there is really demand for it

[yuhhaurlin]

I change the way to support BSSID assignment for VAPs: https://github.com/kaloz/mwlwifi/commit/4fd0788234441d3142c7b49eb192f8a49f0828b2.

[kubrickfr]

@BrainSlayer pardon me if that's a stupid question, but I don't understand how setting the local bit avoids collisions. If you have two devices that are just 1 apart in their BSSID and you create VAPs on both of them, will they not still collide?