fix(client): configure TAP MAC before relay connect

The Windows startup path opened the TAP adapter to clear stale media state
before loading the persisted tunnel identity and writing the NetworkAddress
registry value. That made the first TAP touch happen with whatever MAC Windows
already had loaded from a previous run.

Build the client runtime config first so the virtual MAC and resolved relay
address are known before TAP activation. The pre-connect TAP preparation now
writes the selected adapter's NetworkAddress value before opening the adapter to
mark media disconnected. The relay route is still pinned only after the relay
handshake, while TAP remains media-disconnected.

This reduces the chance of a first-run or post-crash TAP MAC mismatch during
the manual Windows MVP test. The client still validates the driver-reported MAC
before bridging and still fails closed if Windows has not reloaded the registry
value.

Test Plan:
- cargo test -p lanparty-client-win
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings
- cargo fmt --check
- git diff --check
- cargo check -p lanparty-client-win --target x86_64-pc-windows-gnu
  - blocked by missing x86_64-w64-mingw32-gcc for ring on this host

Refs: PLAN.md Windows routing / metric handling; TESTING.md MVP guide

This commit is contained in:

ddidderr

2026-05-22 05:43:16 +02:00

parent bd6479e4b5

commit 563a073d24

3 changed files with 29 additions and 17 deletions

									
										TESTING.md
									
		+1
		-1
	
												View File
												
				@@ -119,7 +119,7 @@ one explicitly:

				Expected client output:

				```text

				prepared TAP adapter ... media disconnected before relay connect

				prepared TAP adapter ... MAC ... configured and media disconnected before relay connect

				lanparty-client-win connected as peer ...

				relay route pinned before TAP ...

				relay route verified after TAP activation ...