From: kasuta@riseup.net
To: connman@lists.linux.dev
Subject: [BUG UPDATE] Wi-Fi vs Ethernet behavior isolated on WireGuard (wg0) disconnect leak
Date: Wed, 12 Aug 2026 14:36:15 +0000 [thread overview]
Message-ID: <43dd58a734ea77cdbcc6e87003032a11@riseup.net> (raw)
Hello ConnMan Developers,
I am writing to provide critical new diagnostic data regarding the file
descriptor resource leak when paired with out-of-band virtual interfaces
(kernel-space WireGuard wg0 tunnel).
After conducting exhaustive monitoring across multiple devices and
builds (including LibreELEC 12/13 running on x86_64 and Raspberry Pi
3/4/5), I have successfully isolated a massive behavioral divergence
between Ethernet and Wi-Fi connections.
### New Discovery: Wi-Fi vs. Ethernet Behavior
1. Ethernet (Stable with Mitigations): When cycling the WireGuard (wg0)
virtual tunnel while connected via a hardwired Ethernet (eth0)
interface, connmand 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 resource 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 when operating over wireless layers,
ConnMan’s active link/BSSID scanning routines or netlink interface
listeners (nl80211) completely fail to execute proper close() system
calls on tracking handles 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, I have
implemented a systemd service override drop-in alongside a custom
configuration:
/storage/.config/connman_main.conf:
[General]
OnlineCheckMode=none
OnlineCheckURL=
OnlineCheckInterval=0
Systemd override block:
[Service]
ExecStart=
ExecStart=/usr/sbin/connmand -n
--config=/storage/.config/connman_main.conf --nodnsproxy
LimitNOFILE=4096
LogRateLimitIntervalSec=0
By forcing `OnlineCheckMode=none` and `--nodnsproxy`, we stabilize
Ethernet. However, because the count continuously climbs on Wi-Fi due to
the underlying wireless link tracking leak, 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), preventing total host networking freezes.
This 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
reply other threads:[~2026-08-12 14:36 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=43dd58a734ea77cdbcc6e87003032a11@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox