ddidderr
f88c8a94f8
Use the new route snapshot helper in the Windows client startup path before the TAP adapter is opened and marked connected. The client now reports the current relay destination route: selected source address, next hop, interface index, interface LUID, route prefix, and metric. This is still diagnostic only. Route pinning remains unwired, and route lookup failure is a warning so manual TAP frame-pump testing is not blocked by a route inspection failure. Once mutation is implemented, this snapshot gives the code the pre-TAP interface data it needs to preserve the real internet path. Verification note: I attempted to check `lanparty-client-win` for `x86_64-pc-windows-msvc`, but this host still lacks the Windows C headers needed by `ring`; the build stops at `assert.h` before the binary crate can be typechecked for Windows. Test Plan: - cargo fmt --check - cargo test --workspace - cargo clippy --workspace --all-targets -- -D warnings - cargo check -p lanparty-client-route --target x86_64-pc-windows-msvc - cargo clippy -p lanparty-client-route --target x86_64-pc-windows-msvc -- -D warnings - git diff --check Refs: PLAN.md
17 lines
486 B
TOML
17 lines
486 B
TOML
[package]
|
|
name = "lanparty-client-win"
|
|
version.workspace = true
|
|
edition.workspace = true
|
|
|
|
[dependencies]
|
|
anyhow.workspace = true
|
|
clap.workspace = true
|
|
lanparty-client-core = { path = "../lanparty-client-core" }
|
|
lanparty-ctrl = { path = "../lanparty-ctrl" }
|
|
lanparty-proto = { path = "../lanparty-proto" }
|
|
tokio.workspace = true
|
|
|
|
[target.'cfg(windows)'.dependencies]
|
|
lanparty-client-route = { path = "../lanparty-client-route" }
|
|
lanparty-client-tap = { path = "../lanparty-client-tap" }
|