Skip to content

Report the link carrying a VPN rather than the tunnel - #6741

Closed
KazeTachinuu wants to merge 1 commit into
omacom:quattrofrom
KazeTachinuu:network-status-underlay
Closed

KazeTachinuu wants to merge 1 commit into
omacom:quattrofrom
KazeTachinuu:network-status-underlay

Conversation

@KazeTachinuu

Copy link
Copy Markdown
Contributor

The network panel says Ethernet while you're on wifi, whenever a VPN is up. The header reads Ethernet with the wifi icon sitting right above it in the bar, since the two come from different sources.

$ omarchy-network-status
ethernet	<tunnel>

It takes whatever device holds the internet route and calls it ethernet if it isn't wireless. A wireguard or tun interface is neither, and the rest of the reading comes off the tunnel instead of the wifi card: no gateway, so the router ping never runs; byte counters and link speed from an interface that has no speed; an error printed from cat /sys/class/net/<tunnel>/speed; and the header network name, the band section and the QR share all go missing.

Fix: find the real interface first, then ask whether it's wifi or ethernet. Real hardware has a wireless directory or a device symlink in /sys/class/net, and when a tunnel holds the route, the main routing table still points at the card carrying it.

$ omarchy-network-status
wifi	<ssid>	85	5540.0

If nothing on the path has hardware behind it, inside a container for instance, it keeps the routed device rather than claiming you're disconnected.

Wifi or ethernet is a question about hardware: a wireless directory or a
device symlink under /sys/class/net. The status command asked it of
whichever device held the internet route and read everything that wasn't
wireless as ethernet, so a wireguard or tun device, which is neither,
came back ethernet for want of anywhere else to land. With a VPN up the
panel reads Ethernet on a laptop sitting on wifi, and the rest of the
reading follows the tunnel: the gateway is empty so the router ping never
runs, the counters and link speed come off an interface that has no speed
to report, the sections naming the network and its band are gone, and
reading /sys/class/net/<tunnel>/speed prints an error over the output.

Resolve the link before classifying it. Policy routing leaves the carrier
on the main table's default, so take the first default there with
hardware behind it. Where the path is virtual the whole way down, a
container overlay among others, keep the device the route named: that
reading is no worse than before, and a working connection should not
report itself disconnected.
@KazeTachinuu
KazeTachinuu marked this pull request as ready for review August 12, 2026 10:40
Copilot AI balanced review requested due to automatic review settings August 12, 2026 10:40

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot wasn't able to review any files in this pull request.


💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

@bjarneo

bjarneo commented Sep 21, 2026

Copy link
Copy Markdown
Member

Automated duplication check: this pull request looks similar to #8866, which covers the same physical-link resolution under VPN tunnels. I keep that one open and close this one to consolidate review.

If you feel this is the wrong decision, please open the PR again with a note on the difference.

@bjarneo bjarneo closed this Sep 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants