Posts by Doemela

  • [RPi] ConnMan resource socket leak (1024 FD crash) when using kernel-space WireGuard (wg0)

    To help other community members check if their systems are suffering from this ConnMan file descriptor leak, I have written a diagnostic script. Connect via SSH and create the script:

    Shell session
    mkdir -p /storage/.config/scripts
nano /storage/.config/scripts/connman-leak-test.sh

    Paste the following code inside the file:

    Save and exit (Ctrl+O, Enter, Ctrl+X), then give it execution permissions and run it:

    Shell session
    chmod +x /storage/.config/scripts/connman-leak-test.sh
/storage/.config/scripts/connman-leak-test.sh

    If you let it run full course or interrupt it, it will provide a direct paste link showing if your system is experiencing un-canceled socket tracking build-ups.

  • [RPi] ConnMan resource socket leak (1024 FD crash) when using kernel-space WireGuard (wg0)

    Quote from chewitt

    To the original question: I'd prefer to see the patch merged and package bumped than place 'known bug' info in the wiki.

    I completely understand your point regarding LE13+ and preferring a package bump once the patch is merged upstream.

    However, my main concern is for users on LE11 and LE12. Since those legacy versions are in maintenance mode and likely won't receive a core ConnMan package update, they will continue to hit this 1024 fd crash. To give you a real-world example of why this is urgent for legacy LE11/LE12: in a standard dual-setup where Ethernet is active and Wi-Fi is left floating on 'idle' or 'ready', ConnMan triggers this background scan-loop constantly. The file descriptors stack up in record time without even touching VPNs/WireGuard. It affects anyone running hybrid wired/wireless setups from day one.

    How would you prefer we handle this for legacy releases? Would it be acceptable to post a brief workaround/troubleshooting note in the forum for them (e.g., using a systemd/cron timer to periodically flush ConnMan before it hits the 1024 fd limit)?

    On a side note, I just submitted [PATCH v6] upstream to the ConnMan mailing list. I believe I have now cleaned up all the formatting issues and the stray line-deletes to meet the strict Linux ecosystem style guidelines—or at least I hope so, but you would know better than me!

  • [RPi5] priorize/switch audio devices

    Quote from userx404

    Thank you for your suggestion
    I tried the addon but am not shure how to use it and how to switch. If i click on the addon in the overview, i see my 2 created profiles in a selection menu. When i select one, the actual settings get saved to this profile. But i want to switch this profile.

    You can switch between profiles using key map see https://kodi.wiki/view/Add-on:Audio_Profiles https://forum.kodi.tv/showthread.php?tid=353852

  • allow changing DNS when using DHCP

    The only solution I can think of to bypass DHCP is a small background script to bypass it. Create a file named autostart.sh for your sister and send it to her. Here is the exact code needed. Copy this block of text:

    Instructions for your Sister. To install this script, you will need a computer connected to the same home network as the LibreELEC device.

    • Open File Explorer on your computer.
    • In the address bar at the very top, type your LibreELEC network path and press Enter:
      \\YOUR_LIBREELEC_IP_ADDRESS\ (Example: \\192.168.1.15\)
    • Open the Configfiles folder.
    • If you cannot see it, enable "Hidden items" in the View settings of Windows.
    • Copy autostart.sh to that Config folder.
    • Restart LibreELEC.

  • allow changing DNS when using DHCP

    Quote from olze

    this "we must block manual dns overwrites because we can" mentality.

    You got it totally wrong it is not LE that sets DHCP on or off all ISPs or self bought modems/routers have DHCP as default ON it is up to the user to set that in modem/router off/on. LE has nothing to do with that if you do not want to use it set it off in modem/router and modify /etc/resolv.conf

  • [RPi] ConnMan resource socket leak (1024 FD crash) when using kernel-space WireGuard (wg0)

    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.

  • [RPi] ConnMan resource socket leak (1024 FD crash) when using kernel-space WireGuard (wg0)

    Quote from chewitt

    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.

  • [RPi] ConnMan resource socket leak (1024 FD crash) when using kernel-space WireGuard (wg0)

    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:

    Code
    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:

    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):

    Code
    PROJECT=Generic ARCH=x86_64 ./scripts/clean connman
