fix(client): reuse existing relay host route

A crashed or forcibly killed Windows client can leave the scoped relay host
route behind. The next run should still be allowed to start when Windows says
that the exact route row already exists, because that route already protects the
relay path from TAP default-route takeover.

Handle ERROR_OBJECT_ALREADY_EXISTS from CreateIpForwardEntry2 as a successful
borrowed pin. Routes created by the current client are still deleted on Drop;
pre-existing routes are left alone so we do not remove administrator-managed or
stale routes that this process did not create. The client startup log now marks
whether the route was created or already existed, and the README and MVP test
guide explain the behavior.

Test Plan:
All cargo commands used these environment variables:
RUSTUP_HOME=/tmp/softlan-vpn-rustup
CARGO_HOME=/tmp/softlan-vpn-cargo

- cargo fmt --check
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings
- cargo check -p lanparty-client-route --tests
  --target x86_64-pc-windows-gnu
- cargo check -p lanparty-client-route --tests
  --target x86_64-pc-windows-msvc
- cargo clippy -p lanparty-client-route --tests
  --target x86_64-pc-windows-gnu -- -D warnings
- cargo clippy -p lanparty-client-route --tests
  --target x86_64-pc-windows-msvc -- -D warnings
- git diff --check

Known limitation: full lanparty-client-win Windows cross-check is still blocked
on this Linux host by the external ring toolchain setup. The GNU target lacks
x86_64-w64-mingw32-gcc, and the MSVC target lacks lib.exe/MSVC environment.

Refs: PLAN.md route-protection requirement
This commit is contained in:
2026-05-22 04:40:05 +02:00
parent 0784e73f30
commit abc75831cb
4 changed files with 60 additions and 13 deletions
+4 -2
View File
@@ -79,6 +79,7 @@ Windows route-table boundary:
- scoped default-route suppression with restore-on-drop behavior
- unicast IP address snapshots for TAP diagnostics
- scoped host-route pinning for the relay IP on the pre-TAP interface
- reuse of an already-existing matching relay host route without deleting it on exit
- non-Windows builds return a clear unsupported-platform error
### `lanparty-client-tap`
@@ -214,8 +215,9 @@ bridges Ethernet frames between the relay and the first TAP-Windows6 adapter
until shutdown. `--relay` accepts a DNS name or socket address; bare hosts
default to UDP/443. Before opening the adapter, it writes the
generated tunnel MAC to the TAP driver's `NetworkAddress` registry setting.
The startup status reports whether the relay already has a LAN gateway for the
room.
If the exact relay host route already exists, the client uses it and leaves it
alone on exit. The startup status reports whether the relay already has a LAN
gateway for the room.
`--virtual-mac` can still override the stored identity for manual testing. On
Windows it sets the TAP IP interface MTU to the relay-selected MTU, marks the
TAP media connected for the scoped client run, and reports the driver MAC/MTU