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

Doemela · July 20, 2026 at 1:25 AM

I have isolated a severe file descriptor resource leak in ConnMan (connmand) that affects both LibreELEC 12 (RPi4/RPi5) and LibreELEC 13 (Generic/x86_64). When an addon or binary initializes an unmanaged, kernel-space WireGuard tunnel (wg0) directly via kernel interfaces, ConnMan's rtnl (Route Netlink) subsystem monitors the link changes but fails to release its internal tracking sockets. The file descriptors tick up steadily at about 5 FDs every 2 minutes until they hit the Linux operating system kernel ceiling of 1024 total FDs.

Once it reaches 1025 FDs, ConnMan throws a Too many open files error and crashes completely. Because LibreELEC depends entirely on ConnMan for networking, this crash drops all system IP routes, instantly dropping active SSH sessions and killing local network connectivity until a hard physical power cycle is performed. Conman Problem

Steps to Reproduce

Manually initialize or cycle a standard kernel-space WireGuard interface (wg0) outside of ConnMan's limited D-Bus infrastructure.
Track the file descriptor handle counts of the daemon over SSH:

Shell session

watch -n 1 "ls -l /proc/\$(pidof connmand)/fd | wc -l"

Watch the baseline count steadily climb past 500, hitting the 1025 wall within 2–3 hours, resulting in a total network drop.

LibreELEC 12.2.1 (Pi5 system hitting the 1024 ceiling and dropping connection):

Code

2026-07-19 17:56:00.000 info <general>: service.connman.monitor v1.0.0: Connman profile -> Sockets: 1015 | Total FDs: 1025 | VPND FDs: 10
2026-07-19 17:57:00.000 info <general>: service.connman.monitor v1.0.0: Connman profile -> Sockets: 1015 | Total FDs: 1025 | VPND FDs: 10
client_loop: send disconnect: Connection reset
ssh: connect to host 192.168.178.45 port 22: Connection timed out

LibreELEC 13 (Generic Test confirming the exact same leak profile remains active upstream):

Code

2026-07-20 01:56:14.938 T:1313 info <general>: service.wireguard.manager v1.5.0~beta: Wm Utils: Connman socket leak detected (514/526 FDs). VPN is disconnected. Executing safe background network reclamation...

System Details:

LibreELEC Versions Tested: 12.2.1 / LibreELEC-Generic.x86_64-13.0-nightly-20260719-3d3de99
Hardware Tested: Raspberry Pi 4, Raspberry Pi 5, Generic x86_64.
Workaround: I have had to write an addon script that intercepts the leak when the VPN is disconnected and safely calls an atomic background systemctl restart connman script loop to prevent hard crashes.

Has anyone else encountered this socket aggregation issue with custom virtual interfaces, or is there an upstream ConnMan patch planned to improve netlink garbage collection?

Bash

#!/bin/sh
<<'COMMENT'

chmod +x /storage/.config/scripts/service.connman.monitor.sh
crontab -e
* * * * * /storage/.config/scripts/service.connman.monitor.sh
tail -f /storage/.kodi/temp/kodi.log | grep -iE "service.connman.monitor"

COMMENT
LOG_FILE="/storage/.kodi/temp/kodi.log"
TAG="service.connman.monitor"
VERSION="v1.0.0"
PID_CONNMAN=$(pidof connmand)
PID_VPND=$(pidof connman-vpnd)

if [ -z "$PID_CONNMAN" ]; then
    TIMESTAMP=$(date "+%Y-%m-%d %H:%M:%S.000")
    echo "${TIMESTAMP} error <general>: ${TAG} ${VERSION}: Internal exception during connmand socket monitoring: connmand is not running!" >> "$LOG_FILE"
    exit 1
fi

FD_TOTAL=$(ls -l /proc/"$PID_CONNMAN"/fd 2>/dev/null | wc -l)
FD_SOCKETS=$(ls -l /proc/"$PID_CONNMAN"/fd 2>/dev/null | grep -c "socket:")

if [ -n "$PID_VPND" ]; then
    FD_VPND=$(ls -l /proc/"$PID_VPND"/fd 2>/dev/null | wc -l)
else
    FD_VPND="0"
fi

TIMESTAMP=$(date "+%Y-%m-%d %H:%M:%S.000")

echo "${TIMESTAMP} info <general>: ${TAG} ${VERSION}: Connman profile -> Sockets: ${FD_SOCKETS} | Total FDs: ${FD_TOTAL} | VPND FDs: ${FD_VPND}" >> "$LOG_FILE"

Display More

Code

2026-07-19 23:41:20.626 T:213859    info <general>: service.wireguard.manager v1.5.0~beta: Service Launcher: Hardware timings loaded for Raspberry Pi 5
2026-07-19 23:41:20.632 T:213859    info <general>: service.wireguard.manager v1.5.0~beta: Service Launcher: Monitor Service Initialized & Ready
2026-07-20 01:46:06.397 T:213859    info <general>: service.wireguard.manager v1.5.0~beta: Wm Utils: Connman socket leak detected (502/514 FDs). VPN disconnected. Executing safe background network reclamation...

https://paste.libreelec.tv/olivary-leonard.log

Code

