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

[kasuta@riseup.net]

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, kasuta@riseup.net 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, kasuta@riseup.net 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