It’s very rare to have such breakage with Debian, and it will be pretty problematic for people with remote Raspberry Pis. I had to manually plug network cables into a Raspberry Pi 5, 4 and 2 Zero 2’s to add the following file in order to get them to work on WiFi. Reading an earlier post it had to do with handshake and encryption not being handled properly… The taking out of my two Pi Zero 2’s was irritating as they’re the home network Pi-Hole/Unbound DNS servers, so I switched the router to Quad9 which was convenient from hearing the Quad9 interview yesterday. A lot of people with remote Raspberry Pi’s using unattended-upgrades are going to be really upset, especially if they’re on a mountain top or really remote. The link below is to the bug report with additional comments. With Debian going pretty woke and people using AI coding assistance, did this lead to inadequate testing and a flawed patch? Maybe we’ll get an entertaining Lunduke video.
Workaround in use here, keeping
2:2.10-24+rpt1: a same-named/etc/modprobe.d/rpi-brcmfmac.confthat shadows the/usr/lib/modprobe.dcopy. The kernel command line stays untouched, and brcmfmac isn’t in the initramfs underMODULES=dep, so noupdate-initramfsis needed:options brcmfmac roamoff=1 feature_disable=0x2282000With it,
auth_algreportsOPEN SHARED LEAP, NetworkManager configureskey_mgmt 'WPA-PSK WPA-PSK-SHA256 FT-PSK', and the connection comes up askey_mgmt=WPA2-PSK. Bit 25 =SAE_EXTmatchesBRCMF_FEAT_LISTinrpi-6.18.y‘sfeature.h. Alternatively, at least on the 43455, storing the passphrase instead of the hash makes WPA3 work without touching the driver.