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

fix(client): configure TAP MAC before relay connect

Browse Source 
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
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+10 -11
View File
@@ -217,17 +217,16 @@ cargo run -p lanparty-client-win -- \
The Windows client binary currently connects to the relay as `role = client`
with a generated locally administered virtual MAC persisted in
`lanparty-client-identity.json`. Before resolving or connecting to the relay,
it selects the TAP-Windows6 adapter and marks TAP media disconnected to clear
stale connected state from a previous crashed run. It then resolves the relay
DNS name before TAP activation, completes the control-stream hello/welcome
handshake, pins a host route for the resolved relay IP on the current pre-TAP
interface, verifies that the relay route still uses that pinned host route
after TAP activation, and then 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 for
bridging, it writes the generated tunnel MAC to the TAP driver's
`NetworkAddress` registry setting.
`lanparty-client-identity.json`. It resolves the relay DNS name before TAP
activation, writes the generated tunnel MAC to the selected TAP driver's
`NetworkAddress` registry setting, and marks TAP media disconnected before
connecting to the relay. That clears stale connected state from a previous
crashed run without letting the TAP adapter influence relay routing. The client
then completes the control-stream hello/welcome handshake, pins a host route
for the resolved relay IP on the current pre-TAP interface, verifies that the
relay route still uses that pinned host route after TAP activation, and bridges
Ethernet frames between the relay and the TAP-Windows6 adapter until shutdown.
`--relay` accepts a DNS name or socket address; bare hosts default to UDP/443.
TAP frames whose source MAC does not match that generated tunnel MAC are
dropped locally before they can consume relay bandwidth; the relay still
enforces the same source-MAC rule.