[BUG UPDATE] Wi-Fi vs Ethernet behavior isolated on WireGuard (wg0) disconnect leak

[BUG UPDATE] Wi-Fi vs Ethernet behavior isolated on WireGuard (wg0) disconnect leak

[kasuta]

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