# Wi-Fi/projector/dashboard diagnostics notes

Use this reference for recurring home-network investigations where the user wants an understandable history dashboard plus occasional packet evidence. The class of task is: Wi-Fi/SSH/tmux lag with changing topology, phone hotspots, projectors/streaming devices, and non-technical viewers.

## Storage and legibility defaults

- Do not write repeated diagnostics to the Desktop.
- Use a single run directory under `~/.local/state/hermes/net-tests/<scenario>-<timestamp>/`.
- Put generated dashboards under `~/.local/share/hermes/net-dashboard/`.
- For non-technical viewers, lead with spike charts and plain-language event cards. Keep tables and packet details behind `<details>`.

## Event markers matter

When the user reports a real-world change, immediately write a marker file in the active run directory with:

- machine timestamp (`date --iso-8601=seconds`)
- user-observed timestamp if different (e.g. installer top-bar time)
- exact text/status the user saw
- current quick pings if useful

Examples of useful markers:

- projector turned on / streaming started
- Ubuntu installer visible / finished
- APT transaction summary visible
- Bluetooth turned off
- phone hotspot/network switch

If a capture window ended before the user's marker, say so clearly: that run is a pre-event baseline, not post-event evidence.

## Avoid false single-cause stories

Projector tests can have multiple simultaneous variables. Label the dashboard accordingly rather than saying "Epson only" when other load is active.

Example topology note to capture:

- debby is on phone hotspot in basement
- projector/router are upstairs
- another Ubuntu laptop is also on the hotspot near the projector/router
- Ubuntu installer may or may not still be downloading
- Android hotspot client isolation may prevent seeing the other laptop in `ip neigh`

Interpret spikes by segment:

- clean gateway + spiky internet/Tailscale => upstream/mobile/hotspot saturation or bufferbloat
- spiky gateway too => local Wi-Fi/RF/hotspot contention
- improvement after Ubuntu install finishes => installer/download load was relevant
- continued spikes after installer finishes while projector streams => projector/streaming or broader RF/mobile path remains suspect

## Short pcap sampling pattern

With low disk space, avoid continuous pcaps. Prefer periodic short packet samples:

- 20 seconds every 5 minutes
- strict per-sample filesize caps
- stop below a free-space threshold
- capture control/diagnostic traffic and interactive paths, not full large-download payloads

Suggested filters:

- Wi-Fi interface: `arp or icmp or port 53 or udp port 5353 or udp port 5355 or udp port 1900 or udp port 3702 or udp port 41641 or host <gateway> or net <hotspot-subnet>`
- Tailscale interface: `tcp port 22 or icmp`

Keep pcaps under the active run directory in `pcap-samples/`, and summarize them into the dashboard later. Do not dump raw packet logs into chat.

A reusable sampler script is available at `scripts/periodic-pcap-sampler.sh`.

## Bluetooth on 2.4 GHz

If Wi-Fi is also 2.4 GHz, Bluetooth can sometimes contribute to local jitter because Wi-Fi/Bluetooth coexist on nearby spectrum and often shared hardware. Treat Bluetooth-off as a marker and compare before/after; do not overclaim. If local gateway ping stays good but internet/Tailscale remains hundreds of ms, Bluetooth is not the main cause.

## Ubuntu installer / APT evidence

Installer screenshots can provide useful network-load timing. Record visible logs with both report time and screenshot/log timestamps. For example, an APT summary showing `Need to get: 218 MB` and visible `Get:` lines around 23:49 means a real download phase occurred then, even if the user reports it later.