Re: [BUG UPDATE] Further isolation: Massive Wi-Fi vs Ethernet divergence on WireGuard disconnect

Hello ConnMan Developers,

An important update regarding the live telemetry behavior after
completely fixing the configuration file casing layout. 

Once `OnlineCheckMode=none`, `OnlineCheckIPv4URL=`, and
`OnlineCheckIPv6URL=` are cleanly parsed by ConnMan, the infinite
runaway compounding leak is successfully contained. The daemon no longer
crawls endlessly toward 1024, confirming that the continuous crawl was
driven by the online probing subsystems reacting to the broken gateway
path.

However, a structural "rest-leak" still occurs instantly upon the
WireGuard disconnect event over Wi-Fi. The descriptor count behaves as
follows:

* VPN Connected baseline over Wi-Fi: 18 open files
* VPN Disconnected event (Immediate jump): 34 open files
* Idle sitting (Long-term tracking): Hard lock at 34 open files

The daemon drops the continuous crawling behavior, but it permanently
holds onto exactly 16 leaked file descriptors/sockets from the dead
virtual interface. This confirms that while the online validation loop
causes the aggressive crash, ConnMan's core state engine still fails to
perform a clean garbage-collection teardown of the primary interface
handles when an out-of-band virtual tunnel drops over wireless layers.

Best regards,
Doemela

On 2026-08-12 16:41, [email protected] wrote:
> 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