brcmfmac: AP+STA on one PHY reassigns STA MAC to AP MAC and breaks concurrent operation

Hi,=0A=
=0A=
I am seeing a reproducible AP+STA concurrency failure with `brcmfmac` on a =
single PHY.=0A=
=0A=
The PHY advertises a valid interface combination containing both a managed =
interface and an AP interface, so one STA and one AP should be able to oper=
ate concurrently.=0A=
=0A=
The relevant `iw phy` interface-combination output is:=0A=
=0A=
```=0A=
[paste the exact =93valid interface combinations=94 block here]=0A=
```=0A=
=0A=
## Environment=0A=
=0A=
```=0A=
=0A=
Broadcom chipset:   BCM4366C0=0A=
=0A=
```=0A=
=0A=
## Summary=0A=
=0A=
STA-only and AP-only operation both work correctly.=0A=
=0A=
Concurrent AP+STA operation fails because the STA interface is reassigned t=
o the MAC address of the AP interface. The visible failure depends on which=
 interface is started first, but concurrent operation never works.=0A=
=0A=
The STA MAC also follows the most recently enabled AP interface. If another=
 AP is enabled, the STA changes again and takes that AP=92s MAC address.=0A=
=0A=
## Expected behavior=0A=
=0A=
One STA and one AP should operate concurrently on the same PHY, using disti=
nct interface MAC addresses.=0A=
=0A=
Starting or stopping another supported AP interface should not reassign the=
 STA MAC or corrupt the state of existing virtual interfaces.=0A=
=0A=
## Actual behavior=0A=
=0A=
### Test 1: STA only=0A=
=0A=
1. Enable the STA.=0A=
2. The STA associates with the upstream AP and works normally.=0A=
3. The STA initially uses the radio=92s normal/default MAC address.=0A=
=0A=
Result: works.=0A=
=0A=
### Test 2: AP only=0A=
=0A=
1. Enable one AP.=0A=
2. The AP starts and broadcasts normally.=0A=
=0A=
Result: works.=0A=
=0A=
### Test 3: STA first, AP second=0A=
=0A=
1. Enable the STA.=0A=
2. The STA associates and works.=0A=
3. Enable the AP.=0A=
4. The STA changes to the AP interface=92s MAC address.=0A=
5. The STA and AP now have the same MAC address.=0A=
6. Both interfaces fail.=0A=
=0A=
Result: both STA and AP fail.=0A=
=0A=
### Test 4: AP first, STA second=0A=
=0A=
1. Enable the AP.=0A=
2. The AP starts and broadcasts normally.=0A=
3. Enable the STA.=0A=
4. The STA changes to the AP interface=92s MAC address.=0A=
5. The STA successfully associates with the upstream AP.=0A=
6. The local AP then stops broadcasting/disappears.=0A=
=0A=
Result: the STA associates, but the AP fails.=0A=
=0A=
### Test 5: Explicit STA MAC=0A=
=0A=
Setting `option macaddr` on the STA does not resolve the problem.=0A=
=0A=
The STA does not retain the configured MAC during concurrent AP+STA operati=
on. It still changes to the AP interface=92s MAC address.=0A=
=0A=
### Test 6: Explicit AP MAC=0A=
=0A=
Changing the AP=92s configured `option macaddr` also does not resolve the p=
roblem.=0A=
=0A=
Whatever MAC address is assigned to the AP, the STA changes to that address=
 when AP+STA operation is attempted.=0A=
