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:

    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?

    Code
    Direct firmware load for brcm/brcmfmac43456-sdio.radxa,rockpi4b.bin failed with error -2
Direct firmware load for brcm/brcmfmac43456-sdio.clm_blob failed with error -2

    ^ Those are harmless messages; the driver looks for board-specific firmware/nvram files before falling back to generic files, and it's rare to see any devices have clm_blob (board-specific performance tuning) files available.

    Your board will be using generic files, so there's two things to try:

    a) Update to a current LE12 nightly so you're using a recent kernel that may have driver fixes.

    b) Some boards need specific firmware/nvram config as generic files cause problems. So I'd have a look in Radxa GitHub repos (or Armbian) to see what they ship with that board. If you put the files in /storage/.config/firmware/brcm/ with the filename brcmfmac43456-sdio.radxa,rockpi4b.bin (firmware) and brcmfmac43456-sdio.radxa,rockpi4b.txt (nvram) and reboot, they will be used instead of the generic files. If that fixes the problem point me to links and we can add them to our images.

    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.

    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:

    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.

    I'd test with/without the clm_blob as those are 100% implementation-specific and can cause issues on the wrong board; and it would not surprise me if Radxa blindly copied the files in their repo from somewhere like Armbian (look mum it works.. job done). I'm also unsure that brcmfmac supports the same naming overrides for clm_blob as the bin/txt files? (something to test).

    I'll also comment that "newer is not necessarily better" as Broadcom (like all SoC/chip vendors) fork code for each new customer project; creating the opportunity for all-new and exciting bugs that don't exist on previous/older forks previously created for a different customer. It's all under "version control" but the process isn't what you wrongly assume it to be :)

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

    I have fuzzy memory of testing the files on an Amlogic S912 board when it was PR'd and it broke WiFi so I didn't merge; but I should probably go back and test again. The problem with these files is - they are all supposed to be board-specific which makes packaging for a generic distro a "choose your compromise" game.

    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:

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

    Bash
    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.

    dpapavas , were you able to resolve the issue you encountered? I'm facing a similar challenge with my Rock Pi 4 SE, where the MAC address changes unpredictably with each reboot and even during operation. Interestingly, this issue doesn't arise when I'm running LibreElec 10.0.4. However, with versions 11.0.6 and the beta 12, the MAC address inconsistency persists. If you've managed to rectify this, could you kindly guide me on how to update the firmware using the solutions provided in this thread?

    This is normally a failure of u-boot to read a factory programmed MAC from efuse; which is then populated to device-tree and used by Linux once it's booted. In some cases the MAC wasn't programmed. In others it's been programmed to a different efuse location on your board-type to the location that u-boot expects. I'd hazard a guess that u-boot needs tweaking with a custom board file so that u-boot knows how to read it from a Rock Pi 4 SE vs a generic RK board and that change probably exists in Radxa's downstream u-boot fork but hasn't been upstreamed to the mainline u-boot source that LE is using. Ask Radxa..

    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.