Rock Pi 4B WiFi keeps changing MAC address on

My Rock Pi 4B WiFi seems to keep changing its MAC address, not after every reboot, but while it's running. This causes all sorts of problems and it seems to be a firmware issue as, a) the kernel driver seems to try to load some firmware, but can't find it, b) the default firmware, or whatever ends up being used, crashes, causing a reload which also changes the MAC address.

Here are some kernel messages:

Quote

...

[10353.200283] ieee80211 phy6: brcmf_fw_crashed: Firmware has halted or crashed
[10354.039948] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9
[10354.040571] brcmfmac mmc2:0001:1: Direct firmware load for brcm/brcmfmac43456-sdio.radxa,rockpi4b.bin failed with error -2
[10354.042067] brcmfmac mmc2:0001:1: Direct firmware load for brcm/brcmfmac43456-sdio.clm_blob failed with error -2
[10354.126087] ieee80211 phy7: brcmf_c_preinit_dcmds: Default MAC is used, replacing with random MAC to avoid conflicts
[10354.126573] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[10354.127010] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/9 wl0: Jun 16 2017 12:38:26 version 7.45.96.2 (66c4e21@sh-git) (r) FWID 01-1813af84
[11687.554259] ieee80211 phy7: brcmf_fw_crashed: Firmware has halted or crashed
[11688.379380] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9
[11688.379829] brcmfmac mmc2:0001:1: Direct firmware load for brcm/brcmfmac43456-sdio.radxa,rockpi4b.bin failed with error -2
[11688.380914] brcmfmac mmc2:0001:1: Direct firmware load for brcm/brcmfmac43456-sdio.clm_blob failed with error -2
[11688.463500] ieee80211 phy8: brcmf_c_preinit_dcmds: Default MAC is used, replacing with random MAC to avoid conflicts
[11688.463881] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[11688.464235] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/9 wl0: Jun 16 2017 12:38:26 version 7.45.96.2 (66c4e21@sh-git) (r) FWID 01-1813af84
[13815.087064] ieee80211 phy8: brcmf_fw_crashed: Firmware has halted or crashed
[13815.222274] ieee80211 phy8: brcmf_netdev_start_xmit: xmit rejected state=0
[13815.941437] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9
[13815.941787] brcmfmac mmc2:0001:1: Direct firmware load for brcm/brcmfmac43456-sdio.radxa,rockpi4b.bin failed with error -2
[13815.942885] brcmfmac mmc2:0001:1: Direct firmware load for brcm/brcmfmac43456-sdio.clm_blob failed with error -2
[13816.025040] ieee80211 phy9: brcmf_c_preinit_dcmds: Default MAC is used, replacing with random MAC to avoid conflicts
[13816.025395] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[13816.025742] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/9 wl0: Jun 16 2017 12:38:26 version 7.45.96.2 (66c4e21@sh-git) (r) FWID 01-1813af84

Display More

And there are more along those lines since boot. This seems to happen at irregular intervals, sometimes after 10', sometimes after close to an hour.

So, is this a known issue? Is there a know fix for it?

Thanks for the pointers, I'll have a look and report back.

One question though:

Quote from chewitt

Otherwise it's not something I've seen before with Broadcom modules. It does happen with cheap Realtek USB dongles where the manufacturer was too lazy to get unique OID's for their devices or programmed everything with 00:00:00:00:00:00.

Don't lines such as this

Quote

ieee80211 phy7: brcmf_c_preinit_dcmds: Default MAC is used, replacing with random MAC to avoid conflicts

imply that this is also what is happening with this Broadcom chip?

I've just installed a couple of firmware/nvram files from https://github.com/armbian/firmware.git. They are the same files as found in https://github.com/LibreELEC/brcmfmac_sdio-firmware, (where, somewhat confusingly, there seems to already be an nvram file for the Rock Pi 4B, named "brcmfmac43456-sdio.radxa,rockpi4b.txt", which is the same as "brcmfmac43456-sdio.txt", used for other boards, but there's no bin file for the 4B, although "brcmfmac43456-sdio.bin", which is the one I've installed, is used on otherboards).

