raspberry pi 5 wifi rejected by eero: status_code=16 (and what finally fixed it)

brandon fiquett

if you’ve landed here because your raspberry pi 5 refuses to connect to an eero mesh router and your logs are full of CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00 status_code=16, i spent several hours on exactly this problem. here’s what i tried, what i learned, and what eventually worked — along with an honest admission that i still don’t fully understand why.

the setup

  • pi 5 running raspberry pi os trixie (64-bit, debian 13), kernel 6.12.75
  • eero mesh router, WPA2-PSK, CCMP only
  • pi connected to ethernet for ssh, trying to connect wifi for a wall kiosk display

the symptom: every wifi association attempt fails immediately with status_code=16. in IEEE 802.11 terms, that means “AP unable to handle additional associated STAs” — but the eero had fewer than a dozen clients. it wasn’t actually full.

what i ruled out

i went deep. here’s everything that didn’t fix it:

kernel version — tested both 6.12.75 (stable) and 6.18.20 (experimental rpi-update). both fail identically.

firmware binary — the BCM43455 firmware (cyfmac43455-sdio-standard.bin, version 7.45.265) is byte-for-byte identical across pi 3b+, pi 4, pi 5, pi 500, and pi CM5. all share checksum 64410bcb. not the issue.

nvram — the pi 5 nvram (brcmfmac43455-sdio.raspberrypi,5-model-b.txt) differs from the pi 3b+ nvram only in btc_mode (0 vs 1). that controls bluetooth coexistence, not wifi association.

bluetooth coexistence — setting btc_mode=0 and stopping the bluetooth service eliminates an early failure mode (BCME_DISABLED, -110) but doesn’t fix the status_code=16.

MFP / 802.11w — the eero advertises MFPC=0, MFPR=0. running wpa_supplicant with ieee80211w=0 and confirming mfp=0x00000000 is set via brcmfmac iovar. not the issue.

RSN IE content — with brcmfmac FIL+BYTES debug enabled, confirmed wpa_supplicant sends a textbook-minimal WPA2-PSK RSN IE: group cipher CCMP, pairwise CCMP, AKM PSK-only, RSN capabilities 0x0000. RSNXE is empty (len=0). everything correct.

WPA3/SAE — the eero’s main SSID advertises PSK only (no SAE). the eero does have SAE-only BSSIDs (different MAC addresses, no public SSID) that are for backhaul/management. attempting WPA3-SAE connections didn’t help.

MAC address spoofing — tried a completely random MAC (never-seen-before OUI). eero still rejected with status_code=16. rules out per-MAC banning.

iwd instead of wpa_supplicant — same result. also revealed: after WPA2 failures, iwd reported “FullMAC driver: brcmfmac using SAE. Expect EXTERNAL_AUTH” — the pi 5’s brcmfmac_wcc module enables SAE external authentication, which iwd detected as a fallback path.

feature_disable=0x282000 — the RPi OS ships /lib/modprobe.d/rpi-brcmfmac.conf with this flag, which disables BRCMF_FEAT_SAE_EXT and BRCMF_FEAT_SAE_EXT_H2E. if you’ve ever touched /etc/modprobe.d/brcmfmac_cyw.conf (see below), you may have silently overridden this. adding it back didn’t fix the eero rejection in my case, but it’s still worth having.

the brcmfmac_cyw.conf gotcha

this is worth documenting even though it wasn’t my root cause.

the pi 5 uses a kernel module called brcmfmac_wcc (sometimes referred to as brcmfmac_cyw in older discussions). it’s a small (~12KB) plugin that extends brcmfmac to handle SAE external authentication on the pi 5’s BCM43455 chip. without it, wlan0 never initializes.

the RPi OS ships /lib/modprobe.d/rpi-brcmfmac.conf with:

options brcmfmac roamoff=1 feature_disable=0x282000

if you create /etc/modprobe.d/brcmfmac_cyw.conf (which various debugging guides suggest), it silently overrides the system default. if your file only has:

options brcmfmac roamoff=1

…then feature_disable=0x282000 is gone. your /etc/ file wins over /lib/.

the fix is to include it explicitly:

options brcmfmac roamoff=1 feature_disable=0x282000
options brcmfmac_wcc roamoff=1

what brcmfmac_wcc actually does

the module’s exported symbols are: brcmf_wcc_set_sae_pwd, brcmf_wcc_alloc_fweh_info, brcmf_set_wsec, brcmf_fwvid_register_vendor.

it registers as a vendor firmware plugin, sets up firmware event handling, and enables SAE external auth. it’s the reason wpa_supplicant’s key_mgmt includes SAE and FT-SAE even when you’re connecting to a WPA2-PSK network.

the firmware is FullMAC — it builds 802.11 management frames (probe requests, association requests) internally. you can set ieee80211w=0 in wpa_supplicant all day, but the firmware decides what IEs actually go on the air. without monitor mode (not supported on brcmfmac FullMAC), you can’t directly inspect what the pi 5 is advertising in its probe requests.

my working theory: brcmfmac_wcc causes the firmware to include RSNXE (RSN Extension Element) in probe requests, advertising WPA3/SAE-H2E capability. the eero, in WPA3 Transition Mode, may treat WPA3-capable clients differently at the association level. but i can’t prove this without a packet capture from a monitor-mode device.

what actually fixed it

a clean reboot.

after 3+ hours of debugging with repeated rmmod/modprobe cycles, SAE connection attempts, and dozens of failed association attempts, i rebooted the pi with this modprobe config:

# /etc/modprobe.d/brcmfmac_cyw.conf
options brcmfmac roamoff=1
options brcmfmac_wcc roamoff=1

on the next boot, NetworkManager connected to the eero immediately. no changes to wpa_supplicant configuration, no new nvram, no different kernel.

most likely explanation: repeated failed association attempts caused the eero to rate-limit or soft-ban the pi 5’s MAC address. the gap during reboot cleared that state. a full hardware power cycle of the pi 5 also ensures the SDIO wifi chip initializes cleanly — after enough rmmod/modprobe cycles, the chip can end up in an undefined state that survives module reloads but not a full power cycle.

if it breaks again

in order of things to try:

  1. power cycle both the pi and the eero. hold the eero’s reset button for a normal restart (not factory reset) or unplug it for 30 seconds.
  2. check /etc/modprobe.d/ for brcmfmac overrides that might be dropping feature_disable=0x282000.
  3. confirm btc_mode=0 in nvram if you’ve modified it. BT coex issues (BCME_DISABLED) are a separate failure mode that appears before the eero ever sees the association request.
  4. try a different MAC (ip link set wlan0 address XX:XX:XX:XX:XX:XX) to rule out eero rate-limiting.

if you found the actual root cause — especially if you captured 802.11 frames comparing a pi 3b+ and pi 5 association request against the same eero BSSID — i’d genuinely like to know. the brcmfmac_wcc behavior on pi 5 is not well documented.

Leave a Reply