Re: brcmfmac: multi-BSS fails with arbitrary per-BSS MAC addresses

Hi,

I have obtained additional reproducible results concerning brcmfmac
MAC-address handling with multiple AP interfaces.


## Summary

Runtime MAC reassignment using "ip link" succeeds only on phy1-ap0,
which appears to be the primary firmware BSS.

The identical operation fails on every secondary AP interface:
phy1-ap1, phy1-ap2, and phy1-ap3.

The failure is not caused by unrelated randomized addresses or by an
invalid address pattern. I tested four valid locally administered
unicast addresses which:

* have the same first five octets;
* differ only in the final octet; and
* follow the same sequential pattern with which the four APs can
  otherwise operate concurrently.

## Test

The requested address set was:

phy1-ap0  aa:bb:cc:dd:ee:01
phy1-ap1  aa:bb:cc:dd:ee:02
phy1-ap2  aa:bb:cc:dd:ee:03
phy1-ap3  aa:bb:cc:dd:ee:04

The first octet, 0xaa, identifies a valid locally administered unicast
address.

I performed the following operations:

ip link set dev phy1-ap0 down
ip link set dev phy1-ap0 address aa:bb:cc:dd:ee:01
ip link set dev phy1-ap0 up

ip link set dev phy1-ap1 down
ip link set dev phy1-ap1 address aa:bb:cc:dd:ee:02
ip link set dev phy1-ap1 up

ip link set dev phy1-ap2 down
ip link set dev phy1-ap2 address aa:bb:cc:dd:ee:03
ip link set dev phy1-ap2 up

ip link set dev phy1-ap3 down
ip link set dev phy1-ap3 address aa:bb:cc:dd:ee:04
ip link set dev phy1-ap3 up

The phy1-ap0 address operation succeeds.

The address operation on each secondary AP fails with:

ip: SIOCSIFHWADDR: No error information

The interfaces were explicitly brought back up after each failed
address operation.

## Kernel log

The corresponding kernel error is:

ieee80211 phy1: brcmf_c_set_cur_etheraddr:
Setting cur_etheraddr failed, -52

Example log excerpt:

brcmfmac 0001:01:00.0 phy1-ap2: left promiscuous mode
br-lan: port 8(phy1-ap2) entered disabled state
ieee80211 phy1: brcmf_c_set_cur_etheraddr:
Setting cur_etheraddr failed, -52
br-lan: port 8(phy1-ap2) entered blocking state
br-lan: port 8(phy1-ap2) entered disabled state
brcmfmac 0001:01:00.0 phy1-ap2: entered allmulticast mode
brcmfmac 0001:01:00.0 phy1-ap2: entered promiscuous mode

brcmfmac 0001:01:00.0 phy1-ap3: left allmulticast mode
brcmfmac 0001:01:00.0 phy1-ap3: left promiscuous mode
br-lan: port 9(phy1-ap3) entered disabled state
ieee80211 phy1: brcmf_c_set_cur_etheraddr:
Setting cur_etheraddr failed, -52
brcmfmac 0001:01:00.0 phy1-ap3: entered allmulticast mode
brcmfmac 0001:01:00.0 phy1-ap3: entered promiscuous mode
br-lan: port 9(phy1-ap3) entered forwarding state

phy1-ap1 produces the same brcmf_c_set_cur_etheraddr failure; its line
was immediately above the displayed tail of the log.

The bridge state transitions are expected because I explicitly brought
each interface down and up. This test did not produce the previous
brcmf_cfg80211_add_iface error or an interface-creation retry loop.

## Interpretation

All AP netdevices expose the same ndo_set_mac_address operation.

brcmf_netdev_set_mac_address() calls:

brcmf_c_set_cur_etheraddr(ifp, address)

which sends the ordinary "cur_etheraddr" IOVAR using:

brcmf_fil_iovar_data_set(ifp, "cur_etheraddr", ...)

The same operation succeeds on the primary AP but returns -52 on every
secondary AP. The failure therefore correlates with the interface being
a secondary BSSCFG, rather than with the requested address format.

This does not by itself establish whether:

1. the firmware does not permit changing a secondary BSSID after
   creation; or

2. brcmfmac needs to use a BSSCFG-indexed "cur_etheraddr" operation for
   secondary AP interfaces.

There may also be a relevant creation-path issue. In
brcmf_apsta_add_vif(), params->macaddr is supplied when requesting a
station interface, but the AP path calls brcmf_cfg80211_request_ap_if()
without passing the requested AP address.

If a secondary AP address can only be assigned during firmware
interface/BSS creation, the current AP creation path does not appear to
provide userspace's requested address.

## Expected behavior

A valid MAC address supplied for an AP interface should either:

1. be applied to the correct firmware BSSCFG; or

2. be rejected with an explicit unsupported-operation error if the
   firmware does not permit changing that interface's address.

The driver should not expose apparently identical runtime MAC-change
support on all AP netdevices while the operation succeeds only on the
primary AP.

## Questions

1. Is the ordinary "cur_etheraddr" IOVAR expected to operate on
   secondary AP interfaces?

2. Should brcmf_netdev_set_mac_address() use
   brcmf_fil_bsscfg_data_set() for an interface whose bsscfgidx is not
   the primary BSS?

3. If secondary AP addresses are immutable after creation, should
   brcmf_cfg80211_request_ap_if() accept and pass params->macaddr when
   creating the firmware interface?

4. If the firmware imposes a BSSID address mask or address pool, should
   brcmfmac advertise that restriction through wiphy->addr_mask or
   reject incompatible requests before disrupting an active interface?


Best regards,