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

**Da Flex** · August 30, 2026 at 3:55 PM

Good luck!

Doemela · August 30, 2026 at 7:15 PM

Quote from Da Flex

Good luck!

[v6] plugins/wifi: Fix GSupplicantInterface socket leak during teardown - Patchwork

Doemela · August 30, 2026 at 8:11 PM

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:

Bash

#!/bin/sh
# chmod +x /storage/.config/scripts/connman-leak-test.sh
# /storage/.config/scripts/connman-leak-test.sh

OUTDIR=/storage/.cache/connman-diagnostics-$(date +%Y%m%dT%H%M%S)
mkdir -p "$OUTDIR"
PASTE_LOG="$OUTDIR/connman-leak-test.txt"

trap 'echo -e "\n[$(date +%H:%M:%S)] Execution interrupted by user! Jumping to final metrics collection..."; break' INT

echo "=== CONNMAN DIAGNOSTICS (PASSIVE MONITOR) ===" > "$PASTE_LOG"
echo "OS: $(cat /etc/os-release | grep PRETTY_NAME | cut -d'"' -f2)" >> "$PASTE_LOG"
echo "Kernel: $(uname -r)" >> "$PASTE_LOG"
if [ -f /proc/device-tree/model ]; then
  echo "Hardware Model: $(cat /proc/device-tree/model)" >> "$PASTE_LOG"
fi
echo "----------------------------------------" >> "$PASTE_LOG"

pid=$(pidof connmand)
echo "Connmand PID: $pid" >> "$PASTE_LOG"

echo "[$(date +%H:%M:%S)] Toggling Kodi component debug logging ON..."
kodi-send --action="SetLogLevel(2)" >/dev/null 2>&1 || true

