Hello AltArch team,
I’m running Rocky Linux on a Raspberry Pi 3B+ at Lawrence Berkeley National Lab (LBNL). LBNL is migrating its open guest network from a plain unencrypted SSID (`lbnl-visitor`, deprecated by 2027) to one based on Wi-Fi Enhanced Open / OWE (`lbnl-open`). I expect many institutional and university Pi deployments will hit the same wall as more sites turn on OWE for their guest networks.
Hello!
Can you share a few more details? what version are you looking for specifically? our non-free package is the latest firmware in the buster branch which is November 2021.
--Bryan
@codedude Just out of interest, is there any reason it’s based on Buster? That’s Debian 10. Latest Debian is 13 (trixie) so since then there has also been bullseye and bookworm (debian 11 and 12). From this github repo: GitHub - RPi-Distro/firmware-nonfree · GitHub would suggest there is changes since 2021. Trixie is currently set as the latest branch with changes in 2025.
just an oversight on my part. Planning to rework it once I get a little free time. hopefully in the next few days.
I’ve made some tests on my raspberry Pi with rocky Linux 8.10 installed. I’ve send the results in attached file.
(Attachment owe-firmware-test.sh is missing)
(Attachment owe-firmware-test-report.txt is missing)
Hello,
I have an script that tested the connection on my Raspberry Pi running Rocky Linux 8.10. Below the script and the results:
┌──(root@raspi16)-[/home/rocky]
└─# cat owe-firmware-test.sh
#!/usr/bin/env bash
Hi Bryan,
Ran a structured reproducer on the affected Pi and want to share both the results and a correction to my earlier message.
Correction: I told you rpi-firmware-nonfree was the package providing the bad firmware. That’s not what’s happening on my system. The brcmfmac43455-sdio.bin file is actually owned by:
linux-firmware-20260112-135.git486ac8f9.el8_10.noarch (Vendor: Rocky)
The linux-firmware package release is dated January 2026, but the Cypress blob inside it is still the 2021 build (Apr 15 2021 ... version 7.45.234) that lacks OWE. So upstream linux-firmware itself hasn’t picked up the newer Cypress firmware that landed in RPi-Distro/firmware-nonfree’s bookworm branch.
That means the fix path may not actually be in rpi-firmware-nonfree at all — unless that package is meant to override /lib/firmware/brcm/brcmfmac43455-sdio.bin from linux-firmware and isn’t currently doing so on Rocky 8.10. Could you confirm whether rpi-firmware-nonfree is supposed to take precedence over linux-firmware for this file, and whether it’s actually installed/effective on a stock Rocky aarch64 image? My system shows the file owned by linux-firmware, which is what made me realize my earlier assumption was wrong.
Reproducer details:
Wrote a diagnostic script that gathers system/firmware/driver info, scans for OWE networks, optionally attempts association, and produces a structured report with a verdict. Output for my Pi 3B+ on Rocky 8.10:
BCM4345/6 wl0: Apr 15 2021 03:03:20 version 7.45.234 (4ca95bb CY) FWID 01-996384e298837BEF945177828BED396lbnl-open)brcmf_set_key_mgmt: invalid akm suite (1027090) (= 0xFAC18 = OWE) + wl_set_key_mgmt failed (-22) (= -EINVAL)The 1027090 decimal is what the driver prints; in hex it’s 0xFAC18, IEEE 802.11 AKM suite OUI 00-0F-AC type 18 = OWE per IEEE 802.11-2020 Table 9-151. So the driver knows OWE and tries to push it; the firmware blob doesn’t recognize the suite ID.
The script is portable — happy to share it if you’d like to run the same diagnostic on your test rig to confirm baseline state, or use it to verify any candidate firmware update against a real OWE network. It has three modes:
--info: read-only, no network changes (safe anywhere)--scan: adds an active scan for OWE BSSes (still no association)--test SSID: attempts OWE association with full revert-on-exit safetyLayered picture, in case it’s helpful for triage:
set_key_mgmt. 
So the fix really is at the firmware-blob layer alone, but the question now is which package owns the path on Rocky aarch64.
Thanks again — happy to provide any other data that would help.
Hi Bryan,
One more correction — and this changes the picture meaningfully.
I looked at the rpi-firmware-nonfree.spec file in the Rocky source repo, and noticed something I’d missed: for the BCM43455 chip (Pi 3B+ / Pi 4 / Pi 5), the package only ships brcmfmac43455-sdio.txt, not the actual firmware blob. The .bin and .clm_blob for that chip come from linux-firmware. From the spec’s %install:
cp brcm/brcmfmac43436s-sdio.{bin,txt} %{buildroot}%{_fwpath}/brcm/ # Pi Zero 2W — .bin shipped
cp brcm/brcmfmac43455-sdio.txt %{buildroot}%{_fwpath}/brcm/ # BCM43455 — .txt only
cp brcm/brcmfmac43456-sdio.txt %{buildroot}%{_fwpath}/brcm/
cp brcm/brcmfmac43456-sdio.bin %{buildroot}%{_fwpath}/brcm/
cp brcm/brcmfmac43456-sdio.clm_blob %{buildroot}%{_fwpath}/brcm/
On my Pi the .bin and .clm_blob for 43455 are owned by linux-firmware-20260112-135.git486ac8f9.el8_10.noarch, confirming this.
So — if I’m reading this correctly — bumping the %global nonfree_commit alone wouldn’t actually fix OWE on Pi 3B+/4/5 even if pointed at bookworm, because the spec doesn’t install the 43455 .bin to begin with. The newer firmware in the bookworm tarball would just sit unused.
The real fixes (as I see them, happy to be corrected):
Upstream linux-firmware refresh — the proper long-term home for the Cypress blob. But this depends on kernel.org’s linux-firmware tree picking up the newer Cypress build, and then RHEL/Rocky inheriting it. Not in the SIG’s direct control.
Extend rpi-firmware-nonfree to also ship brcmfmac43455-sdio.bin and brcmfmac43455-sdio.clm_blob from a bookworm SHA, with file precedence over linux-firmware. This is a more invasive change — needs RPM conflict resolution and probably a Conflicts: or Obsoletes: clause on the linux-firmware file path, plus testing on Rocky 8 and 10. But it’s what would actually fix OWE for end users on current hardware without waiting on upstream.
For reference, the bookworm firmware-nonfree changelog shows the most recent firmware update was (1:20240709-2~bpo12+1+rpt1) in March 2025: “Add/update Raspberry Pi WLAN firmware”. That’s the build that should carry OWE for the BCM43455.
On the install side: rpi-firmware-nonfree is not currently installed on my Rocky 8.10 Pi (rpm -q rpi-firmware-nonfree → not installed). I’ll try dnf install to see whether it’s at least reachable from the default Pi image’s repos and report back.
Sorry for the back-and-forth on the diagnosis here — the layering between linux-firmware, rpi-firmware-nonfree, and what each actually puts on disk took me a couple of passes to untangle. Hopefully this version is closer to right; let me know what I’m still getting wrong.
Hi Bryan,
Follow-up to my last message — ran the install check and it confirms what I was suspecting. Three independent findings, each of which on its own means a bump of rpi-firmware-nonfree wouldn’t fix OWE on Pi 3B+/4/5:
1. The firmware file /lib/firmware/brcm/brcmfmac43455-sdio.bin is owned by linux-firmware, not rpi-firmware-nonfree:
# rpm -qf /lib/firmware/brcm/brcmfmac43455-sdio.bin
linux-firmware-20260112-135.git486ac8f9.el8_10.noarch (Vendor: Rocky)
2. rpi-firmware-nonfree.spec (at commit bda9207) doesn’t %install the 43455 .bin to begin with — only the .txt board config:
cp brcm/brcmfmac43455-sdio.txt %{buildroot}%{_fwpath}/brcm/
The .bin and .clm_blob for 43455 are simply not copied out of the source tarball into the package payload. (Compare to brcmfmac43456 in the same spec, where all three files are installed.)
3. rpi-firmware-nonfree is not reachable from a stock Rocky 8.10 Pi image — even with the AltArch repos enabled:
# rpm -qa | grep -E 'rocky-release|sig'
rocky-release-8.10-1.11.el8.noarch
rocky-release-altarch-8-5.el8.noarch
rocky-release-rpi-8.0-3.el8.noarch
# dnf repolist
altarch-common Rocky Linux 8 - SIG AltArch Common
altarch-rockyrpi Rocky Linux 8 - Rasperry Pi
appstream Rocky Linux 8 - AppStream
baseos Rocky Linux 8 - BaseOS
extras Rocky Linux 8 - Extras
# dnf install rpi-firmware-nonfree
No match for argument: rpi-firmware-nonfree
Error: Unable to find a match: rpi-firmware-nonfree
So the OWE fix path on Rocky 8 for Pi 3B+/4/5 isn’t really through rpi-firmware-nonfree at all — it would have to be one of:
(A) A refresh of the linux-firmware package itself with a newer Cypress brcmfmac43455 build. This is the upstream-correct path but depends on kernel.org’s linux-firmware tree and then RHEL backports.
(B) Expand rpi-firmware-nonfree to also ship brcmfmac43455-sdio.bin and .clm_blob from a bookworm SHA, take file precedence over linux-firmware via RPM conflict handling, and make sure it’s actually in the altarch-rockyrpi repo’s package set so a dnf install finds it.
(C) Some completely different mechanism I’m not aware of — if there’s a kernel-rpi-firmware or similar package that’s the intended owner of this path, I’d want to understand the architecture before assuming.
Looking at the Rocky 9 Pi forum thread about kernel-rpi-firmware-6.6.77-7.el9.altarch boot issues, it seems like the firmware story on the Pi side has multiple moving parts (linux-firmware, rpi-firmware-nonfree, kernel-rpi-firmware, bcm283x-firmware), and I’m probably not seeing the full picture from outside the SIG. Would appreciate any pointers on which of those owns the brcmfmac userspace firmware on a current Rocky 8 / Rocky 10 image, since that’s where the fix would need to land.
Thanks for your patience as I work through the layers — I think the technical question is now well-specified, but I don’t know enough about the AltArch package architecture to propose a clean fix path. Happy to keep testing.
Thanks for all the details.
You are correct, in Rocky 8, it was just the linux-firmware package plus perhaps one of the brc*-firmware packages. In 9, we started shipping the nonfree package to fix odd wifi issues etc. the forum post about boot issues is related to the board firmware(eeprom) that we ship with our kernel-rpi package. Due to the age of our pi kernel, the rpi board firmware cant be the newest. I’m not sure we wanna try to override whats in linux-firmware and unfortunately at the moment, i dont have any good suggestions for a fix.
--Bryan
Thanks Bryan, that’s helpful context — especially the clarification that kernel-rpi-firmware is the eeprom/board firmware rather than the brcmfmac userspace blob. I had those crossed in my head and appreciate you straightening it out. And completely understand the reluctance to override linux-firmware; file precedence between packages is a real maintenance burden.
Before the thread goes quiet, I wanted to share the full test matrix I ran while diagnosing this — partly so it’s on the record for anyone else who searches and lands here, and partly in case the scope is wider than you’d realized. I tested across both Pi models I have access to and every Rocky version that supports either one:
| Rocky | Pi model | Kernel | wpa_supplicant | Cypress firmware |
|---|---|---|---|---|
| 8.10 | 3B+ | 6.1.31-v8.1.el8 | 2.10 | Apr 15 2021 / 7.45.234 |
| 9.2 | 3B+ | 6.1.23-v8.1.el9 | 2.10 | Apr 15 2021 / 7.45.234 |
| 9.2 | 4B | 6.1.23-v8.1.el9 | 2.10 | Apr 15 2021 / 7.45.234 |
| 10.1 | 4B | 6.6.77-8.el10 | 2.11 | Apr 15 2021 / 7.45.234 |
Userspace and kernel advance across releases, but the brcmfmac43455-sdio.bin blob from linux-firmware is byte-identical (same FWID 01-996384e2) on every combination. So no Rocky version on any currently-supported Pi can do OWE today — the gap is purely the Cypress blob shipped by upstream linux-firmware.
That’s why I went looking at rpi-firmware-nonfree in the first place — I was hoping there was a Pi-side override path. Now that you’ve confirmed linux-firmware is the right home for this and the SIG doesn’t want to override it, I think the realistic path is the kernel_dot_org linux-firmware tree refreshing the Cypress blob and Rocky inheriting it. That’s slow but architecturally correct.
If it would help, I’d be glad to:
--info mode is safe anywhere) so anyone investigating this later has a clean reproducer.linux-firmware directly if you think that’s the right venue — I’m not sure whether kernel_dot_org’s linux-firmware maintainers prefer reports through their mailing list, or whether this should go through RHEL/Red Hat Bugzilla as the downstream consumer.For my specific Pi, I’m moving it to lbnl-iot (WPA2-PSK on registered MACs, works fine on the 2021 firmware) since it’s a shared lab device. That unblocks me without needing any firmware changes, but anyway this is a limitation for me and other people in the future.
Thanks again for the time you’ve put into this. Even if no fix is immediately forthcoming, the diagnosis is now well-documented for whoever revisits.
Oh i misspoke. We dont ship the eeprom firmware. The boot issues are due to the gpu firmware/kernel combo being so old. if you update the eeprom to the latest firmware, it wont boot. Sorry about that.
I think “maybe” we can update our nonfree package at a minimum. I need to look at it a bit closer and see if that’ll solve the issue. Its only for 9 though, will that be a problem?
Hi Bryan,
Quick update with what I learned from the RPi-Distro side, which I think changes the picture in a useful way.
I filed a request with them (Submit bookworm-branch cyfmac43455-sdio firmware to upstream linux-firmware · Issue #55 · RPi-Distro/firmware-nonfree · GitHub) asking they upstream the newer cyfmac43455 firmware to kernel.org’s linux-firmware. Phil Elwell declined and pointed at a prior issue (#47) and a comment from XECDesign (Raspberry Pi staff) on bluez-firmware #15:
“These aren’t our files, we have as much ‘authority’ here as anybody else. … The upstream README says: ‘Your commit must contain a Signed-Off-By: from someone authoritative on the licensing of the firmware in question (i.e. from within the company that owns the code).’”
The upshot: even Raspberry Pi staff don’t have a privileged relationship with Cypress that lets them submit upstream. The kernel.org Signed-off-by requirement effectively means only Cypress/Infineon employees can submit newer Cypress blobs to linux-firmware, and they apparently haven’t since 2021. Waiting for upstream isn’t a path.
Another RPi-Distro thread participant (macmpi, Alpine packager) pointed at a cleaner approach that directly addresses your concern about overriding linux-firmware: don’t override it — ship the firmware under board-specific filenames that brcmfmac’s resolution chain tries first, at paths that currently have no file at all.
Here’s the evidence from journalctl -k -b on a Rocky 10 Pi 4B (no sudo needed, survives dmesg -C):
Aug 15 00:00:08 localhost kernel: brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.bin failed with error -2
Aug 15 00:00:08 localhost kernel: brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Apr 15 2021 03:03:20 version 7.45.234 (4ca95bb CY) FWID 01-996384e2
The kernel first tries brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.bin, fails with -2 (file genuinely doesn’t exist), then falls back to brcm/brcmfmac43455-sdio.bin — which on Rocky is a symlink to ../cypress/cyfmac43455-sdio.bin.xz, the upstream linux-firmware blob from 2021.
Verifying the empty board-specific paths on Rocky 10:
$ ls /usr/lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.bin.xz 2>&1
ls: cannot access ...: No such file or directory
$ ls /usr/lib/firmware/brcm/brcmfmac43455-sdio.raspberrypi,4-model-b.bin.xz 2>&1
ls: cannot access ...: No such file or directory
So a Rocky Pi-specific firmware package would ship the bookworm-vintage firmware (2023-08-29 build, OWE/SAE-capable) as:
brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.bin.xz + matching .clm_blob.xzbrcm/brcmfmac43455-sdio.raspberrypi,4-model-b.bin.xz + matching .clm_blob.xzBoth are currently nonexistent paths — no linux-firmware file to conflict with. The brcmfmac driver picks these up automatically via the device-tree match. The linux-firmware symlinks and the underlying cypress/cyfmac43455-sdio.bin.xz stay completely untouched and continue serving any non-Pi BCM43455 deployment (and any Pi without this package installed). It’s literally additive — the package just creates new files at currently-empty paths.
(Pi 5 is slightly different — linux-firmware already ships a symlink at the ,5-model-b.bin.xz path, so a clean addition isn’t available there. Could be handled with a %post script or just left for a follow-up. Pi 3B+ and Pi 4B are the clean case.)
This is the same pattern Debian’s firmware-brcm80211 and Raspberry Pi OS use in production, so the mechanism is well-validated against the brcmfmac driver Rocky ships.
I confirmed the bookworm firmware contains OWE and SAE protocol support:
$ strings cyfmac43455-sdio-standard.bin | grep -ic owe
11
$ strings cyfmac43455-sdio-standard.bin | grep -ic sae
6
(Rocky’s currently shipped 2021 blob returns zero for both.)
Would the SIG be open to revisiting this with the board-specific-naming approach in mind? It’s a much smaller maintenance surface than my earlier suggestion — a Pi-only package that ships ~1.5 MB of files at paths linux-firmware doesn’t touch. Happy to test candidate builds against real OWE infrastructure (LBNL’s lbnl-open deployment) on Pi 3B+ and Pi 4B if useful.
If the answer remains no, totally understood and I’ll stop pushing — just wanted to make sure the specific mechanism was on the table before closing this out, since it sidesteps the override concern entirely.
Thanks again for the engagement.
Final update on this thread.
Tested the same Pi 4B with Raspberry Pi OS Trixie (Debian 13, kernel 6.12.75+rpt-rpi-v8) booted from a separate SD card. Same hardware, same cyfmac43455-sdio firmware (Aug 29 2023, version 7.45.265 (28bca26 CY)), much newer kernel and brcmfmac. Same OWE association failure:
ieee80211 phy0: brcmf_set_key_mgmt: invalid akm suite (1027090)
ieee80211 phy0: brcmf_cfg80211_connect: wl_set_key_mgmt failed (-22)
This rules out Rocky-specific issues. The brcmfmac driver in Pi OS Trixie pushes the same OWE AKM suite and hits the same -EINVAL rejection from the firmware command interface. The 2023 Cypress firmware build does not actually implement OWE on the BCM4345/6 (CYW43455) chip, despite containing “OWE” strings in the binary.
Conclusion: OWE on Raspberry Pi 3B+/4B/5 is not currently possible with any Linux distribution. The blocker is Cypress/Infineon firmware, not driver or distro packaging. Withdrawing my earlier suggestion about packaging newer firmware in Rocky — it wouldn’t fix the user-visible problem.
For Rocky/RHEL/Pi users who need OWE, alternatives are:
Thanks again, Bryan and macmpi, for the engagement on this.