AI-in-the-loop: Fixing Raspberry Pi connectivity issues
For a long time, I had a Pi Zero 2W hanging out on my network. Sometimes it woldn't respond, but I always assumed it's because it is such a slow device. After deploying Uptime Kuma, I discovered there was a pattern.
The Pi would respond to ICMP Ping requests with RTT 402±3 ms. Every once in a while it would drop to 2±1 ms RTT, before returning back. Several times every few hours, it would jump up to 900+ ms RTT for one sample, before returning to normal.
Since search engines are borderline unusable these days, especially if you are searching for generic terms like "raspberry pi" and "wifi", I went directly to duck.ai and asked what the cause might be, appending the journal log showing NetworkManager reconnecting. From the six points I was given, two were possible:
Signal quality – Verify RSSI on the Pi (
iwconfig wlan0oriw dev wlan0 link). If it’s below ~‑70 dBm, move the device closer or reduce interference (e.g., other 2.4 GHz devices, microwave ovens).
Power‑saving settings – Some Raspberry‑Pi Wi‑Fi drivers enable aggressive power‑saving, causing the interface to drop after a short idle period. Disable it with
sudo iwconfig wlan0 power offor addwifi.powersave = 2to/etc/NetworkManager/conf.d/default-wifi-powersave-on.conf.
In theory, it could be the air noisy with neighbouring WiFi stations, I measured -77 dBm, but it was too regular for that.
I run iwconfig wlan0 power off, and RTT went straight to 2±1 ms RTT, and stayed there.
"Cool," I thought, "let's see if it's permanent or not."
I restarted and discovered it is not.
"Cool," I thought, "the second option will be permanent for sure, let's do that."
It was, because after subsequent restarts, the Pi didn't connect to the network at all. Fortunately, I always have MicroSD card reader ready: I mounted the card, removed the file, and the Pi booted back up, connecting to my WiFi once again.
NetworkManager.conf(5) doesn't document possible values, you have to follow the text into nm-settings(5), and there it is: NM_SETTING_WIRELESS_POWERSAVE_DISABLE (2). I wouldn't have found this without ArchWiki, to be honest.
ArchWiki also provided a snippet that matched AI suggestion, with an important difference: it assigned it to [connection] section. I set that, rebooted, and I saw both Uptime Kuma calm down, and system logs confirming this was the correct thing to set.
$ dmesg | grep brcmfmac
[ 11.346134] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save enabled
[ 12.316580] brcmfmac: brcmf_cfg80211_set_power_mgmt: power save disabled
Yay!
As an excersise, tried to go back to DuckDuckGo and figure this out again, with no AI.
Nothing.
All of the suggestions were totally irrelevant, with most fixes being "I set the SSID correctly this time" or "I have set up a cron job to restart NetworkManager if it doesn't have conectivity."
Power saving wouldn't have crossed my mind. On my own, I wouldn't have discovered the section-key-value combo, documented in two different places.
Thanks, DuckDuckGo. Since I don't have any subscription nor free account with any of the AI providers, you saved me hours of troubleshooting.