echo "[$(date +%H:%M:%S)] Collecting FIRST snapshot (T=0)..."
echo "=== SNAPSHOT 1: START ===" >> "$PASTE_LOG"
echo "Timestamp: $(date)" >> "$PASTE_LOG"
if [ -n "$pid" ]; then
  echo "FD count: $(ls -l /proc/$pid/fd 2>/dev/null | wc -l)" >> "$PASTE_LOG"
  echo "Active FD targets (Top 20):" >> "$PASTE_LOG"
  (for f in /proc/$pid/fd/*; do readlink -f "$f" 2>/dev/null || readlink "$f" 2>/dev/null; done ) | sort | uniq -c | sort -nr | head -n 20 >> "$PASTE_LOG" 2>&1 || true
fi
echo "----------------------------------------" >> "$PASTE_LOG"

echo "[$(date +%H:%M:%S)] Sleeping for 30 minutes to let the leak accumulate..."
echo "Press Ctrl+C at any time to skip the wait and generate the log immediately."

for i in $(seq 1 1800); do
  sleep 1
done

trap - INT

echo "[$(date +%H:%M:%S)] Collecting SECOND snapshot (T=+30 min)..."
echo -e "\n=== SNAPSHOT 2: AFTER 30 MIN ===" >> "$PASTE_LOG"
echo "Timestamp: $(date)" >> "$PASTE_LOG"
if [ -n "$pid" ]; then
  echo "FD count: $(ls -l /proc/$pid/fd 2>/dev/null | wc -l)" >> "$PASTE_LOG"
  echo "Active FD targets (Top 20):" >> "$PASTE_LOG"
  (for f in /proc/$pid/fd/*; do readlink -f "$f" 2>/dev/null || readlink "$f" 2>/dev/null; done ) | sort | uniq -c | sort -nr | head -n 20 >> "$PASTE_LOG" 2>&1 || true
  
  if [ -r /proc/net/netlink ]; then
    echo -e "\n=== /proc/net/netlink ===" >> "$PASTE_LOG"
    cat /proc/net/netlink >> "$PASTE_LOG"
  fi
fi

echo -e "\n=== RECENT KODI LOG ENTRIES FOR ADDON ===" >> "$PASTE_LOG"
if [ -f /storage/.kodi/temp/kodi.log ]; then
  grep -Ei "connman|wireguard" /storage/.kodi/temp/kodi.log | tail -n 150 >> "$PASTE_LOG" 2>&1 || true
fi

echo -e "\n=== RECENT SYSTEM JOURNAL LOGS FOR CONNMAN ===" >> "$PASTE_LOG"
journalctl -u connman.service -n 150 --no-pager >> "$PASTE_LOG" 2>&1 || true

echo "[$(date +%H:%M:%S)] Toggling Kodi component debug logging OFF..."
kodi-send --action="SetLogLevel(0)" >/dev/null 2>&1 || true

echo "----------------------------------------"
echo "Uploading results..."

PASTE_URL=""
if command -v paste >/dev/null 2>&1; then
  PASTE_URL=$(paste "$PASTE_LOG" 2>/dev/null)
fi

if [ -z "$PASTE_URL" ]; then
  echo "Deploying curl fallback to ix.io..."
  PASTE_URL=$(curl -s -F "f:1=@$PASTE_LOG" ix.io)
fi

if [ -n "$PASTE_URL" ]; then
  echo "----------------------------------------"
  echo "Your diagnostic paste link is:"
  echo "$PASTE_URL"
  echo "----------------------------------------"
else
  echo "Upload failed. Log preserved locally at: $PASTE_LOG"
fi

Display More

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.

**chewitt** · August 31, 2026 at 1:46 AM

The patch looks structurally okay to me now, but I can't speak for the code. Denis and Marcel seem to be less active at the moment and I'm not sure if they are still working at Intel or were laid off, which might slow things up (not that ConnMan has been quick in recent years). If there is no comment in a week you might need to reply to your own email submission with a brief apology for the five previous messy iterations, and politely asking for feedback. If we see some positive feedback then I'm happy to pick the patch into LE images until ConnMan sees a version bump that includes it.

Doemela · September 20, 2026 at 9:43 PM

UPDATE 2026-09-20: Fixed — patch submitted upstream

Confirmed the leak on stock LE13 nightly 20260920-b68ee23 (ConnMan 2.0, iwd backend, Generic x86_64): fd count 22 → 49+ over VPN cycles, never recovers. Root cause in plugins/wifi.c interface_removed() — early-return skips g_supplicant_interface_cancel().

Patch (v7) submitted to [email protected]. With patch applied: fd returns to baseline (22) after every cycle. Verified data + fix instructions: Upstream ConnMan FD Leak Automated Mitigation Guide

**chewitt** · September 21, 2026 at 2:21 AM

In the v7 submission everything below the first paragraph should have been placed under the --- separator so that it is visible to reviewers but not merged into the codebase along with the description.

I normally place things above --- during development so that testing commentary is easily edited and not forgotten, but then you need to remember to tweak the final patch files before sending to move the --- above it.

Doemela · September 21, 2026 at 2:47 AM

Quote from chewitt

In the v7 submission everything below the first paragraph should have been placed under the --- separator so that it is visible to reviewers but not merged into the codebase along with the description.
I normally place things above --- during development so that testing commentary is easily edited and not forgotten, but then you need to remember to tweak the final patch files before sending to move the --- above it.

Ty v8 submitted with the commentary moved below the separator.

Der Olli · October 26, 2026 at 8:38 PM

Additional data point: reproducible trigger for the UDP :53 leak via a failed online check (no WireGuard)

Setup: RPi2, LibreELEC 12.0.2 (ConnMan 1.43), WiFi only, no VPN/WireGuard, default online check settings ("one-shot", geometric interval [1, 12]).

Symptom: after ~35 days of uptime connmand had ~1015 of 1024 FDs open, followed by "Failed to open/bind time server socket" flooding the journal and NTP no longer syncing.

Findings:

During normal operation there is no leak at all. connmand stayed at 17 FDs for 23 hours.
Clean WiFi reconnects (connmanctl disconnect/connect, 3 cycles) don't leak either. FDs go 17 → 12 → 17 every time and all sockets are closed properly.
A single failed online check does trigger it. I blocked outbound HTTP with
Code
```
iptables -I OUTPUT -p tcp --dport 80 ! -d 192.168.0.0/16 -j DROP
```
and reconnected the WiFi. The service stays in "ready". After the first check times out (~2 min), every retry fails immediately with
Code
```
IPv4 online check to http://ipv4.connman.net/online/status.html failed: -22: Invalid argument
```
Each retry leaves one more UDP socket to the DNS server (router:53) open. FDs went 17 → 24 within ~12 minutes (UDP :53 sockets 3 → 9+).
The online check never recovers by itself. After removing the iptables rule it kept failing with -22 for another 7 minutes (and presumably forever, retrying at up to 144 s intervals), leaking one socket per attempt. Only restarting connman fixed it, after which the check succeeded immediately and FDs were back to 17.

So on my system the chain is: a short internet/connman.net outage → online check stuck in -22 → endless retries → one leaked UDP :53 socket per retry → FD limit reached after a few days → NTP dead. A clean reconnect isn't enough to start it, it needs the check to actually time out.

The ConnMan 1.44 changelog has "Fix issue with handling web context for online detection", and that release reworked the failure path in src/wispr.c / gweb. It might be related, but I haven't tested 12.2.x / 1.45 yet. The iptables rule above should be an easy way for anyone on 12.2 or 13 to check whether it still happens there.

Workaround for now: EnableOnlineCheck = false in /storage/.config/connman_main.conf (CamelCase, [General] section), then restart connman.

Update: still happens on LibreELEC 12.2.1 / ConnMan 1.45

I updated to 12.2.1 (ConnMan 1.45) and repeated the same test (iptables DROP on outbound tcp:80, then WiFi reconnect). So my guess about the 1.44 changelog was wrong. The bug is still there, only the error message changed:

Code

21:52:58 IPv4 online check to http://ipv4.connman.net/online/status.html failed: Input/output error
21:52:59 No valid proxy with proxy auto-configuration (PAC) URL http://wpad.fritz.box/wpad.dat for wlan0 [ wifi ] online check URL http://ipv4.connman.net/online/status.html
21:52:59 IPv4 online check to http://ipv4.connman.net/online/status.html failed: no valid proxy
... (repeats at growing intervals)

The first check times out after ~2 min (Input/output error). After that, every retry fails immediately with no valid proxy.
Each retry still leaks one UDP socket to the DNS server (router:53). connmand went from 20 to 29 FDs in ~11 minutes.
It doesn't recover after the block is removed. I waited another 5+ minutes and it was still "ready" with no valid proxy on every retry. Restarting connman fixes it immediately.

So in 1.45 the failure path seems to switch to WPAD/PAC proxy discovery. The PAC URL is derived from the DHCP domain (fritz.box, my AVM router doesn't provide a wpad.dat). It then never falls back to a direct request again, and every attempt leaves a resolver socket open.

Workaround is unchanged: EnableOnlineCheck = false in /storage/.config/connman_main.conf ([General] section), then restart connman.