feat(client): log TAP frame movement

The relay and gateway already emit structured frame logs, but the Windows
client only exposed aggregate counters. During the MVP end-to-end test that
left a blind spot between TAP reads/writes and the relay datagram path.

Add client-side frame log lines for accepted TAP-to-relay sends,
relay-to-TAP writes, and local TAP-frame drops before relay send. The logs use
the shared FrameLog vocabulary with TapToRelay and RelayToTap directions so the
client, relay, and gateway logs can be correlated during DHCP, ARP, ping, and
LAN-game discovery checks.

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

Refs: MVP Windows client diagnostics
This commit is contained in:
2026-05-22 06:54:11 +02:00
parent 50ddadc82d
commit ca57b90228
4 changed files with 126 additions and 6 deletions
+4 -2
View File
@@ -41,7 +41,7 @@ Reliable control-plane schema shared by the QUIC stream handlers:
Shared diagnostics and structured logging vocabulary:
- gateway/relay frame logs with MACs, ethertype, length, peer, and action
- client/gateway/relay frame logs with MACs, ethertype, length, peer, and action
- tunnel counters shared by control messages and runtime diagnostics
- client connectivity/TAP diagnostics and user-facing status messages
@@ -280,7 +280,9 @@ stopping the bridge. Relayed LAN frames are also safety-checked before TAP
writes, so switch-control traffic, invalid-source frames, and jumbo frames stay
out of the Windows adapter even if they reached the client over QUIC.
Misdirected unicast frames not addressed to the client's virtual MAC are also
counted and skipped; TAP device read/write errors still stop the bridge.
counted and skipped; accepted TAP-to-relay and relay-to-TAP frames are logged
with direction, peer id, MACs, ethertype/length, frame length, action, and drop
reason. TAP device read/write errors still stop the bridge.
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