Hello Everyone - I’m running an up to date version of Volumio on a PI 5 and I have an ongoing wi-fi issue - Volumio refuses to remember or store my WiFi access code - I’ve had to run a lengthy ethernet cable to my Volumio player and this cant be left in place long term. Volumio seems my wifi, I enter my code and it connects but when I check the wi-fi settings moments later the access code box is blank/empty & the next time that I restart Volumio the code has been forgotten and the player wont connect - can you help?
Hey @Somerset,
Your post is missing information required for investigation.
All of the following are mandatory:
- Device model (Raspberry Pi 3/4/5, x86, etc.)
- Storage type (SD card, SSD, USB, eMMC)
- Raspberry Pi board revision (if applicable)
- Power supply (brand, connector type, wattage/amps)
- Exact Volumio version number (example: 3.569)
- Log link - visit http://volumio.local/dev, click Send, post the resulting URL in your reply
- Connected hardware (DAC, display, USB devices, GPIO attachments - all of it)
- Problem description: what happened, what you expected, steps to reproduce
Missing any item means no investigation. Reply with complete details.
Resource Link
------------------------------ -----------------------------------------------------
Help request guidelines https://community.volumio.com/t/tips-and-guidelines-to-get-faster-help/1440
Raspberry Pi identification https://community.volumio.com/t/guide-identifying-your-raspberry-pi-board-on-volumio-a-comprehensive-guide-to-revision-codes/71350
Log retrieval instructions https://help.volumio.com/help/how-to-send-a-log-link-for-a-bug-report
Kind Regards,
Hello - please see below - I was able to connect to my wi-fi until I shut Volumio down, after booting up the wi-fi stopped working:
| Device model (Raspberry Pi 3/4/5, x86, etc.) | PI 5 (8GB) |
|---|---|
| Storage type (SD card, SSD, USB, eMMC) | Misco SD card (music on Samsung NVME viaPCIE) |
| Raspberry Pi board revision (if applicable) | |
| Power supply (brand, connector type, wattage/amps) | IFI Elite 5V, 5A |
| Exact Volumio version number (example: 3.569) | 4.119 - Released March 2026 |
| Log Link - sucessful wi-fi connection | http://logs.volumio.org/volumio/Lwk81mO.html |
| Log Link - unsucessful wi-fi connection | http://logs.volumio.org/volumio/4MFVhoT.html |
| Connected hardware (DAC, display, USB devices, GPIO attachments - all of it) | Teradak Digital Out HAT, LHY power filter sat between PI 5 & Teradak |
| Problem description: what happened, what you expected, steps to reproduce | Attempts to connect to my wi-fi network are always rejected, to either 2.4Ghz or 5Ghz if the device has been restarted |
Seems your power source is not adequate to power everything. Your log (2nd) holds low voltage warnings. please correct this first. Your working log (1st) doesn’t have these errors.
Apr 06 22:30:01 volumio kernel: hwmon hwmon3: Undervoltage detected!
Apr 06 22:30:03 volumio kernel: hwmon hwmon3: Voltage normalised
Hey @Somerset,
Thanks for the complete details and both logs. I want to separate what the logs actually show from what the symptom looks like from the UI, because they are not the same thing.
On op what @Wheaten has already flagged out:
First, on the stored password. Volumio does save your wifi credentials. It deliberately does not display a saved password back in the UI once stored - that is a security measure, not a bug, and an empty password box in settings after a successful connection is expected. So “the box is blank next time I look” is not evidence that the credential was lost. With that out of the way, the logs show something else is going on.
You have two wifi radios active on this Pi 5:
- wlan0: a TP-Link Archer T2U Nano USB dongle (Realtek RTL8811AU, driver rtw88_8821au, USB ID 2357:011e)
- wlan1: the Pi 5 internal Broadcom radio (brcmfmac, BCM4345/6)
Volumio only manages wlan0, and the USB dongle has taken that slot. The internal Pi 5 radio is sitting unused. I need to flag this because it matters for what follows.
What the failing log (4MFVhoT) actually shows at 22:06:07 to 22:07:00:
- wpa_supplicant authenticates with your AP (C-NET v5 2.4)
- wpa_supplicant associates
- WPA 4-way handshake completes: “Key negotiation completed with d8:44:89:52:cf:14 [PTK=CCMP GTK=CCMP]”
- wpa_supplicant logs CTRL-EVENT-CONNECTED
At that point the supplicant-level connection is fully established. The credential is correct. The handshake worked. So the problem is not the password and not the authentication.
What then fails is the next step. dhcpcd needs the network interface to report link carrier up before it can request a DHCP lease. In the working log (Lwk81mO) dhcpcd logs “wlan0: carrier acquired” immediately after authentication and then gets a lease normally. In the failing log, dhcpcd never logs “wlan0: carrier acquired” at all. Instead it sits in a tight loop for 38 seconds:
wlan0: connected to Access Point: C-NET v5 2.4
wlan0: adding address fe80::…
ipv6_addaddr1: Permission denied
wlan0: removing interface
wlan0: waiting for carrier
(repeat)
That same “Permission denied” line appears 11,336 times in the failing log and only 2 times in the working log. After 38 seconds wireless.js times out with “Overtime, connection failed”, the kernel then deauthenticates wlan0 “by local choice”, and Volumio drops to its hotspot fallback. From the UI that looks exactly like “it forgot my wifi” - but what actually happened is that the driver never raised carrier after a successful handshake, so DHCP never ran, so Volumio gave up and started the hotspot.
My current hypothesis - and I am calling it a hypothesis, not a conclusion - is that the rtw88_8821au driver on the Archer T2U Nano is completing association at the supplicant level but not asserting link carrier to the kernel on this particular boot. The Archer T2U Nano has a long history of intermittent behaviour on Linux across kernel versions. I cannot prove that is the cause from logs alone, so I need you to help isolate it.
What I need you to do next, in this order:
-
Confirm the TP-Link Archer T2U Nano is something you deliberately added. If you did not know it was there, tell me where it is plugged in.
-
Power the Pi down. Physically unplug the Archer T2U Nano. Leave the ethernet cable disconnected. Power the Pi up with only the internal Pi 5 wifi available. Attempt to connect to C-NET v5 2.4 from the UI. Whether it works or fails, grab a fresh log link from http://volumio.local/dev and post it here. This takes the USB dongle and its driver completely out of the picture and tells us whether the internal Pi 5 radio behaves the same way.
-
If step 2 works cleanly across a reboot, the Archer T2U Nano is the problem and the fix is either stop using it or move it to a different port. If step 2 fails the same way, the problem is elsewhere and I will work from the new log.
Please do not plug the ethernet back in during step 2. I need a clean wifi-only boot to read.
Kind Regards,
Thank-you for taking the time to review the log and promptly write a detailed reply.
I added the TP-Link USB dongle for two simple reasons, my PI-Fi is mounted in an old, metal-bodied Technics tuner & I was concerned that the metal enclosure would shield the PIs built in wi-fi. I used a TP link device simply because I have a TP Link router – I also tried an Netgear dongle and the same problem occurred.
Using the PIs wifi has fixed this issue but I would still like to use an external wi-fi dongle so that when my Pi player is located some distance from my router a reliable wi-fi connection is maintained – what is the best way to improve upon the built-in wi-fi module?
Thank-you again for your assistance
Thanks - the IFI PSU is rated at 5A - hopefully the reported issue was a connection issue rather than the need to use a more powerful PSU.
Raspberry Pi 4 - 4 GB - Khadas Tone1 - Ubiquiti USB-C 5V 5A 25W power supply (new power supply from Ubiquiti Flex XG router). Volumio 4.119.
Over the weekend and today, I experienced a problem – the Raspberry Pi was unable to connect to the router via Wi-Fi.
The Raspberry Pi wouldn’t connect to the 5 GHz network. The password was missing.
After re-entering the network password, it connected.
Here is the latest log, earlier the PI 5 did connect to my wi-fi using the built-in wi-fi module, and now it refuses point blank to connect to anything, I enabled guest access on my router and removed the need for a password, Volumio would not connect, I enabled a hotspot on my phone, Volumio would not connect to that either: http://logs.volumio.org/volumio/ivfdF51.html
For context - I have a second PI 5, running the PI OS and it works perfectly using any of the three TP Link dongles and also the Netgear dongle.
My wi-fi is now working - but at the expense of my DAC - I dont know if this is worth the effort anymore:
http://logs.volumio.org/volumio/4M8qAA5.html
Hey @Somerset,
Two logs, two very different pictures. Let me take them in order.
ivfdF51 is not usable for the claim you made with it. Across the entire captured window (Apr 7 10:45 to 12:08) your ethernet cable is plugged in and has a lease on 192.168.1.100. Volumio’s Single Network Mode is correctly preferring ethernet and is holding wlan0 UP for scanning only, without ever attempting to associate. There is not a single wpa_supplicant authentication attempt in this log. Nothing tried to connect, so nothing could fail. If you want me to look at a “refuses to connect to anything” scenario, I need a log from a boot where ethernet is physically unplugged and you actually attempt to connect from the UI. Otherwise the log captures Volumio behaving exactly as designed: ethernet is up, wifi is held in scan mode.
4M8qAA5 is the interesting one, and it is good news for the wifi and bad news elsewhere.
On the wifi, at 20:07:12:
- wpa_supplicant associates with C-NET v5 2.4
- WPA key negotiation completes
- CTRL-EVENT-CONNECTED fires
- dhcpcd immediately logs “wlan0: carrier acquired”
- DHCP lease 192.168.1.105 is obtained normally
That is the internal Pi 5 radio behaving the way it is supposed to. No runaway loop, no permission-denied cascade, no carrier starvation, no hotspot fallback. Compare this with the earlier failing log where the Archer T2U Nano was in wlan0: wpa_supplicant completed the handshake, but the rtw88_8821au driver never raised link carrier, so dhcpcd could not solicit a lease. That was a driver-level carrier bug specific to the USB dongle, not a Pi problem, not a power problem, and not RF interference. With the dongle out of the system, the internal radio connects cleanly. The Pi 5 wifi is fine.
The DAC issue in 4M8qAA5, however, is self-inflicted. Something has changed between the two logs:
- In the earlier working log, aplay -l reported “card 2: sndrpihifiberry [snd_rpi_hifiberry_digi], device 0: HifiBerry Digi HiFi wm8804-spdif-0” and /boot/config.txt contained “dtoverlay=hifiberry-digi”.
- In 4M8qAA5, aplay -l reports only card 0 (vc4hdmi0) and card 1 (vc4hdmi1). There is no sndrpihifiberry card at all. And /boot/config.txt now contains “dtoverlay=hifiberry-digi-pro” in the Volumio-managed section at the bottom.
You have changed the I2S DAC selection in the Volumio UI from “HifiBerry Digi” to “HifiBerry Digi Pro”. That writes a different overlay, and the Pro overlay uses a different hardware binding that does not match your Teradak Digital Out HAT. The kernel loads the overlay but no ALSA card is created because the hardware does not answer to it. mpd then fails with “Failed to open ALSA device ‘volumio’: No such device” because the card name it is pointing to does not exist. None of that is caused by the wifi work. The Teradak was being driven as a HifiBerry Digi from day one and needs to stay that way.
To recover the DAC, go to Settings, Playback Options, I2S DAC, and change the selection from “HifiBerry Digi Pro” back to “HifiBerry Digi”, then reboot. aplay -l should then show card 2 as sndrpihifiberry again and mpd will open the device normally.
One side observation: your /boot/userconfig.txt in 4M8qAA5 now contains “dtparam=i2c_arm_baudrate=800000” and “dtparam=spi=on”. These were not in the earlier log. They are not causing the current DAC problem, but unless you added them for a specific reason you know about, I would remove them. Neither is needed for a Teradak Digital Out HAT.
On USB RF interference as a framing: your case is not that. The dongle failure in the first log was a carrier-assertion bug in the rtw88_8821au driver, not radiated noise. The internal radio proves it: same Pi, same AP, same room, same PSU, same everything except no USB dongle, and wifi works in under a second.
Summary of where you are:
- Wifi: part-solved by removing the Archer T2U Nano. This should work, unless firmware is being silently rejected.
- DAC: set the I2S DAC selection back to HifiBerry Digi and reboot.
- userconfig.txt: consider removing the two dtparam lines unless you added them deliberately.
- Second Pi 5 on Pi OS working with the dongles: Pi OS uses a different kernel, different driver stack, different wpa_supplicant version, different networking manager. Cross-OS behaviour is not transferable evidence.
Kind Regards,