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

Hello ConnMan Developers,

To expedite downstream tracking and save triage cycles, we mapped our
telemetry logs directly against the target subsystems. Since the
resource footprint continues to increase monotonically over Wi-Fi
channels despite shutting down user-space proxy routing and connectivity
verification triggers (`OnlineCheckMode = none` and `--nodnsproxy`), the
leakage vector is verified within the core kernel notification loops.

The leak behavior strictly manifests during the parsing sequence for
`RTM_DELLINK` / `RTM_NEWLINK` message sweeps when out-of-band virtual
device routing domains (such as standard `wg0` kernel interfaces) are
recycled beneath active infrastructure.

#### The Code Coordinates to Audit

We highly recommend reviewing the object reference counts and lifecycle
tracking pathways inside `src/rtnl.c`:

1. `rtnl_link_cb` Allocation Boundaries:
   Inside the primary Netlink route event engine handler callbacks,
check whether incoming interface event transitions are cloning reference
counts via structural configurations without matching dereferences when
device groups change state or vanish.

2. `g_io_channel_unref()` Missing Triggers:
   If ConnMan triggers localized wireless scanning adjustments or link
quality polling sweeps over internal communication pipes following link
loss events, verify that the low-level file handles created to poll
netlink arrays are properly executing an explicit `close()` or
`g_io_channel_unref()` upon message resolution loop conclusions.

3. Sub-Interface Tracking Buffers:
   Ensure that virtual routing nodes created dynamically under active
Wi-Fi backhauls clear their child reference records upon interface link
destruction events, instead of abandoning orphaned sockets within the
internal lifecycle architecture.

Our current management suite hooks into the environment by enforcing an
early-stage service-level sandbox (`LimitNOFILE=512`) to act as a
system-safe circuit breaker while this deep-seated lifecycle bug remains
open upstream. 

Hopefully, these technical data logs allow you to pin down the exact
routing socket release mismatch in the core daemon source arrays.

Best regards,  
Doemela

On 2026-08-12 17:23, [email protected] wrote:
> Hello ConnMan Developers,
> 
> Correction to my previous telemetry update: The file descriptor count
> has broken past the initial threshold and is still continuously crawling
> upward on Wi-Fi, even with `OnlineCheckMode=none` and `--nodnsproxy`
> fully operational.
> 
> Here is the extended tracking timeline showing the active, creeping leak
> over time:
> 
> * VPN Connected baseline over Wi-Fi: 18 open files
> * VPN Disconnected (Immediate jump): 34 open files
> * A few minutes later (Idle sitting): 63 open files and climbing!
> 
> # ls -l /proc/$(pidof connmand)/fd | wc -l
> Output: 63
> 
> This completely eliminates the Fritz!Box WPAD or the HTTP online check
> loops as the core drivers of the resource leak. The daemon is actively
> compounding and abandoning sockets/handles on a low-frequency cycle
> purely over the wireless tracking layers. 
> 
> Something inside ConnMan's internal Netlink event listeners or
> link-state polling routines is generating or duplicating sockets on
> every internal cycle following an out-of-band interface teardown, and it
> never executes a clean garbage-collection close().
> 
> Best regards,
> Doemela
> 
> On 2026-08-12 17:20, [email protected] wrote:
>> 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