PROJECT=Generic ARCH=x86_64 ./scripts/build connman

    For Raspberry Pi 4 (32-bit ARM Target):

    Code
    PROJECT=RPi ARCH=arm ./scripts/clean connman
PROJECT=RPi ARCH=arm ./scripts/build connman

    For Raspberry Pi 5 (64-bit AArch64 Target):

    Code
    PROJECT=RPi ARCH=aarch64 ./scripts/clean connman
PROJECT=RPi ARCH=aarch64 ./scripts/build connman

    The addon's built-in sandbox remains active to protect normal users, but this patch resolves the core issue at the operating system level.

    Salute!

  • [RPi] ConnMan resource socket leak (1024 FD crash) when using kernel-space WireGuard (wg0)

    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:

    Code
    [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:

    Code
    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:

    Code
    [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=0

    Live 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:

    Code
    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):    19

    The 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.

    Upstream ConnMan FD Leak & Automated Mitigation Guide
    Multi-Provider WireGuard VPN Manager for LibreELEC (NordVPN, PIA, Mullvad, Proton, Custom) - BrodjagaRatnik/service.wireguard.manager
    github.com

    Salute!

  • WireGuard VPN Manager

    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?

    1. Full Integration: Do you want the add-on to fully manage the dedicated connection on the background (handling ConnMan routing, automatic firewall rules, and keeping the tunnel alive)?
    2. Standalone WireGuard Config Generator Manager: Alternatively, I could pull the core connection, disconnection, killswitch, and system watchdog service logic from this manager and tie it together into a brand new, standalone add-on tailored specifically for custom/dedicated WireGuard tokens. This keeps this main project clean, saves me a massive rewrite headache, and gives you a fully functional, lightweight service for your dedicated connection.
    3. Config Generator Only: Or do you just want a quick utility built into the UI to generate the WireGuard configuration files using your token, so you can run them via your own custom scripts or system paths?

    Let me know your thoughts and what your setup looks like so we can see what is realistic!

    Saluti.

  • WireGuard VPN Manager

    Quote from chaosen3

    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.

  • [RPi] ConnMan resource socket leak (1024 FD crash) when using kernel-space WireGuard (wg0)

    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):

    Code
    === Network & VPN Status ===
WireGuard (wg): CONNECTED
=== ConnMan Daemon Resources ===
VPN Daemon (connman-vpnd): 10
Main Daemon (connmand):    19

    2. Immediately After Disconnecting VPN (The Wi-Fi Leak Trigger):

    Code
    === 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:

    Code
    [Service]
ExecStart=
ExecStart=/usr/sbin/connmand -n --config=/storage/.config/connman_main.conf --nodnsproxy
LimitNOFILE=4096
LogRateLimitIntervalSec=0

    connman_main.conf:

    Code
    [General]
onlinecheckmode = none
onlinecheckurl = 
onlinecheckinterval = 0
onlinecheckipv4url = 
onlinecheckipv6url =
    • --nodnsproxy: Completely bypasses ConnMan's corrupted DNS loop architecture.
    • LimitNOFILE=4096: Explicitly raises the system descriptor ceiling from the default 1024 up to 4096. This provides a massive resource cushion to absorb slow, creeping wireless handle transitions, keeping the core operating system and active SSH terminal sessions completely stable for long-term use.
    • LogRateLimitIntervalSec=0: Prevents systemd from locking out or throttling ConnMan diagnostic events during a rapid interface or connection shift.
    • OnlineCheckMode=none: Completely disables ConnMan’s periodic internet accessibility probing subsystem, which prevents background testing loops when network gateways drop routing tables.
    • OnlineCheckIPv4URL= & OnlineCheckIPv6URL=: Clears the default target endpoints. This blocks ConnMan from attempting out-of-band WPAD/PAC proxy lookups, resolving infinite retry loops triggered by routers like the Fritz!Box.
    • OnlineCheckInterval=0: Sets the validation retry timer to zero, completely turning off background testing intervals.

    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!