ddidderr
a09852dada
The Windows client still needs a real Ethernet TAP boundary before it can pump
frames between the adapter and the relay session. Keep that OS-specific surface
separate from the QUIC client state by adding a `lanparty-client-tap` crate.
The new crate discovers TAP-Windows6 adapters through the Windows network
adapter registry class, validates `tap0901` component ids, constructs the
`\\.\Global\{NetCfgInstanceId}.tap` device path, opens the TAP device handle,
and exposes blocking Ethernet frame read/write helpers. It also wraps the
TAP-Windows IOCTLs for media status, driver MAC, and driver MTU.
This does not wire the TAP crate into `lanparty-client-win` yet and does not
attempt route protection. The value of this slice is the target-checkable OS
boundary that the next client pump can depend on.
Test Plan:
- cargo fmt --check
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings
- Windows-target cargo check for lanparty-client-tap with clang-cl/lld-link
- Windows-target cargo clippy for lanparty-client-tap with -D warnings
- git diff --check
Refs: PLAN.md Windows TAP client
18 lines
386 B
TOML
18 lines
386 B
TOML
[package]
|
|
name = "lanparty-client-tap"
|
|
version.workspace = true
|
|
edition.workspace = true
|
|
|
|
[dependencies]
|
|
anyhow.workspace = true
|
|
lanparty-proto = { path = "../lanparty-proto" }
|
|
|
|
[target.'cfg(windows)'.dependencies]
|
|
windows-sys = { workspace = true, features = [
|
|
"Win32_Foundation",
|
|
"Win32_Security",
|
|
"Win32_Storage_FileSystem",
|
|
"Win32_System_IO",
|
|
"Win32_System_Registry",
|
|
] }
|