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)
roonbridge
Was the software title installed freshly or updated/migrated?
No
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
n/a
Steps to reproduce
Turn on raspberry pi
Wait for network connection and see Roon recognise the device
SSH to raspberry pi
Run htop
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.
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.
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.
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.
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
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
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.
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.