RPi3B+/RPi4 wlan/brcmfmac IBSS mode does not honour fixed BSSID (and triggers a kernel warning)

Start by reproducing the IBSS join commands on the listed RPi3/RPi4 setup and inspect the warning at net/wireless/sme.c:975, along with brcmf_notify_roaming_status and the brcmfmac event path shown in the trace. Done means the requested BSSID is used and reported by both nodes, no kernel warning occurs, and the nodes can still communicate.

Describe the bug
Running two RPi wlan/brcmfmac in IBSS mode with fixed BSSID triggers a kernel warning and the given BSSID is ignored.

To reproduce
On Node A (RPi3):

        $ iw wlan0 set type ibss
        $ ifconfig wlan0 10.11.0.3 up
        $ iw wlan0 ibss join test-ibss1 2412 1a:2b:3c:4d:5e:6f

On Node B (RPi4):

        $ iw wlan0 set type ibss
        $ ifconfig wlan0 10.11.0.3 up
        $ iw wlan0 ibss join test-ibss1 2412 1a:2b:3c:4d:5e:6f

[  122.182232] ------------[ cut here ]------------
[  122.190371] WARNING: CPU: 2 PID: 88 at net/wireless/sme.c:975 cfg80211_roamed+0x248/0x260 [cfg80211]
[  122.202884] Modules linked in: 88XXau(O) brcmfmac brcmutil sha256_generic cfg80211 rfkill ipv6
[  122.215029] CPU: 2 PID: 88 Comm: kworker/2:2 Tainted: G           O      5.10.46-v7l #1
[  122.226397] Hardware name: BCM2711
[  122.233258] Workqueue: events brcmf_fweh_event_worker [brcmfmac]
[  122.242605] Backtrace:
[  122.248363] [<c0bb1e50>] (dump_backtrace) from [<c0bb21c4>] (show_stack+0x20/0x24)
[  122.259265]  r7:ffffffff r6:00000000 r5:60000013 r4:c12e6b7c
[  122.268236] [<c0bb21a4>] (show_stack) from [<c0bb697c>] (dump_stack+0xc4/0xf0)
[  122.278769] [<c0bb68b8>] (dump_stack) from [<c0221200>] (__warn+0xfc/0x158)
[  122.289018]  r9:c291a000 r8:00000009 r7:000003cf r6:00000009 r5:bf0c57fc r4:bf0f6868
[  122.300093] [<c0221104>] (__warn) from [<c0bb29c4>] (warn_slowpath_fmt+0x70/0xe4)
[  122.310905]  r7:bf0c57fc r6:000003cf r5:bf0f6868 r4:00000000
[  122.320104] [<c0bb2958>] (warn_slowpath_fmt) from [<bf0c57fc>] (cfg80211_roamed+0x248/0x260 [cfg80211])
[  122.332915]  r8:c2be02f0 r7:c2bb81c0 r6:c2be0004 r5:00000cc0 r4:c2375df0
[  122.343323] [<bf0c55b4>] (cfg80211_roamed [cfg80211]) from [<bf18f978>] (brcmf_notify_roaming_status+0x18c/0x260 [brcmfmac])
[  122.358068]  r8:c2be02f0 r7:c2ba8000 r6:c2ba8800 r5:c2be0000 r4:c28a5800
[  122.368529] [<bf18f7ec>] (brcmf_notify_roaming_status [brcmfmac]) from [<bf19d6d4>] (brcmf_fweh_call_event_handler+0x48/0x98 [brcmfmac])
[  122.384429]  r10:c2bba63c r9:bf1bb0e8 r8:c2bba64c r7:00000000 r6:c2bb863c r5:c1a45ec8
[  122.395896]  r4:c1a45e80
[  122.402233] [<bf19d68c>] (brcmf_fweh_call_event_handler [brcmfmac]) from [<bf19d950>] (brcmf_fweh_event_worker+0x22c/0x4c8 [brcmfmac])
[  122.418154] [<bf19d724>] (brcmf_fweh_event_worker [brcmfmac]) from [<c023f194>] (process_one_work+0x220/0x574)
[  122.431927]  r10:00000080 r9:00000000 r8:00000000 r7:ef77ea00 r6:ef77b680 r5:c1a45080
[  122.443540]  r4:c2bba63c
[  122.449838] [<c023ef74>] (process_one_work) from [<c023f554>] (worker_thread+0x6c/0x5d0)
[  122.461746]  r10:ef77b680 r9:00000008 r8:c1203d00 r7:ef77b698 r6:c1a45094 r5:ef77b680
[  122.473400]  r4:c1a45080
[  122.479744] [<c023f4e8>] (worker_thread) from [<c0246558>] (kthread+0x168/0x16c)
[  122.490974]  r10:c1969e84 r9:c1a45080 r8:c023f4e8 r7:c2374000 r6:00000000 r5:c1a44840
[  122.502652]  r4:c198b6c0
[  122.509008] [<c02463f0>] (kthread) from [<c02000ec>] (ret_from_fork+0x14/0x28)
[  122.520116] Exception stack(0xc2375fb0 to 0xc2375ff8)
[  122.529063] 5fa0:                                     00000000 00000000 00000000 00000000
[  122.541161] 5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[  122.553239] 5fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[  122.563714]  r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000 r5:c02463f0
[  122.575418]  r4:c1a44840
[  122.581858] ---[ end trace 1bd14831fa886161 ]---

