omarchy-network-status: 100% packet loss when 1.1.1.1 is unreachable

[0zgenius]

Description

omarchy-network-status hardcodes 1.1.1.1 (Cloudflare DNS) as the sole internet ping probe. On networks that block ICMP to 1.1.1.1, the network panel shows "Timeout" and "100% Packet Loss" — even though the internet connection is fully functional and data is flowing normally.

Steps to Reproduce

1. Connect to a network that blocks ICMP to 1.1.1.1 (but allows it to other hosts like 8.8.8.8)
2. Open the network panel
3. Observe "Timeout" / "100% Packet Loss" despite working internet

Expected Behavior

Panel shows real latency and 0% packet loss.

Actual Behavior

Panel shows Timeout / 100% loss.

Suggested Fix

Try multiple probe addresses (1.1.1.1, 8.8.8.8, 9.9.9.9, 208.67.222.222) and use the first that responds. I've locally patched omarchy-network-status with this approach and it works correctly:

ping_best_internet_probe() {
  local result
  result=$(ping_latency_ms "$internet_probe")
  if [[ -n $result ]]; then
    printf '%s' "$result"
    return
  fi
  local probe
  for probe in $internet_fallback_probes; do
    result=$(ping_latency_ms "$probe")
    if [[ -n $result ]]; then
      printf '%s' "$result"
      return
    fi
  done
}

Environment

• Omarchy latest
• Network: ozgenius_5G (5GHz Wi-Fi)
• Router/gateway reachable, internet functional, but 1.1.1.1 ICMP blocked

[AronBakes]

Same underlying bug as #9068, from the host side rather than the protocol side: omarchy-network-status sends one echo to one hardcoded host with no fallback. On the network in #9068 all outbound ICMP is filtered — 8.8.8.8, 9.9.9.9 and 1.0.0.1 time out too — so extra ping hosts don't help there, and PR #9069 falls back to a TCP handshake to 1.1.1.1:443.

I've extended #9069 to cover your case as well: 1.1.1.1 and 8.8.8.8 are pinged in parallel and whichever answers is used, with the handshake only when neither does. Parallel rather than a list because on a fully ICMP-filtered network a sequential list costs a second per host to fail on every poll, and because it keeps the loss row counting one thing.

Two checks on ozgenius_5G would confirm which path your network takes:

ping -c 3 8.8.8.8
timeout 2 bash -c 'exec 3<>/dev/tcp/1.1.1.1/443' && echo tcp ok

[bjarneo]

Automated duplication check: this issue looks similar to #9068, which covers the same network panel false Timeout on filtered ICMP. I keep that one open and close this one to keep the discussion in one place.

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