### System details

21DK (ThinkBook 14 G4 ABA), AMD Ryzen 7 5825U (16) @ 4.55 GHz, Omarchy 4.0.3-1

### What's wrong?

## What happened

On a WiFi network whose firewall drops ICMP (a standard enterprise setting —
in my case the university network "wiut"), the network widget in the top bar
reports:

```
Ping        Timeout
Packet Loss 100%
```

while the network is working completely fine: HTTPS sites load, downloads run
at full speed (~200 Mbps), and a TCP connect to 1.1.1.1:443 completes in
~107 ms. The widget is the only thing claiming there is a problem.

## What's actually wrong

The probe behind the widget is `/usr/share/omarchy/bin/omarchy-network-status`,
which measures the two latency samples with **ICMP `ping`**:

```bash
# omarchy-network-status, lines 56-60
ping_latency_ms() {
  local host=$1
  LC_ALL=C ping -n -c 1 -W 1 "$host" 2>/dev/null | \
    awk -F'time[=<]' '/time[=<]/ { split($2, parts, " "); print parts[1]; exit }'
}
```

`internet_probe=1.1.1.1` (line 8). When ICMP is blocked, `ping` exits with no
`time=` line, stdout stays empty, and the value parses to `null`.

The panel then counts **every null sample as a packet loss** rather than as
"no data":

```js
// Model.js, pingPacketLossPercent()
var lost = 0
for (var i = 0; i < values.length; i++) {
  if (values[i] === null) lost++
}
return Math.round((lost / values.length) * 100)
```

So a network that merely *filters ICMP* (while passing TCP/HTTPS fine) is
rendered as "Timeout" + "100% packet loss" — a guaranteed false alarm on any
ICMP-blocking network.

## Steps to reproduce

1. Connect to any network that blocks ICMP echo (captive-portal / enterprise
   university networks are common examples; **wiut** qualifies).
2. Confirm at the shell that the link is actually healthy:
   ```bash
   curl -s -o /dev/null -w '%{time_connect}\n' --connect-timeout 2 https://1.1.1.1
   ping -c 3 1.1.1.1        # <- times out: 100% packet loss
   ```
   (TCP works, ICMP is dropped.)
3. Open the network widget in the bar.
4. Observe: **Ping → Timeout**, **Packet Loss → 100%**.

## Expected behavior

The widget should distinguish "ICMP is filtered by this network" from "the
network is actually lossy" — e.g. by measuring latency over TCP (connect
time), or by dropping samples that never returned instead of counting them as
lost. On the same connection, a TCP-based probe reports ~107 ms and 0% loss,
which matches user-observable behavior.

## Environment / System details

- **Omarchy:** 4.0.3-1
- **Hyprland:** 0.56.2 (built from branch v0.56.2 at commit efb50993780079460b0cbed1363e2166a2de1d9f)
- **Quickshell:** 0.3.1-1 (Arch package)
- **Kernel:** 7.2.3-arch1-3
- **NetworkManager:** nmcli 1.58.1-1
- **Network controller:** Realtek RTL8852BE (rtw89_8852be), Lenovo subsystem
- **Affected network:** open-SSID enterprise network with ICMP-dropping firewall
- **Networking stack:** NetworkManager (no IWD), wpa-supplicant

## Provenance of the fix

A working probe is `/usr/share/omarchy/bin/omarchy-network-status` run with
`--verbose`; its `router_ping_ms`/`internet_ping_ms` values feed the panel.
Replacing the ICMP sample with a TCP connect sample to the same targets
(gateway:80, 1.1.1.1:443) produces identical output shape with correct
numbers. The minimal upstream change would be localized to that one function
(`ping_latency_ms`) and the panel's null-handling in `Model.js`.

## Captures

<img width="604" height="720" alt="Image" src="https://github.com/user-attachments/assets/ad6dff98-17e8-4f55-a071-f89bc418ae44" />