ddidderr/softlan-vpn
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
a09852dada2f1b523c271bd69ca737a1c7939f28
softlan-vpn/README.md
T
ddidderr a09852dada feat(client): add TAP-Windows adapter crate 
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
2026-05-21 18:48:14 +02:00

4.5 KiB
Raw Blame History

softlan-vpn

Monorepo for a Layer 2 over QUIC LAN party bridge.

Workspace crates

  • lanparty-proto: shared frame format, MAC validation, MTU helpers.
  • lanparty-ctrl: control-plane messages (join/hello/role/version).
  • lanparty-obs: shared diagnostics/logging event models.
  • lanparty-client-core: platform-agnostic client session state.
  • lanparty-client-tap: TAP-Windows6 adapter discovery and frame I/O.
  • lanparty-client-win: Windows TAP + route/metric handling binary.
  • lanparty-gateway: Linux AF_PACKET gateway binary.
  • lanparty-relay: public QUIC relay binary.

lanparty-proto

Transport-agnostic tunnel contract shared by all binaries:

  • overlay datagram header encoding and decoding
  • Ethernet frame header parsing
  • MAC address parsing and identity validation
  • QUIC datagram to TAP MTU budget helpers

lanparty-ctrl

Reliable control-plane schema shared by the QUIC stream handlers:

  • endpoint hello messages with role, room, MAC, and datagram budget
  • server welcome, reject, peer lifecycle, stats, and disconnect messages
  • room-code, role/MAC, peer-id, and effective-MTU validation
  • length-prefixed JSON control frames for reliable QUIC streams

lanparty-obs

Shared diagnostics and structured logging vocabulary:

  • gateway/relay frame logs with MACs, ethertype, length, peer, and action
  • tunnel counters shared by control messages and runtime diagnostics
  • client connectivity/TAP diagnostics and user-facing status messages

lanparty-client-core

Platform-neutral remote client relay session:

  • relay QUIC connection with pinned relay certificate trust
  • client hello with room, virtual MAC, and datagram budget
  • welcome/reject handling with assigned peer id and effective TAP MTU
  • Ethernet frame send/receive helpers over QUIC DATAGRAM

lanparty-client-tap

Windows TAP adapter boundary:

  • TAP-Windows6 adapter discovery from the Windows network adapter registry
  • \\.\Global\{NetCfgInstanceId}.tap device path construction
  • blocking Ethernet frame reads/writes through the TAP device handle
  • TAP driver IOCTL helpers for media status, adapter MAC, and MTU

lanparty-relay

Public relay binary and relay-owned room state:

  • QUIC endpoint binding and first-stream hello/welcome admission
  • room admission for clients and gateways
  • one gateway per room, duplicate client MAC rejection, and room limits
  • stable effective room MTU chosen before Ethernet datagrams flow
  • live Ethernet datagram forwarding with no ingress reflection
  • L2 safety filters for jumbo, switch-control, DHCP-server, and IPv6-RA frames
  • peer leave cleanup for room membership and MAC indexes

Build

cargo check --workspace

Relay

cargo run -p lanparty-relay -- --listen 443/udp --dev-cert-der-out relay-cert.der

--listen accepts either a socket address or a UDP port shorthand such as 443/udp. The relay binds a QUIC endpoint, accepts a control-stream hello, replies with welcome or reject, and forwards live Ethernet QUIC datagrams between accepted peers in the same room. It currently uses a generated self-signed development certificate; --dev-cert-der-out writes that certificate so the gateway and client can pin it in development. Production certificate handling remains future work. Ethernet forwarding decisions are logged with room, peer, MAC, ethertype, action, drop reason, and target count.

Gateway

cargo run -p lanparty-gateway -- \
  --relay 203.0.113.10:443 \
  --server-name lanparty-relay.local \
  --relay-ca-cert relay-cert.der \
  --room ROOM1 \
  --interface eth0

The gateway connects to the relay as role = gateway, completes the control-stream hello/welcome handshake, opens an AF_PACKET socket on the LAN interface, and bridges Ethernet frames between the relay and wired LAN until shutdown. It tracks remote-client source MACs seen from relay traffic and periodically emits small CAM refresh frames so the physical switch keeps those MACs associated with the gateway port.

Windows Client

cargo run -p lanparty-client-win -- \
  --relay 203.0.113.10:443 \
  --server-name lanparty-relay.local \
  --relay-ca-cert relay-cert.der \
  --room ROOM1

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, completes the control-stream hello/welcome handshake, and then waits for shutdown. --virtual-mac can still override the stored identity for manual testing. TAP adapter binding and route pinning are not wired yet.

Reference in New Issue View Git Blame Copy Permalink