Anyway the files I've used ("brcmfmac43456-sdio.bin", "brcmfmac43456-sdio.txt", appropriately renamed) seem to be working although I'm still getting

Quote

brcmf_c_preinit_dcmds: Default MAC is used, replacing with random MAC to avoid conflicts

and the MAC address was different upon reboot. When I say it's working, I mean it seems to be working fine so far. I'll let you know tomorrow, or after a couple of days if it is ok.

Is there a tried and true way of getting the MAC to stay put?

That firmware didn't work; it kept crashing. After looking around, for a newer firmware (since that one was from 2017) I found this, where the most recent working firware I found was inside lib-firmware-brcm-20200211. Now this seems to work fine so far (after close to 2 hours) and it also seems to not randomize my MAC address. Some kernel logs:

Quote

[ 17.267370] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43456-sdio for chip BCM4345/9
[ 17.267853] usbcore: registered new interface driver brcmfmac
[ 17.820526] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/9 wl0: Feb 11 2020 11:54:51 version 7.45.96.61 (be7af2d@shgit) (r745790) FWID 01-a41d86bd es7.c5.n4.a3
[ 18.064531] Bluetooth: hci0: BCM4345C5 'brcm/BCM4345C5.hcd' Patch

In fact, this gives me the same MAC address, as the one I had running Armbian, based on the 4.4 kernel, and sure enough, they are the same nvram and firmware files, only on my Armbian installation there was no cl_blob file (but I've installed that too).

One funny thing is that I now see messages like the following now and again:

Quote

[ 32.333391] brcmfmac: brcmf_sdio_bus_sleep: error while changing bus sleep state -5
[ 32.333486] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame
[ 32.333612] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame
[ 32.333700] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame
[ 32.333746] brcmfmac: brcmf_sdio_dpc: sdio ctrlframe tx failed err=-110
[ 32.333758] brcmfmac: brcmf_sdio_dpc: failed backplane access over SDIO, halting operation
[ 32.333864] ieee80211 phy0: brcmf_run_escan: error (-110)
[ 32.333875] ieee80211 phy0: brcmf_cfg80211_scan: scan error (-110)

Display More

As far as I can see, these are not related, as they seem to be communication errors between the chip and the CPU. I also didn't notice them on my first reboot after installing the new firmware. Functionally, the WiFi link seems to be fine, as far as I can see.

I'll confirm that it's still working fine after a day or two, just to make sure. In the meantime, if there are any places I can look for more recent firmware, let me know.

Quote from chewitt

I'd test with/without the clm_blob as those are 100% implementation-specific and can cause issues on the wrong board;

Copy that.

Quote from chewitt

It's all under "version control" but the process isn't what you wrongly assume it to be

Copy that too. I suspected as much and hence am now operating on the assumption that "different version might work better", as opposed to "higher version might work better". I tried all versions in that pinebook related repo, without much success. The version I mentioned in my last message, did indeed work with the correct MAC address and no crashes, much like it did on my old Armbian setup. Unfortunately, it worked exactly the same, including a weird bug, where the board will suddenly be unreachable by some or all machines inside the LAN, while still being able to access the Internet just fine. I have no idea what may be causing that, but it seems to be related to the router as well, as it started only after the last time my ISP saddled me with a new router. Let me know if you suspect anything.

In the meantime, I've found another firmware, dated Jul 6 2020, that seems to be working flawlessly for more than 5 hours now, allowing me to loosely keep my fingers crossed in disbelief. We'll hopefully know in a day or two, or sooner if I'm not lucky.

Quote from chewitt

NB: This has been lurking on our repo for a while https://github.com/LibreELEC/brcmfmac_sdio-firmware/pull/30

I'll have a look once I'm done with the fimware currently under test.

Ugh, this is not going to be easy to get to work properly. Using the latest (as in latest I've tried) Jul 6 2020 driver, the device seemed to work fine for more than 10 hours. Then I went to sleep and the next morning it still seemed to be reachable from the PC and my tablet, but it wasn't reachable from my phone. Usually the PC was that first to be unable to reach it, so I'm not sure if this is the same issue, or just something acting up on my phone's network, or what.

The kernel log contained just these messages from the driver, printed at some point during the night:

Quote

[47811.100500] brcmfmac: brcmf_sdio_bus_sleep: error while changing bus sleep state -84
[47811.100615] brcmfmac: mmc_submit_one: CMD53 sg block write failed -110
[47811.100623] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame
[61855.759177] brcmfmac: brcmf_sdio_bus_sleep: error while changing bus sleep state -84
[61855.759283] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame
[76022.271596] brcmfmac: brcmf_sdio_bus_sleep: error while changing bus sleep state -84
[76022.271707] brcmfmac: brcmf_sdio_txfail: sdio error, abort command and terminate frame

Display More

This makes me think the problem, might be related to powersaving. I've tried to disable it with

iw dev wlan0 set power_save off

We'll see if that helps. If it does, I'll have to figure out a way to make this permanent.

In the meantime, I've also tried contacting Radxa, to ask them about it.

Edit: Forgot to say, that there seem to be other problems, as after a reboot, sometimes the WiFi doesn't come up at all. I have no idea why, as I can't log into the machine without WiFi and I don't know of a way to get to the kernel messages without SSH. I've tried enabling persistent logs, to see if I can find out anything about this, when it happens again.

I've been using the firmware found here for a while and it seems the best I've tried so far. The files in question are ap6256/fw_bcm43456c5_ag.bin and ap6256/nvram_ap6256.txt and the version, as reported by the kernel driver, is:

Quote

Firmware: BCM4345/9 wl0: Jul 6 2020 11:29:52 version 7.45.96.68 (f9ee141@shgit) (r745790) FWID 01-b299bba7 es7.c5.n4.a3

I get no suspicious messages with this firmware and it works well as far as I can see. There are some cases where the device isn't reachable from some of my other LAN devices, but a) this happens rarely, b) it seems to fix itself quickly and c) only happens from the Kore app on my tablet or phone, so that this may well be due to a bug in this app. I haven't had issues connecting via ssh on my desktop machine.

I've also contacted Radxa and they've pointed me to try this image, which contains the firmware reported as

Quote

Firmware: BCM4345/9 wl0: Feb 11 2020 11:54:51 version 7.45.96.61 (be7af2d@shgit) (r745790) FWID 01-a41d86bd es7.c5.n4.a3

mentioned a few messages back. As I've said, I've tried it briefly, and it seemed to work mostly correct too (i.e the proper MAC address was set and retained), but there were a lot of messages about SDIO errors and I seemed to have more of the issues regarding reachability.

It's hard to be very definite, as testing each firmware entails waiting for hours or days for issues to appear, so pehaps the Feb 11 firmware was just as good, but at any rate, I can recommend the one from Jul 6, which I've used for days and seems to work fine, as far as I can tell.

Where should I open the PR? Here, I assume?

chewitt may well be right, but I can confirm that some firmwares, at least for the Broadcom chip in my 4B do indeed fail to load the correct MAC address and instead assign a random MAC address at module load time. This normally happens at boot, but it may also happen during operation if the firmware crashes.

hiimLimp Try loading the firmware I'm currently using. You need to get the files ap6256/fw_bcm43456c5_ag.bin and ap6256/nvram_ap6256.txt from here and copy them to /storage/.config/firmware/brcm/, but under new names. For my 4B the names are brcmfmac43456-sdio.radxa,rockpi4b.bin and brcmfmac43456-sdio.radxa,rockpi4b.txt, I'm not sure what the designator for the Pi 4 SE is, so yours probably need to have something other than rockpi4b in there. chewitt will hopefully know what it is.