2026-07-20 02:06:56.078 T:756983    info <general>: service.wireguard.manager v1.5.0~beta: Service Launcher: Hardware timings loaded for Raspberry Pi 4
2026-07-20 02:06:56.090 T:756983    info <general>: service.wireguard.manager v1.5.0~beta: Service Launcher: Monitor Service Initialized & Ready

https://paste.libreelec.tv/mistiest-yung.log

LibreELEC-Generic-13

https://paste.libreelec.tv/englacial-brynlee.log

https://paste.libreelec.tv/antiempirical-samuel.log

**chewitt** · July 20, 2026 at 4:54 AM

I don't see any submitted patches to address this topic: https://patchwork.kernel.org/project/connman/list/ so I would assume it has not been reported. So you need to report findings to ConnMan developers via their mailing list: [email protected]

Doemela · July 20, 2026 at 9:41 AM

Thank you for checking the patch history. I have followed your advice and officially submitted a detailed bug report upstream to the ConnMan developers mailing list. For anyone else running into this freeze or loop while using WireGuard configurations, here is a summary of what I have discovered and how I have managed to mitigate the issue in the meantime:

When an out-of-band WireGuard interface changes the system routing table, ConnMan's internal DNS proxy subsystem gets caught in a loop. It repeatedly spawns client sockets targeting the gateway (port 53), but fails to run a close() system call on them. These orphaned file descriptors accumulate rapidly until they hit the Linux process limit of 1024. Once hit, all network resolutions fail and the system freezes. On LibreELEC 13 (Generic), the socket leak is completely tied to the DNS proxy loop. On LibreELEC 12.2.1 (Pi4, PI5), an older tracking bug remains active alongside the DNS loop, trickling in an additional 2 unclosed anonymous sockets per minute during active VPN cycles.

Bypassed ConnMan's broken DNS proxy layer by applying a custom systemd runtime override flag. This forces the OS to handle DNS calls natively without letting ConnMan drop handles. If your system is freezing due to this leak, you can apply this workaround via SSH:

Bash

mkdir -p /storage/.config/system.d/connman.service.d
cat << 'EOF' > /storage/.config/system.d/connman.service.d/override.conf
[Service]
ExecStart=
ExecStart=/usr/sbin/connmand -nr --config=/storage/.config/connman_main.conf --nodnsproxy
EOF
systemctl daemon-reload
systemctl restart connman

On LE 13 the file descriptor count stays completely flat and stable (locked around 30 FDs), entirely fixing the crash. On LE 12 the massive socket storm is blocked, slowing the leak down drastically to just 2 FDs per minute, giving the machine significantly longer uptime before needing a network service restart. Hopefully, the upstream developers can pinpoint exactly where the missing close() descriptors are in the rtnl or proxy source arrays.

Salute.

**Da Flex** · July 20, 2026 at 10:41 AM

Some RPi users have reported that they had to restart the device once a day to use it 24/7. Maybe you found the cause.

Doemela · July 20, 2026 at 1:12 PM

Think we haxored it Following up on my previous report regarding the severe file descriptor leak in connmand when using WireGuard (wg0) tunnels, my team and testers have successfully isolated the root causes and implemented a elegant solution, zero-leak workaround. It turns out there were two separate upstream tracking bugs inside ConnMan's older network cache layer that trigger when an out-of-band virtual interface alters default routing metrics.

ConnMan's internal DNS proxy layer loops indefinitely trying to process client sockets during interface state changes, leaking 10 FDs every minute.
ConnMan constantly polls ipv4.connman.net to verify global internet status. When WireGuard routes shift mid-flight, these TCP connections get permanently orphaned in a CLOSE_WAIT state, trickling in an additional 2–3 leaks per minute on older environments (like LibreELEC 12).

By completely disabling ConnMan's internal DNS proxy and turning off its aggressive global connectivity tracking, the daemon relies on native Linux routing. This drops the file descriptor load down to baseline and completely flatlines the leak. Here is the exact setup we deployed via SSH to fix the issue:

Open or create /storage/.config/connman_main.conf and ensure the online check is completely disabled:

Code

[General]
EnableOnlineCheck = false

To apply your changes and restart ConnMan via SSH, use this command:

Shell session

systemctl daemon-reload && systemctl restart connman

Create the service drop-in override directory and force ConnMan to start with the --nodnsproxy flag active:

Shell session

mkdir -p /storage/.config/system.d/connman.service.d
cat << 'EOF' > /storage/.config/system.d/connman.service.d/override.conf
[Service]
ExecStart=
ExecStart=/usr/sbin/connmand -nr --config=/storage/.config/connman_main.conf --nodnsproxy
EOF

Reload and Apply in ssh:

Shell session

systemctl daemon-reload
systemctl restart connman

Verification:

Shell session

watch -n 1 "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"

LibreELEC 13 (Generic): File descriptors stay perfectly locked and flat at 30 FDs. LibreELEC 12 (Pi4 / Pi5): File descriptors stay perfectly locked and flat at 22 FDs without a single trickle over time. The system is now completely stable. I have forwarded these exact details to the ConnMan upstream developer mailing list ([email protected]) so they can investigate adding proper close() descriptors inside the rtnl or proxy source arrays for future releases.

Salute.