From: kasuta@riseup.net
To: connman@lists.linux.dev
Subject: Re: [BUG UPDATE] Further isolation: Massive Wi-Fi vs Ethernet divergence on WireGuard disconnect
Date: Wed, 12 Aug 2026 14:41:28 +0000 [thread overview]
Message-ID: <6368c1cf1ddade8d052770691f7bd6e1@riseup.net> (raw)
Hello ConnMan Developers,
Following up on my previous message regarding the WireGuard (wg0)
disconnect trigger, I have conducted further exhaustive testing and
isolated a massive behavioral divergence between Ethernet and Wi-Fi
environments.
### New Discovery: Wi-Fi vs. Ethernet Behavior
1. Ethernet (Stable with Mitigations): When cycling the WireGuard tunnel
while connected via hardwired Ethernet (eth0), resource tracking remains
entirely flat and stable once the `--nodnsproxy` flag is applied.
2. Wi-Fi (Aggressive Persistent Leak): When operating over a wireless
connection (wlan0), disconnecting the exact same WireGuard tunnel causes
an immediate, massive surge in file descriptors within the Main Daemon
(connmand). This leak persistently accumulates on Wi-Fi even with
modifications active.
Live Telemetry Capture (Wireless Environment):
* VPN Connected (Baseline): Main Daemon (connmand) File Descriptors = 19
* VPN Disconnected (Single Trigger Event): Main Daemon (connmand) File
Descriptors = 91
ConnMan instantly leaked 72 file descriptors in a single disconnect
action on Wi-Fi. It appears that under wireless layers, ConnMan’s active
link/BSSID scanning routines or netlink interface listeners (nl80211)
completely fail to execute proper close() system calls when a concurrent
virtual routing interface drops out-of-band.
### Deployed Workaround for Embedded Environments (LibreELEC)
For users running this in read-only appliance platforms (tested on
x86_64 and Raspberry Pi 3/4/5), I have implemented a systemd service
override drop-in alongside a custom configuration to prevent total host
networking freezes:
/storage/.config/connman_main.conf:
[General]
OnlineCheckMode=none
Systemd override block:
[Service]
ExecStart=
ExecStart=/usr/sbin/connmand -n
--config=/storage/.config/connman_main.conf --nodnsproxy
LimitNOFILE=4096
LogRateLimitIntervalSec=0
Capping `LimitNOFILE=4096` ensures systemd will cleanly terminate and
respawn connmand to reclaim leaked file descriptors before it exhausts
the global operating system limit (1024).
This strongly narrows down the root cause to missing resource garbage
collection inside the wireless tracking state machines or netlink route
management loops during out-of-band virtual interface teardowns.
Best regards,
Doemela
next reply other threads:[~2026-08-12 14:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-12 14:41 kasuta [this message]
2026-08-12 15:20 ` [BUG UPDATE] Further isolation: Massive Wi-Fi vs Ethernet divergence on WireGuard disconnect kasuta
2026-08-12 15:23 ` kasuta
2026-08-15 13:57 ` kasuta
2026-08-15 14:02 ` kasuta
2026-08-15 14:41 ` kasuta
2026-08-15 14:48 ` kasuta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6368c1cf1ddade8d052770691f7bd6e1@riseup.net \
--to=kasuta@riseup.net \
--cc=connman@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.