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

feat(client): include gateway presence in diagnostics

Browse Source 
PLAN.md calls for user-facing diagnostics that can say whether the remote
client is connected to the LAN gateway. Startup already reported the initial
welcome bit, but periodic diagnostics only carried relay reachability and route
pinning.

Add gateway_connected to RelayDiagnostics and seed the client status from the
welcome. The client control-event logger now updates that status when gateway
join and leave events arrive, so later diagnostics reflect relay lifecycle
changes while the tunnel is running.

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

Refs: PLAN.md
This commit is contained in:
ddidderr
2026-05-21 21:47:53 +02:00
parent 6a18daac3a
commit 9722adbd70
3 changed files with 87 additions and 31 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+7 -7
View File
@@ -202,10 +202,10 @@ does not match the tunnel identity, because an already-initialized Windows TAP
adapter may need to be disabled/enabled or reinstalled before it reloads the
configured `NetworkAddress`.
It prints and reports client diagnostics snapshots with relay reachability,
route-pinning, QUIC datagram budget, TAP status/IP, 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.
LAN-gateway presence, route-pinning, QUIC datagram budget, TAP status/IP,
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.