ddidderr/softlan-vpn
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(client): print user-facing diagnostics

Browse Source 
The PLAN calls out client diagnostics that a user can read directly, not only
machine-shaped counters. The Windows client already built ClientDiagnostics
snapshots, but it printed a dense status line and left the UserDiagnostic model
unused.

Derive user-facing diagnostics from ClientDiagnostics in lanparty-obs so a
future GUI and the current CLI can share the same status vocabulary. The
messages report the states the runtime actually observes: relay reachability,
LAN gateway presence, TAP IP presence, and observed broadcast traffic. TAP IPs
are only described as DHCP when they are non-link-local IPv4 addresses, because
link-local IPv4 and IPv6 addresses do not prove DHCP success.

The client now prints those user-facing lines after the existing detailed
counter line. Gateway latency is intentionally not reported here; the current
protocol does not measure gateway RTT.

Test Plan:
- cargo fmt --check
- cargo test -p lanparty-obs -p lanparty-client-win
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings
- git diff --check
- git diff --cached --check

Refs: PLAN.md Logging / diagnostics
This commit is contained in:
ddidderr
2026-05-21 22:22:43 +02:00
parent 881dee5491
commit 733badd2a8
3 changed files with 154 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+7 -4
View File
@@ -216,7 +216,10 @@ It prints and reports client diagnostics snapshots with relay reachability,
LAN-gateway presence, route-pinning, QUIC datagram budget, TAP status/IP,
broadcast frame flow, frame/datagram counters, and drops. The periodic
diagnostics refresh the TAP unicast IP so DHCP results that arrive after
bridging starts become visible in later status lines. Relay lifecycle events
are logged as they arrive, including gateway joins and peer leaves. The client
remembers peer identities from join and catch-up events so later leave logs can
identify a disconnected LAN gateway or client MAC when that peer was known.
bridging starts become visible in later status lines. Each snapshot also emits
short user-facing lines such as relay/gateway connection status, DHCP address
presence, and broadcast-flow confirmation when those signals are observed.
Relay lifecycle events are logged as they arrive, including gateway joins and
peer leaves. The client remembers peer identities from join and catch-up events
so later leave logs can identify a disconnected LAN gateway or client MAC when
that peer was known.