Expected behaviour
Both Nodes (Node A/RPi3, Node B/RPi4) should join a IBSS ad-hoc network with given SSID (test-ibss1) and given BSSID (1a:2b:3c:4d:5e:6f).

Actual behaviour
The given fixes BSSID (1a:2b:3c:4d:5e:6f) is ignored and the second Node triggers a kernel warning (but both join the ad-hoc network (9A:0C:D0:64:BE:6E), ping between the nodes is possible).

On Node A (RPi3):

        $ iwconfig wlan0
wlan0     IEEE 802.11  ESSID:"test-ibss1"
          Mode:Ad-Hoc  Frequency:2.412 GHz  Cell: 9A:0C:D0:64:BE:6E
          Tx-Power=31 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:on

On Node B (RPi4 - wrong Cell/BSSID is reported):

        $ iwconfig wlan0
wlan0     IEEE 802.11  ESSID:"test-ibss1"
          Mode:Ad-Hoc  Frequency:2.412 GHz  Cell: E2:D4:06:A3:1A:8C
          Tx-Power=31 dBm
          Retry short limit:7   RTS thr:off   Fragment thr:off
          Encryption key:off
          Power Management:on

A wifi capture/wireshark trace (with a third system and wifi card in monitor mode) shows that the actual used BSSID from both Nodes is '9A:0C:D0:64:BE:6E' (as announced in the beacon frames):

No.     Time           Source                Destination           Protocol Length Info
  26901 6.857673       Raspberr_4c:ca:cc     Broadcast             802.11   202    Beacon frame, SN=381, FN=0, Flags=........C, BI=100, SSID=test-ibss1

Frame 26901: 202 bytes on wire (1616 bits), 202 bytes captured (1616 bits)
Radiotap Header v0, Length 32
802.11 radio information
IEEE 802.11 Beacon frame, Flags: ........C
    Type/Subtype: Beacon frame (0x0008)
    Frame Control Field: 0x8000
    .000 0000 0000 0000 = Duration: 0 microseconds
    Receiver address: Broadcast (ff:ff:ff:ff:ff:ff)
    Destination address: Broadcast (ff:ff:ff:ff:ff:ff)
    Transmitter address: Raspberr_4c:ca:cc (dc:a6:32:4c:ca:cc)
    Source address: Raspberr_4c:ca:cc (dc:a6:32:4c:ca:cc)
    BSS Id: 9a:0c:d0:64:be:6e (9a:0c:d0:64:be:6e)
    .... .... .... 0000 = Fragment number: 0
    0001 0111 1101 .... = Sequence number: 381
    Frame check sequence: 0x5d7f7a14 [unverified]
    [FCS Status: Unverified]
IEEE 802.11 Wireless Management

No.     Time           Source                Destination           Protocol Length Info
  27882 2.765100       Raspberr_86:59:49     Broadcast             802.11   202    Beacon frame, SN=968, FN=0, Flags=........C, BI=100, SSID=test-ibss1

Frame 27882: 202 bytes on wire (1616 bits), 202 bytes captured (1616 bits)
Radiotap Header v0, Length 32
802.11 radio information
IEEE 802.11 Beacon frame, Flags: ........C
    Type/Subtype: Beacon frame (0x0008)
    Frame Control Field: 0x8000
    .000 0000 0000 0000 = Duration: 0 microseconds
    Receiver address: Broadcast (ff:ff:ff:ff:ff:ff)
    Destination address: Broadcast (ff:ff:ff:ff:ff:ff)
    Transmitter address: Raspberr_86:59:49 (b8:27:eb:86:59:49)
    Source address: Raspberr_86:59:49 (b8:27:eb:86:59:49)
    BSS Id: 9a:0c:d0:64:be:6e (9a:0c:d0:64:be:6e)
    .... .... .... 0000 = Fragment number: 0
    0011 1100 1000 .... = Sequence number: 968
    Frame check sequence: 0x17ca6739 [unverified]
    [FCS Status: Unverified]
IEEE 802.11 Wireless Management

System

• RPi3+, RPi4
• OS and version: Buildroot 2021.08-git
• kernel version: Linux buildroot 5.10.46-v7
• brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Jan 4 2021 19:56:29 version 7.45.229 (617f1f5 CY) FWID 01-2dbd9d2e