I use Audio Profiles - Easy switch between different audio settings Audio Profiles
Installation Steps
Saluti.
chewitt Done, did it, third time lucky, as this old sailor says.
I checked the true upstream master branch on Google Git and saw exactly where my branch had diverged. I also noticed that my webmail client mangled the formatting with automatic line wraps on the first attempt. I have rewritten the patch from scratch using the correct upstream context lines and split the long lines to prevent any word-wrap issues. I just submitted the clean [PATCH v2] directly to [email protected]. Appreciate the sharp eye ty for the help.
Doemela when interacting with mailing lists:
a) If you submit a patch as an additional comment within a bug report (as you have) it will be handled in patch tooling as a comment, and not as a patch. Instead submit the patch to the mailing-list as an actual patch; assume general kernel standards and etiquette for the patch submission. Keep the description brief/simple and use imperative (not conversational) tone. Note that AI generated patches are obvious and a human touch is generally appreciated by maintainers.
b) Once you submit a bug report and start a mail thread on the list always reply to the original message (even if this means replying to yourself) to keep everything in the same thread. If you send further information as 'new' messages these will not be linked in any of the list/review tooling that maintainers use.
c) Never top-post replies; always add information and content inline to the original post or append below the original. Again, this is to keep the information flow sequential in patch/review tooling.
Thanks for the reminder! It's been a while since I last used the mailing lists. I just resent the fix as a clean, standalone plain-text patch email.
DEVELOPMENT UPDATE: Structural Upstream Fix & Formal C-Code Patch (Beyond Mitigation)
Following up on the v1.5.3 addon service mitigations (the LimitNOFILE=512 circuit breaker), we have successfully moved beyond temporary containment. By auditing ConnMan’s active repository source layers, we have isolated the exact code path responsible for the Wi-Fi specific resource aggregation.
The Root Cause: Structural Bypass inside plugins/wifi.c
When an out-of-band virtual interface (like our WireGuard tunnel) drops, ConnMan's wireless event pathway triggers interface_removed(). If the parent device linkage has already been decoupled during the routing shift, the function hits an early conditional exit check:
if (wifi == NULL || wifi->device == NULL) {
DBG("wifi interface already removed");
return; /* 🛑 THE STRUCTURAL HOLE: Early return bypasses object lifecycle teardown! */
}
Because of this premature return, the mandatory GLib unreferencing routines (g_supplicant_interface_cancel and g_supplicant_interface_set_data) are completely bypassed. This leaves the low-level netlink and event tracking sockets running infinitely inside the OS handle table, causing the 72+ FD leaks we captured earlier.
Upstream Git Patch Submitted
I have submitted a formal patch to the core mailing list ([email protected]) to separate the hardware link check from the memory lifecycle teardown, ensuring cleanup runs unconditionally:
From: Doemela <[email protected]>
Subject: [PATCH] plugins/wifi: Fix GSupplicantInterface socket leak on out-of-band drop
Signed-off-by: Doemela <[email protected]>
---
diff --git a/plugins/wifi.c b/plugins/wifi.c
index 9ce7b5a..bcf8321 100644
--- a/plugins/wifi.c
+++ b/plugins/wifi.c
@@ -1014,14 +1014,16 @@ static void interface_removed(GSupplicantInterface *interface)
wifi = g_supplicant_interface_get_data(interface);
if (wifi != NULL && wifi->tethering == TRUE)
return;
- if (wifi == NULL || wifi->device == NULL) {
- DBG("wifi interface already removed");
- return;
- }
+ if (wifi != NULL && wifi->device != NULL) {
+ wifi->interface = NULL;
+ connman_device_set_powered(wifi->device, FALSE);
+ } else {
+ DBG("wifi device linkage missing, executing isolated interface cleanup");
+ }
- wifi->interface = NULL;
- connman_device_set_powered(wifi->device, FALSE);
+ g_supplicant_interface_set_data(interface, NULL);
+ g_supplicant_interface_cancel(interface);
}Compiling Safely Across Your Custom LibreELEC Tree Targets
For anyone building custom distribution images, you can drop this patch file straight into packages/network/connman/patches/connman-999-fix-wifi-fd-leak.patch and rebuild your exact appliance tree environment cleanly:
For PC / Intel / AMD (Generic x86_64 Target):
PROJECT=Generic ARCH=x86_64 ./scripts/clean connman
PROJECT=Generic ARCH=x86_64 ./scripts/build connmanFor Raspberry Pi 4 (32-bit ARM Target):
PROJECT=RPi ARCH=arm ./scripts/clean connman
PROJECT=RPi ARCH=arm ./scripts/build connmanFor Raspberry Pi 5 (64-bit AArch64 Target):
PROJECT=RPi ARCH=aarch64 ./scripts/clean connman
PROJECT=RPi ARCH=aarch64 ./scripts/build connmanThe addon's built-in sandbox remains active to protect normal users, but this patch resolves the core issue at the operating system level.
Salute!
UPDATE: Case-Sensitivity Fix & Hardened Service Sandbox (v1.5.3+ Breakthrough)
Following up on my previous live wireless debugging sessions, my team and I have successfully verified the exact interaction pattern and locked down a 100% zero-leak state under active runtime conditions.
During our final integration testing for the management addon, we isolated two critical regressions in the initial workaround parameters that other users/developers should be aware of:
1. ConnMan Configuration Case-Sensitivity
ConnMan's underlying GLib key-file parser is strictly case-sensitive. My previous configuration block utilized lowercase keys (e.g., onlinecheckmode). Because of this typographical mismatch, ConnMan completely ignored those lines and quietly fell back to its default background testing intervals, keeping the background tracking loops fully alive.
The configuration layout must use strict camelCase fields to be parsed correctly:
[General]
preferredtechnologies = ethernet,wifi,cellular
OnlineCheckMode = none
OnlineCheckIPv4URL =
OnlineCheckIPv6URL =
OnlineCheckInterval = 0
OnlineCheckURL =
Once corrected to uppercase camelCase, the journal log immediately confirms the tracking engine has successfully flattened out:
connmand[1859187]: Online check disabled; interface eth0 [ ethernet ] remains in ready state.2. Dropping LimitNOFILE from 4096 down to 512 (The Safe Sandbox Boundary)
Setting LimitNOFILE=4096 in the systemd override actually creates a dangerous race condition against the host environment. Because the Linux kernel's global default allocation maximum for an unprivileged process space defaults to 1024, setting systemd's ceiling to 4096 means a cascading Wi-Fi netlink handle leak will breach the kernel ceiling long before it hits the systemd limit. This results in the exact hard network lockup and dropped SSH terminal access we are trying to prevent.
By dropping the process sandbox boundary down to 512, systemd acts as a highly effective, native circuit breaker. If a user runs exclusively on Wi-Fi and cycles their VPN repeatedly, systemd will cleanly catch, terminate, and gracefully restart the daemon *before* it can exhaust the global OS resource table—keeping host routing tables 100% stable.
The corrected /storage/.config/system.d/connman.service.d/override.conf:
[Service]
ExecStart=
ExecStart=/usr/sbin/connmand -nr --config=/storage/.config/connman_main.conf --nodnsproxy
ExecStartPost=/bin/sh -c "sleep 2; if ! grep -q 'Method=manual' /storage/.cache/connman/*/settings 2>/dev/null; then echo -e 'nameserver 1.1.1.1\nnameserver 9.9.9.9' >> /etc/resolv.conf; fi"
LimitNOFILE=512
LogRateLimitIntervalSec=0Live Verification Results:
After forcing a systemctl daemon-reload and cycling our target WireGuard interface (vpn_91_90_123_2) 10 times consecutively over a live monitoring window, the process limit ceiling safely clamped and the file handle loops fully stabilized at an ultra-low, flat baseline:
Every 1.0s: echo -n 'VPN Daemon (connman-vpnd): '; ls -l /proc/$(pidof connman-vpnd)/fd 2>/dev/null | wc -l; echo -n 'Main Daemon (connmand): '; ls -l /proc/$(pidof connmand)/fd 2>/dev/null | wc -l
VPN Daemon (connman-vpnd): 10
Main Daemon (connmand): 19The structural leak is neutralized, execution tracking boundaries are safely held on LibreELEC, and process allocation profiles remain completely flatlined. These automatic configuration rewrites are fully integrated into our add-on upcoming release.
Salute!
chaosen3 Before I look into building support for this standalone dedicated auth path, I want to make sure I design the logic correctly for your specific setup. I actually already wrote some alpha code for it! However, to save myself the headache and grief of a massive backend rewrite, I want to double-check how you plan to use it.
Jumping into the full add-on service means my background loops—like the connection watchdog, update crons, and ConnMan deadlocks—will constantly try to rotate tokens and ping public server lists. For a dedicated IP, I will have to build a lot of special overrides to tell the service: 'Stop, do not touch this connection, it is static!'
To be completely transparent: this add-on was born out of my own personal needs. While I love open-source and sharing my work for free, my time is limited. I have my own job, bills to pay, and a life outside of coding. I am happy to help up to a certain point, but I cannot do massive, time-consuming backend overhauls for free.
Could you tell me a bit more about your exact goal?
Let me know your thoughts and what your setup looks like so we can see what is realistic!
Saluti.
Doemela I use the script from https://github.com/pia-foss/manual-connections to manually generate wireguard config files using my PIA dedicated token, is it a chore to build support for it into your add-on?
The integration of PIA into WireGuard VPN Manager is indeed based on that exact script https://github.com/pia-foss/manua…d_with_token.sh . In the add-on settings under 'VPN provider', you enter your username and password. The add-on after selecting countries/regions then automatically generates the WireGuard files in ~/.config/wireguard. https://github.com/BrodjagaRatnik…tings-Explained
Please note that it refreshes the standard session token only when it connects or updates in add-on. The update interval can be set in the hours settings. If you are not connected, it will refresh every hour (or whatever interval you choose). You can use it this way for now.
However, it does not officially support the 'PIA dedicated token' feature yet. In the meantime, I will look into adding a PIA authentication option specifically for dedicated tokens. I have looked into the script logic for the 'PIA dedicated token' and noticed it bypasses the standard user/password auth by using the token as a basic auth username. Since my add-on manages many other platform-specific tasks (like ConnMan routing and firewalls for LibreELEC), I will need to design a specific settings layout to let you input your dedicated IP, hostname, and token safely. I will look into adding this dedicated auth option in a future update!
Salute.
Yes, I used the Mullvads DNS servers from the blocklist, with beta.3 I set the unblocked and unfiltered DNS of Mullvad. https://github.com/BrodjagaRatnik….5.3~Beta.3.zip
Saluti.
Update: Wi-Fi Specific Leak Profile & Optimized Service Mitigation.
Through further targeted testing with my custom monitor scripts, I discovered that this tracking leak is entirely Wi-Fi specific. When cycling the VPN over a hardwired Ethernet connection, the file descriptor counts remain completely flat and stable (with Service Mitigation). However, the moment the system switches to a wireless interface, disconnecting the WireGuard tunnel causes an immediate, massive spike in connmand file descriptors. Here is the live capture of the anomaly during a wireless test cycle:
1. VPN Connected (Baseline Stable):
=== Network & VPN Status ===
WireGuard (wg): CONNECTED
=== ConnMan Daemon Resources ===
VPN Daemon (connman-vpnd): 10
Main Daemon (connmand): 192. Immediately After Disconnecting VPN (The Wi-Fi Leak Trigger):
=== Network & VPN Status ===
WireGuard (wg): DISCONNECTED
=== ConnMan Daemon Resources ===
VPN Daemon (connman-vpnd): 10
Main Daemon (connmand): 91 <-- Leaked 72 FDs after ~15 minutes on a single disconnect!It appears that when operating over Wi-Fi, ConnMan's underlying link/route scanning infrastructure fails to execute standard close() calls on its routing sockets when the virtual tunnel interface drops out-of-band. To prevent this aggressive accumulation from hitting the hard kernel wall of 1024 (which inevitably drops all system IP routes and kills SSH access), I have integrated a safe, proactive containment mechanism into my management addon.
By applying a custom systemd override template, we can restrict the process file allocation limits so the service safely self-reclaims without freezing the host system, while also ensuring aggressive logging loops don't choke the storage layer:
[Service]
ExecStart=
ExecStart=/usr/sbin/connmand -n --config=/storage/.config/connman_main.conf --nodnsproxy
LimitNOFILE=4096
LogRateLimitIntervalSec=0connman_main.conf:
[General]
onlinecheckmode = none
onlinecheckurl =
onlinecheckinterval = 0
onlinecheckipv4url =
onlinecheckipv6url =Hopefully, this extra data point regarding the wireless-specific behavior helps the upstream maintainers narrow down exactly which wireless state tracking hooks or netlink socket callbacks are missing their proper garbage collection routines.
Salute!
I had the same problem and made/added to my /storage/.config/autostart.sh at the top:
#!/bin/sh
ip link set dev wlan0 down
ip link set dev wlan0 address 00:11:22:33:44:55
ip link set dev wlan0 up
systemctl restart connmanMake the script executable, clean out the broken profiles and reboot:
chmod +x /storage/.config/autostart.sh
rm -rf /storage/.cache/connman/wifi_*
rebootThis fixed the asking for wifi password after every reboot.
You're awesome, I just install the 1.5.3 beta 2 and it worked perfect
Please note that this is a beta version. View the settings for this VPN provider in the add-on, then provide me with feedback. Run it for a couple of days, and if you encounter any problems, send me the log.
Saluti.
RapidRapunzel This wireguard config will do the trick:
[provider_wireguard]
Type = WireGuard
Name = Custom_Usa
Host = 23.234.116.3
WireGuard.Address = 10.70.70.181/32
WireGuard.ListenPort = 51820
WireGuard.MTU = 1420
WireGuard.PrivateKey = xxx
WireGuard.PublicKey = xxx
WireGuard.DNS = 100.64.0.63, 100.64.0.7
WireGuard.AllowedIPs = 0.0.0.0/0, ::/0
WireGuard.EndpointPort = 51820
WireGuard.PersistentKeepalive = 25I am busy integrating Mullvad into version 1.5.3. You can try out this beta version in the meantime. https://github.com/BrodjagaRatnik….5.3~Beta.2.zip
To post logs to this forum, copy and paste the following into SSH:
grep -i "service.wireguard.manager" /storage/.kodi/temp/kodi.log | pastebinitAnd post that URL here.
How to post a log (wiki)
1. Enable debugging in Settings>System Settings>Logging
2. Restart Kodi
3. Replicate the problem
4. Generate a log URL (do not post/upload logs to the forum)
use "Settings > LibreELEC > System > Paste system logs" or run "pastekodi" over SSH, then post the URL link
Salute.
Hi Doemela, I tested v1.5.2~rc.3 and quickly switched back to 1.5.2 because the VPN and network stopped working, if you'd like some logs, I could reinstall it and grab them, if that helps.
Best regard,
Brun0 So version 1.5.2 works for jou?
7/31
LE 13.0 Pi5 20260729 nightly v1.5.2~rc.3
https://paste.libreelec.tv/matter-pasty.log
Running smooth here. I see it shows an error but did not notice anything as user. Maybe a homotron.
That was former version so np:
2026-07-29 15:02:36.131 T:1059 error <general>: service.wireguard.manager v1.5.2~rc.1: Service Launcher: Verification loop aborted. Network target down.
Thanks.
Hello Brun0 ,
Because you are running on a non-Raspberry Pi wireless setup, your hardware requires slightly more time to cleanly tear down existing connection profiles when switching locations. Because the connection processing occasionally takes slightly longer than the hard-coded limits of the previous build, it caused a timeout crash. This left a stale .lock state file behind, which blocked your TV channels (PVR) and locked down your local routing parameters (disrupting SSH/Samba access).
Please install the updated script modules https://github.com/BrodjagaRatnik…-1.5.2~RC.3.zip and let me know if everything is running smoothly!
Best regards, Doemela.
Maybe try the latest version 1.5.2~rc
Reddirt You beat moi 
you can also test https://github.com/BrodjagaRatnik…-1.5.2~RC.3.zip specially on that I7.
v1.5.2 (2026-08-0?)
- Fixed: Resolved an exit status 22 argument error on Wi-Fi profile swaps.
- Fixed: Prevented system lockouts and file tracking freezes on slower hardware tiers.
- Optimized: Maintained local subnets and gateway paths to guarantee uninterrupted SSH/Samba access.
- Fixed: Resolved an exception routing conflict where upstream HTTP 429 server blocks returned empty token responses.
- Fixed: Resolved an issue causing the exception tree to misinterpret events and erroneously trigger the 401 alert window.
- Optimized: Implemented dynamic file state inspection within the token verification routine to accurately isolate locks.
- Optimized: Prioritized system rate-limiting locks over authentication validation screens during active profile swaps.
Salute.
Thank you so much for testing the beta build and sharing the logs!
I can see from the entries that the connection teardown and the dynamic DNS recycling are now working flawlessly. The stream links (pvr.iptvsimple) are resolving instantly and cleanly right after the tunnel closes without hitting any deadlocks.
The fix is officially successful! Thank you again for your time, and have a wonderful weekend as well!
I have built a specific test build to automate this fix directly inside the add-on logic. This will proactively catch and repair the ConnMan DNS deadlock on your system during execution.
You can download and install the update from here: service.wireguard.manager-1.5.1~beta.zip
What this update does:
Every time a VPN disconnection occurs, the manager now performs an internal DNS deadlock. If it detects that ConnMan has left your network in an unresolvable state (triggering the ifconfig.co error), it automatically triggers a fallback routine to flush the stale cache and force ConnMan to dynamically pull your local router's original DNS settings via DHCP. If a static IP is set, the script only clears the manual DNS block, causing ConnMan to immediately fall back to the manual DNS entered in LibreELEC, without affecting the static IP configuration.
Please install this beta build, test your add-on switching workflow, and let me know if your TV channels and the pastebinit log uploader function correctly without any manual terminal commands.
Salute.
