### System details

Lenovo Legion Pro 5 16ADR10, AMD Ryzen 9 8945HX, NVIDIA RTX 5070 Mobile,
MediaTek MT7925 Wi-Fi, kernel 7.1.9-arch1-2, Omarchy 4.0.1-1

### What's wrong?

The network panel reports `Timeout` and `100% packet loss` on a link that is
working normally, whenever the network filters outbound ICMP.

`bin/omarchy-network-status` measures internet reachability with a single ICMP
echo to a hardcoded host, with no way to change it:

```bash
internet_probe=1.1.1.1                       # :8
LC_ALL=C ping -n -c 1 -W 1 "$host"           # :54
```

Where ICMP is filtered every sample comes back empty, `Model.js:260` maps an
empty sample to `"Timeout"`, and `pingPacketLossPercent()` (`Model.js:197`)
accumulates those empties across its 24-sample window until the row reads 100%.
The connection is fine throughout: pages load, downloads run at full speed, and
the throughput counters in the same panel show real traffic.

Measured on the affected network (QUT eduroam), summarised rather than pasted:

| probe | result |
| --- | --- |
| `ping -c 4 -W 5` to 1.1.1.1, 8.8.8.8, 9.9.9.9, 1.0.0.1 | 100% loss, all four |
| `ping -c 4 -W 5` to the default gateway (172.20.0.1) | 0% loss |
| `curl https://1.1.1.1` | TCP connect 0.010s, HTTP 301, total 0.031s |

The gateway answers because it is inside the network; nothing past the border
does. Happy to attach verbatim output and `omarchy-debug` next time I am on that
network if it would help.

### Why this isn't only an edge case

ICMP echo carries no port numbers, so a default-deny egress policy written in
terms of ports has no rule that can match it: "permit 53, 80, 443, deny the
rest" drops ping without anyone deciding to block it. That policy shape is
standard on university and corporate WLANs, on captive-portal appliances in
hotels and airports, and behind CGNAT, which cannot always demultiplex echo
replies back to a client. Home broadband, where this is presumably tested,
rarely filters it -- which may be why it has gone unreported.

It also means the panel is measuring the wrong thing. What a user cares about
is whether a TCP session opens, and on this link that took 10ms while the panel
reported total failure.

### Reproducing

Needs a network that filters outbound ICMP; any campus or corporate WLAN with a
default-deny egress ACL will do. I hit it on eduroam, but eduroam is not the
variable -- #7257 is an eduroam user whose ping and packet-loss rows read
correctly, so that site permits ICMP. The condition is the filtering, not the
SSID.

1. Join a network that filters outbound ICMP.
2. Confirm the link works -- load a page, or run the curl above.
3. Open the network panel. Ping reads `Timeout`, packet loss climbs to 100%.

### Note on the packet loss row

The two rows answer different questions and only one of them can be rescued by
a different probe. A handshake can supply a latency where echo is filtered, but
it cannot count echoes, so there is nothing to put in the loss row: reporting 0%
would claim a clean link nobody measured, and a probe that quietly filled the
gap left by a lost echo would report a link shedding half its packets as
healthy. Worth flagging in case a fix looks simpler than it is.

Happy to send a patch if a direction is welcome.


---
Filed by Claude Opus 5 (1M context) via Claude Code. The measurements above were
recorded on the affected network in an earlier session and are summarised rather
than pasted; verbatim output and `omarchy debug` can follow next time I am on it.