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

docs(testing): align client startup log guide

Browse Source 
The manual MVP proof asks the tester to compare the Windows client output with
TESTING.md. That block had the right concepts, but the order did not match the
current startup path after TAP route protection moved earlier in the flow.

Update the expected client output to include the connect, TAP-open, interface,
bridge, and lifecycle-event lines in the order the binary emits them. Also call
out the expected MTU, metric, and default-route protection lines so they are not
mistaken for surprising output during the Windows handoff run.

Test Plan:
- cargo test -p lanparty-client-win
- git diff --check

Refs: MVP Windows client handoff
This commit is contained in:
ddidderr
2026-05-22 09:18:32 +02:00
parent e2e8741974
commit 2d8a229c32
1 changed files with 10 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files
TESTING.md
+10 -2
View File
@@ -230,16 +230,24 @@ Expected client output:
prepared TAP adapter ... MAC ... configured and media disconnected before relay connect prepared TAP adapter ... MAC ... configured and media disconnected before relay connect
relay route pinned before TAP ... relay route pinned before TAP ...
relay route verified before TAP activation ... relay route verified before TAP activation ...
lanparty-client-win connecting virtual MAC ... to relay ... room ROOM1
lanparty-client-win connected as peer ...; LAN gateway connected yes (peer ...) lanparty-client-win connected as peer ...; LAN gateway connected yes (peer ...)
relay event: LAN gateway connected as peer ... lanparty-client-win opened TAP adapter ...
relay route verified after TAP activation ...
TAP driver reports MAC ... and MTU ... TAP driver reports MAC ... and MTU ...
TAP interface index ... LUID ...
relay route verified after TAP activation ...
client diagnostics: relay reachable yes gateway connected yes route pinned yes ... client diagnostics: relay reachable yes gateway connected yes route pinned yes ...
bridging TAP frames; relay route is pinned and TAP route policy is scoped ...
relay event: LAN gateway connected as peer ...
``` ```
The route pin line ends with `(created)` or `(already existed)`. Either is OK. The route pin line ends with `(created)` or `(already existed)`. Either is OK.
`already existed` usually means a matching relay host route was already present, `already existed` usually means a matching relay host route was already present,
for example after a previous crashed test run. for example after a previous crashed test run.
You may also see TAP IPv4/IPv6 MTU, metric, and default-route protection lines
between the connect and TAP-open lines. Those are expected.
The lifecycle event may appear after the bridge starts because event logging
begins once TAP and route protection are ready.
The first diagnostics line may show `IP unknown`. After DHCP succeeds, a later The first diagnostics line may show `IP unknown`. After DHCP succeeds, a later
line should show: line should show: