Wifi Drops out after update to 8.14.2

Bug report/issue

Required Information

  • DietPi version | cat /boot/dietpi/.version
    G_LIVE_PATCH_STATUS[0]=‘not applicable’

  • Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
    bullseye 0

  • Kernel version | uname -a
    Linux headphoneberry 5.15.84-v8+ #1613 SMP PREEMPT Thu Jan 5 12:03:08 GMT 2023 aarch64 GNU/Linux

  • SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
    RPi 4 Model B (aarch64)

  • Power supply used | (EG: 5V 1A RAVpower)
    OKDO Raspberry Pi 4 Power Supply

  • SD card used | (EG: SanDisk ultra)
    SanDisk 32 GB

Additional Information (if applicable)

  • Software title | (EG: Nextcloud)

  • Was the software title installed freshly or updated/migrated?

  • Can this issue be replicated on a fresh installation of DietPi?
    I want to use the same installation and don’t want to wipe it.

  • Bug report ID | echo $G_HW_UUID

Steps to reproduce

  1. Turn on raspberry pi
  2. Wait for network connection and see Roon recognise the device
  3. SSH to raspberry pi
  4. Run htop
  5. Eventually htop no longer updates and ssh no longer responds and device drops out of Roon (usually 1-2 minutes

Expected behaviour

Network stays up and connected

Actual behaviour

Device disconnects from Wifi

Extra details

These are thoughts I’ve had about the problem or fact I think may be relevant or they could be irrelevant and contradictory, but I’m not complete sure so I hope enough of my own research helps.

  • When I connect to Ethernet and run dietpi-config I can view Network Options: Adapters and it shows that Wifi is Available, on, but disconnected. However, I am connected via SSH to the Wifi static IP at the time. So is it disconnected or not? When I use Wifi only and have enough time to look at the same screen before the network drops it is Available, on and connected. Confusing.
  • During update a message saying something like “crda package/files were deleted because these can now be downloaded” and I approved the deletion - this was related to wifi config.
  • I use channel 161 and had to update dietpi to allow access to these higher channels by setting location to US (if I remember correctly)
  • I have Unifi U6 Mesh and use “Lock to Access Point” functionality - two other raspberry pi are also connected in the same way and work fine. If I turn this off I get the same problem, but I intend to turn it back on once this issue is resolved
  • This raspberry pi is on a different linux kernel to other ones I have as it is a pi that was built from a later image of dietpi. However, this has been running fine for almost a year.

independent from your issue, all RPI should have same kernel version if you successfully updated DietPi to latest version. Because our update process will trigger an apt upgrade which should update RPI kernel version as well.

These are the uname -a from the other two, should I try to upgrade these two also? I’d probably wait until this issues is fixed.

Linux hostname 5.10.103-v8+ #1529 SMP PREEMPT Tue Mar 8 12:26:46 GMT 2022 aarch64

Are you running Debian Bullseye on all if your device or some still running Buster?


I have 3 Pis that I bought and set-up in april 2021 (pre-Bullseye) and so they all use Buster. Then in 2022 I got another one and the latest image I used was Bullseye. I’ve not upgraded the Buster ones yet, I was just happy ensuring they were on the latest dietpi release and didn’t see a need to upgrade to Bullseye.

Ok at least this explains the difference on kernel version.

1 Like

Back to my original problem, I’ve done some investigating and it was the crda package and config that was changed and automated. [Link to Debian reference]

When I got a new router I had to get all of my Raspberry Pis set to the US because I use 5Ghz WiFi channels around 161 at home. In the UK these are permitted for short range devices and my router supports them. I think the Raspberry Pi is a short range device and felt this legitimate.

My current theory is that this change to the Raspberry Pi that is not working lead to the removal of that crda package and whatever automatic set-up that replaced, which has overidden my forced setting of location and so it connects correclty, downloads the location and then disables wireless based on that downloaded config.

Why WiFi works somewhat when I plug in an Ethernet cable seems odd as it contradicts that theory.

If my theory is correct, how can I set my location or otherwise enable these WiFi channels. There is a lot of interference below these channels, which is why my router switched to them and why I want to use them.

I’ve been able to get everything working on a lower 5 GHz channel (140).

Reading this guide saying I was operating without a licence (eek!) and this from Ofcom (UK regulator) I can see why those channels were skipped. Even if technically I could use them with the Raspberry Pi.

1 Like

thx for sharing, good to keep this in mind if someone else is running into similar issues.

1 Like

I guess it’s a Debian thing, but my router apparently is using the right channels for the location as do all my other devices, which happily use these channels. It is only the Debian location based channel permissions that stop this on my Pi. Maybe there will be an update to this soon.

Thanks for the conversations. I’m now updating everything to Bullseye.

You are aware on our guide? DietPi - How to upgrade to "Bullseye" - DietPi blog
I might gonna help on your journey.

1 Like

Yes thanks, I saw a link in the MotD on login and have now upgraded all. The guide was useful, although a couple of commands didn’t work and I had to manually edit /etc/apt/sources.list

Ok good you could fix it. Hope it’s running well now.

1 Like

I have a similar behaviour. System running with Dietpi 8.10. for half a year without problem.
After updating to 8.14.2 this week all seems to be ok - until an reboot. Now - no ping, no SSH, no access anymore, but Rpi still seems working internally - without network.
Made a new system with OLD 8.10 image, using SSH during first boot - all ok. After automatically updating to 8.14.2 and internal reboot → no ping, no SSH, no access.
Made a new system with NEW 8.14. image, NO ping and Wlan during first boot, nor the next

Any idea what the problem might be and how to avoid?

My configuration: RPi3B Bullseye with DietPi 8.14.2 booting from an external SSD, headless no HDMI, only access via WLAN (Mesh) 2.4 GHz German channels, DHCP, Router is gateway, additional DNS-server.
Applications: Iobroker with MQTT, InfluxDB

Your issue sounds different. Best would be to get a screen connected to check what happened and where your system stuck.

Thanks, but in my eyes no way to find this out afterwards.
I’ve got to setup a new 8.14.2 based system using LAN and doing the wlan configuration afterwards. This worked for me.

Many thanks to the community, I like dietpi

I have a similar issue.
Diept on a pi3B+, latest version, wifi only, no ethernet.
Docker, Zigbee2mqtt.
Connection drops off after a few hours and only option left is power toggle.
At times, just a ping command wakes it up so I have configured, just moments ago, UptimeKuma to ping and report every 60s.
Jury is on.

did you already activated dietpi-wifi-monitor service?

Thanks for such a prompt reply.

I saw elsewhere on the forums about this.

cat /etc/systemd/system/dietpi-wifi-monitor.service



It is there but I am too much of a noob to know how to enable it and ensure it is enabled after any/all reboots - please guide.
Thanks in advance.

Edit: Is it this?

systemctl enable dietpi-wifi-monitor.service
systemctl start dietpi-wifi-monitor.service
systemctl status dietpi-wifi-monitor.service
systemctl enable dietpi-wifi-monitor
systemctl start dietpi-wifi-monitor
1 Like