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

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