Hardware
• Raspberry Pi 3 Model B Plus Rev 1.4
• AllStarLink v3 (Debian Bookworm base)
• Kernel: 6.12.34+rpt-rpi-v8 (#1 SMP PREEMPT Debian 1:6.12.34-1+rpt1~bookworm)
Summary
• This node ran for months with rock-solid uptime on wired Ethernet.
• Recently moved it to Wi-Fi and on Sept 15 applied ~79 package updates including:
raspberrypi-kernel (to 6.12.34)
systemd / udev
wpasupplicant
wireless-regdb
• Since that update the node will randomly drop completely off the network:
No SSH, Cockpit web UI, or AllStar connectivity.
Requires a hard power-cycle to recover.
• Wired Ethernet remains perfectly stable.
Logs / symptoms
• dmesg and syslog show brcmfmac (Broadcom Wi-Fi) driver messages and repeated
regulatory-domain changes.
• Example:
nl80211: kernel reports: Registration to specific type not supported
• Asterisk service stays healthy once the system is back up.
• Filesystem usage low (10 % on /); no CPU or memory pressure.
Steps tried
• Hard power-cycle brings it back every time.
• Set regulatory domain to Canada:
sudo iw reg set CA
echo 'REGDOMAIN=CA' | sudo tee /etc/default/crda
• Considering kernel hold or rollback, or reverting to wired.
Ask
• Has anyone else seen Wi-Fi instability on AllStarLink v3 / Debian Bookworm
after the 6.12.34 kernel update on a Raspberry Pi 3B+?
• Is there a recommended fix, kernel pin, or patch, or should I stay wired
until a newer kernel is released?
Just a recommendation here but maybe try rebuilding a new SD card. A secondary one. See if the wifi still does the same thing. I dont use WiFi on any of my nodes just because I always felt wifi was unstable to begin with. Not blaming the Pi either but if you can try it on another pi and new SD card see if the WiFi drops
That almost makes it sound like your system is fighting over wpa_supplicant vs. NetworkManager to manage wireless. Did you try to alter the networking configuration with raspi-config or some other tool that isn't nmcli or nmtui or Cockpit?
I could certainly do that—I’ve got a spare card on hand—but the trouble only started right after the last patch cycle.
Normally I keep everything wired, but since I needed to move the Pi while rearranging part of the shack, I figured I’d try wireless. It also seemed like a good chance to test Wi-Fi for possible remote or travel use down the road.
Have not, but I will look into that again at all is working fine for weeks, flawlessly wired, and seemed pretty stable on Wi-Fi until the last patch cycle.
Thanks for the suggestion! From what I gather, rpi-eeprom-update updates the Pi’s bootloader firmware—the EEPROM that controls low-level hardware behavior such as USB/SD boot order, power-management quirks, and some USB/PCIe fixes. My understanding is that it usually isn’t part of routine AllStar maintenance unless you’re troubleshooting boot failures or need new boot features.
The node boots and runs fine apart from the wireless dropouts I’ve been chasing since the last patch cycle. I haven’t changed networking with raspi-config or similar—only ASL’s asl-menu, Cockpit, and the occasional text edit with vi or pico depending on my mood.
Could you expand on how an EEPROM update might influence Wi-Fi stability in this case? I’d like to understand the link before flashing new firmware
Quick follow-up:
Uptime is about 21 hours now since I set the regulatory domain to Canada . No hangs or lock-ups so far—it’s been solid all day. I generally have it on the air from around 7 AM to 7 PM for a variety of nets and routine use.
Without any arguments, the command only checks if any firmware updates are available. But, looking a bit more closely, you need a Pi that has a boot EEPROM (RPi4, RPi5, ...). Your RPi3 does not have an EEPROM.
