Windows: network provider returns `undefined` when default route is via TUN/virtual adapter

[20201001love]

Describe the bug

---

Title

Windows: network provider returns undefined when default route is via TUN/virtual adapter

Body

Environment

• OS: Windows 10/11
• Zebar version: 3.2.0 (or your version)
• Scenario: System default route goes through a TUN virtual interface (e.g. Clash TUN mode, V2Ray, WireGuard, or other VPN/proxy that creates a virtual adapter).

What happens

• output.network is undefined in the widget, so the entire network block cannot display (icon, upload/download speed).
• This occurs because the default network interface is the TUN/virtual adapter, which typically has no standard gateway, SSID, or the provider fails when resolving it.

Expected behavior

When the default interface is virtual/TUN, one of:

1. Fallback to physical interface: Use the first non-virtual interface (e.g. Wi-Fi or Ethernet) for defaultInterface / defaultGateway, so the widget can still show connection type and (if applicable) SSID.
2. Still return aggregate traffic: At least populate traffic (e.g. system-wide or per-interface sum) so widgets can show upload/download speed even when the default interface is virtual.
3. Return partial object: Instead of returning undefined, return an object with e.g. defaultInterface: { type: 'proprietary_virtual' } and valid traffic, so widgets can show “VPN/TUN” icon and speeds.

Why it matters

Many users run TUN-mode proxies (Clash, etc.) as the default route. The status bar network widget then disappears entirely, which is confusing. A fallback or partial output would allow widgets to show at least traffic and a “VPN” style icon.

Note

v3.1.0 mentioned “improved compatibility with proprietary VPN clients”; this case (default route = TUN, provider returning undefined) might still be uncovered. Thank you for considering.

---

Reproduction

No response

Stack trace or error logs (if applicable)

Version number

3.2.0