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

I ran additional tests and found results that may help.

## Summary

There appear to be two related failures:

1. A MAC address configured for the station using OpenWrt
   "option macaddr" is ignored. The station continues using the
   primary/default address.

2. When the AP and station are enabled concurrently, the station can
   take the AP interface's MAC address. Both interfaces then have the
   same address, the AP fails to remain active, and the station either
   fails to connect or connects only momentarily.

The only method that reliably changes the station MAC is:

ip link set dev phy0-sta0 address <STA_MAC>

This works even without bringing the interface down first.

When I bring both interfaces down, assign different MAC addresses, and
bring them up again, the addresses shown by Linux become different.
However, the interfaces then enter a repeated failure cycle: the
station connects for approximately one second and disconnects, while
phy0-ap0 appears for approximately one second and disappears again.

## Expected behavior

The MAC address supplied for each interface should either:

1. be applied to that interface, or
2. be rejected with a clear error if the firmware cannot support it.

A supported one-STA plus one-AP combination should remain operational
with distinct, valid local-unicast addresses. The driver should not
silently assign the AP address to the station or repeatedly recreate
and remove interfaces.

## Reproduction

1. Configure only a station on radio0 and give it an explicit MAC:

config wifi-iface 'sta'
option device 'radio0'
option mode 'sta'
option network 'wwan'
option ssid '<redacted>'
option encryption '<redacted>'
option key '<redacted>'
option macaddr '<STA_MAC>'

2. Reload Wi-Fi.

3. Check phy0-sta0:

ip link show dev phy0-sta0

The configured STA_MAC is not applied. The station uses the
primary/default radio address instead.

4. Configure and enable an AP on the same PHY with another address:

config wifi-iface 'ap'
option device 'radio0'
option mode 'ap'
option network 'lan'
option ssid '<redacted>'
option encryption '<redacted>'
option key '<redacted>'
option macaddr '<AP_MAC>'

The radio is configured so the AP and station can use the same channel;
automatic channel selection was used during this test.

5. Reload Wi-Fi and check both interfaces:

ip link show dev phy0-sta0
ip link show dev phy0-ap0
iw dev

The station takes AP_MAC, so phy0-sta0 and phy0-ap0 can show the same
MAC address. The AP then fails to remain operational.

If another AP configuration is enabled with a different address, the
station can instead take that AP's address.

## Manual MAC-address test

The following changes the station MAC successfully:

ip link set dev phy0-sta0 address <STA_MAC>

I also tested forcing both interfaces to restart with distinct
addresses:

ip link set dev phy0-sta0 down
ip link set dev phy0-sta0 address <STA_MAC>
ip link set dev phy0-sta0 up

ip link set dev phy0-ap0 down
ip link set dev phy0-ap0 address <AP_MAC>
ip link set dev phy0-ap0 up

Linux then shows two distinct addresses, but AP+STA operation becomes
unstable and enters a repeated add/remove cycle.

No interface was manually created with "iw phy interface add", and no
separate manual hostapd instance was used for the log below.

## Relevant log excerpt

br-lan: port 6(phy0-ap0) entered forwarding state
ieee80211 phy0: brcmf_cfg80211_add_iface: iface validation failed: err=-16
br-lan: port 6(phy0-ap0) entered disabled state
brcmfmac 0000:01:00.0 phy0-ap0: left allmulticast mode
brcmfmac 0000:01:00.0 phy0-ap0: left promiscuous mode
br-lan: port 6(phy0-ap0) entered disabled state
br-lan: port 6(phy0-ap0) entered blocking state
br-lan: port 6(phy0-ap0) entered disabled state
brcmfmac 0000:01:00.0 phy0-ap0: entered allmulticast mode
brcmfmac 0000:01:00.0 phy0-ap0: entered promiscuous mode
ieee80211 phy0: brcmf_link_down: WLC_DISASSOC failed (-52)
br-lan: port 6(phy0-ap0) entered forwarding state
ieee80211 phy0: brcmf_cfg80211_add_iface: iface validation failed: err=-16

This sequence repeats approximately once per second.

## Code-path observations

The observed difference between OpenWrt configuration and "ip link"
appears consistent with the current brcmfmac code paths.

OpenWrt's wireless scripts place the configured address in the nl80211
request as "req.mac". When a pre-existing wireless device is reused,
this request is sent using NL80211_CMD_SET_INTERFACE.

In brcmfmac, brcmf_cfg80211_change_iface() receives:

struct vif_params *params

but does not appear to use params->macaddr.

This could explain why a configured address is ignored when the primary
or reusable interface becomes phy0-sta0.

There is another asymmetry in brcmf_apsta_add_vif():

* For NL80211_IFTYPE_STATION, params->macaddr is passed to
  brcmf_cfg80211_request_sta_if().
* For NL80211_IFTYPE_AP, brcmf_cfg80211_request_ap_if() is called
  without the requested address, and that function generates an
  address from the primary interface.

In contrast, "ip link set ... address ..." reaches
brcmf_netdev_set_mac_address(), which calls
brcmf_c_set_cur_etheraddr(). That path sends the address to the
firmware and updates the netdev address after the operation succeeds.

The "-16" message also appears to come from interface-combination
validation before a new interface-create request is sent to firmware.
Since a STA+AP combination should be valid, perhaps a previous or stale
VIF remains counted while userspace retries the operation.

## Possible firmware address restriction

On the same hardware, I separately observed that multiple AP interfaces
work when their first five MAC-address octets are identical and only
the last octet differs. Arbitrary unrelated AP addresses do not work
concurrently.

I intend to report that multi-AP behavior separately. However, it may
be relevant because brcmfmac also constructs its advertised interface
address list from a common base address and varies the final octet.

This could indicate a firmware address-mask or address-pool restriction.
Even if that restriction is required by the firmware, it does not
appear to explain why a requested station address is silently ignored,
why the station receives an AP address, or why the failure enters an
endless retry loop.

## Questions

1. Is ignoring params->macaddr in brcmf_cfg80211_change_iface()
   intentional?

2. Should the driver call brcmf_c_set_cur_etheraddr() when a MAC is
   supplied while changing/reusing the primary interface?

3. Should brcmf_cfg80211_request_ap_if() receive and validate
   params->macaddr instead of always generating the AP address?

4. Does the firmware require concurrent VIF addresses to share a
   particular prefix or address mask?

5. If such a firmware restriction exists, should brcmfmac expose it
   through wiphy->addr_mask or reject incompatible addresses before
   interface creation?


Best regards,