=0A=
### Test 7: Enable another AP=0A=
=0A=
This test makes the cross-interface reassignment especially visible:=0A=
=0A=
1. Enable AP0.=0A=
2. Enable the STA.=0A=
3. The STA takes AP0=92s MAC address.=0A=
4. Enable AP1, which has a different valid MAC address.=0A=
5. The STA changes again and takes AP1=92s MAC address.=0A=
=0A=
Therefore, the STA is not merely receiving one incorrect static address. It=
s MAC follows the most recently enabled AP interface.=0A=
=0A=
If AP1 is then disabled, AP0 and the STA once again show different MAC addr=
esses in Linux. However, concurrent operation does not recover correctly:=
=0A=
=0A=
* OpenWrt/hostapd may briefly report AP0 as enabled.=0A=
* The AP is not visible over the air.=0A=
* The STA repeatedly connects and disconnects.=0A=
* `phy0-ap0` repeatedly enters forwarding state and is then disabled.=0A=
* `brcmfmac` repeatedly reports `WLC_DISASSOC failed (-52)`.=0A=
=0A=
## Representative log=0A=
=0A=
The STA initially associates and completes WPA key negotiation:=0A=
=0A=
```=0A=
wpa_supplicant: phy0-sta0: Associated with aa:bb:cc:00:11:22=0A=
wpa_supplicant: phy0-sta0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=3D0=0A=
wpa_supplicant: phy0-sta0: WPA: Key negotiation completed with aa:bb:cc:00:=
11:22 [PTK=3DCCMP GTK=3DCCMP]=0A=
wpa_supplicant: phy0-sta0: CTRL-EVENT-CONNECTED - Connection to aa:bb:cc:00=
:11:22 completed=0A=
```=0A=
=0A=
The local driver then fails to disconnect cleanly:=0A=
=0A=
```=0A=
ieee80211 phy0: brcmf_link_down: WLC_DISASSOC failed (-52)=0A=
```=0A=
=0A=
The STA is disconnected locally:=0A=
=0A=
```=0A=
wpa_supplicant: phy0-sta0: CTRL-EVENT-DISCONNECTED bssid=3Daa:bb:cc:00:11:2=
2 reason=3D0 locally_generated=3D1=0A=
```=0A=
=0A=
The AP bridge port then repeatedly transitions through forwarding and disab=
led states:=0A=
=0A=
```=0A=
br-lan: port 10(phy0-ap0) entered blocking state=0A=
br-lan: port 10(phy0-ap0) entered forwarding state=0A=
br-lan: port 10(phy0-ap0) entered disabled state=0A=
```=0A=
=0A=
This loop repeats:=0A=
=0A=
```=0A=
ieee80211 phy0: brcmf_link_down: WLC_DISASSOC failed (-52)=0A=
br-lan: port 10(phy0-ap0) entered blocking state=0A=
br-lan: port 10(phy0-ap0) entered forwarding state=0A=
br-lan: port 10(phy0-ap0) entered disabled state=0A=
```=0A=
=0A=
## Channel and security tests=0A=
=0A=
The AP+STA failure is reproducible with the channel set to automatic and wi=
th the AP explicitly configured to use the upstream AP=92s channel.=0A=
=0A=
The same MAC reassignment and concurrent-operation failure was observed wit=
h:=0A=
=0A=
* open authentication=0A=
* WEP=0A=
* WPA=0A=
* WPA2=0A=
=0A=
Therefore, the failure does not appear to be caused by WPA key negotiation =
or by a particular security mode.=0A=
=0A=
## Recovery=0A=
=0A=
On a fresh boot, disabling the STA allows the AP configuration to work agai=
n. A full reboot is not consistently required.=0A=
=0A=
During one earlier extended test session, a Wi-Fi restart was required befo=
re all APs returned, but I have not reproduced a consistent reboot requirem=
ent and am not treating that as part of the main bug.=0A=
=0A=
## Related observation=0A=
=0A=
The same hardware also has a separate multi-BSS MAC-assignment issue. Multi=
ple APs work only when explicit addresses are configured with the first fiv=
e octets identical and only the last octet different.=0A=
=0A=
I am treating that as a separate issue. However, it may indicate that virtu=
al-interface MAC allocation or firmware interface-address handling is relev=
ant to both failures.=0A=
=0A=
## Conclusion=0A=
=0A=
The main reproducible problem is:=0A=
=0A=
* AP-only works.=0A=
* STA-only works.=0A=
* Concurrent AP+STA is advertised as supported.=0A=
* The STA is reassigned to the AP interface=92s MAC.=0A=
* The STA MAC follows the most recently enabled AP.=0A=
* Bring-up order changes the visible outcome, but concurrent operation alwa=
ys fails.=0A=
* Removing the visible duplicate MAC afterwards does not immediately restor=
e valid AP+STA operation.=0A=
* The driver enters a repeated `WLC_DISASSOC failed (-52)` and interface-fl=
apping loop.=0A=
=0A=
This appears to be a `brcmfmac`/firmware virtual-interface MAC assignment o=
r interface-state handling bug.=0A=
=0A=
=0A=
Best regards,=0A=
Stephen=0A=