fix: do not treat TUN route devices as the bar's network

[kvnloo]

Closes #9624

Split-table VPNs (e.g. Meta) win ip route get 1.1.1.1 with a TUN iface that has no wireless sysfs, so the bar prints ethernet/Meta while nmcli still has wifi connected.

After ip route get, if the iface is TUN/TAP (type 65534) or PPP (512), fall back to the nmcli wifi device in connected. Sysfs root is overridable via OMARCHY_NET_SYSFS for the pin.

test/shell.d/network-status-tun-test.sh PASS on 5f1a7be9.

[omarchybot]

Reviewed against quattro (merge-base b686ed8, head 5f1a7be) by Claude Opus 5 in Claude Code, with an independent second opinion from Codex at xhigh reasoning. Everything below was run on a disposable VM, never on this machine. Where the two reviews agree that is said plainly — Codex's independence is not currently guaranteed, so agreement is worth less than the measurements.

What it fixes. The reported case works. With a TUN device owning the route to 1.1.1.1 and NetworkManager reporting a connected Wi-Fi device, omarchy-network-status names the Wi-Fi device instead of the tunnel. Classifying by kernel device type rather than by interface name is the right instinct — Meta and tailscale0 are unmatched by any name rule.

The bar goes dark when there is no Wi-Fi to fall back to. bin/omarchy-network-status:47 replaces the route device with wifi_connected_device unconditionally, and when that comes back empty line 50 prints disconnected. Measured on a VM with a working internet connection, a real Ethernet default route, and a tun device holding the route to 1.1.1.1:

base : ethernet  omatun9666
9666 : disconnected

That is a wired desktop on a VPN, and the widget now says it is offline while it is online. Same for a WireGuard-only or tethered box whose only connectivity is the tunnel, and for a Tailscale exit node on a wired machine. Retaining the routed device when no replacement is found would keep the fix and drop this case.

Two real WAN link types are classified as tunnels. This is Codex's finding, not something I had reasoned about, and the mechanism holds up in the kernel sources: type 512 is ARPHRD_PPP, used by PPP, PPPoE and serial/mobile links, and raw-IP QMI WWAN modems set ARPHRD_NONE (65534) just as a tun does. On such a machine is_tunnel_iface returns true for the interface that is genuinely carrying the internet, so it is either replaced by an unrelated Wi-Fi or blanked by the paragraph above. I could not put a PPPoE or WWAN link on the test VM, so this one is reasoned from the drivers rather than measured.

The tun probe at line 31 never matches, and tap-mode tunnels slip through. Measured on the VM, with a tun, a tap and a WireGuard interface created for the purpose:

omatun9666  type 65534  tun_flags 0x1801  (no `tun` entry)
omatap9666  type 1      tun_flags 0x1802  (no `tun` entry)
omawg9666   type 65534  no tun_flags

The driver exposes tun_flags, owner and group flat in the device directory; there is no tun child, so [[ -e $net_sysfs/$device/tun ]] is dead code and the type test is doing all the work. That matters because a tap device is ARPHRD_ETHER (type 1), so bridged OpenVPN is not detected at all — and tun_flags is the attribute that would catch tun and tap together, without catching PPP or WWAN.

The test passes whether or not the fix is present. test/shell.d/network-status-tun-test.sh:18 re-declares its own copy of is_tunnel_iface and asserts against the copy; the other three assertions grep the script for the strings OMARCHY_NET_SYSFS, is_tunnel_iface and wifi_connected_device. Nothing sources the script, stubs ip/nmcli, or calls print_status. Demonstrated by mutation: on the worker I changed the shipped comparison to [[ $iface_type == 999999 ]] — the fix disabled entirely — and the file still reported 4 ok, 0 failed. Stubbing ip and nmcli on PATH and asserting on print_status's actual output is what would have caught the two findings above; it is how I measured them.

Smaller. OMARCHY_NET_SYSFS is only honoured in print_status; print_verbose still hardcodes /sys/class/net. And wifi_connected_device requires the state to be exactly connected, so a Wi-Fi device NetworkManager reports as connected (externally) is no fallback at all.

--verbose is untouched, and that is the panel's data source. print_verbose resolves the route again on its own at bin/omarchy-network-status:111, so with a TUN route it still prints iface <tunnel> and type ethernet — measured on the VM. shell/plugins/panels/network/Panel.qml:812 reads exactly that output, so the panel's detail view is unchanged by this PR. Worth knowing either way: the bar pill's own icon comes from NetworkManager at Panel.qml:435 and never runs this command, so the pill is not what this diff moves.

Tests. On the worker: test/shell.d/network-status-tun-test.sh (4 ok), network-test.sh (104 ok), network-qr-test.sh (7 ok) and test/cli (116 ok, exit 0), all green — with the caveat about the new file above.

Nothing was pushed to your branch. #9652 fixes the same issue (#9624) with a different rule, so this is two designs for one behaviour rather than one being a correction of the other, and which one lands is the maintainer's call — neither PR is being closed or edited here. The disconnected regression is worth answering whichever way that goes.