Commit Graph

10 Commits

Author SHA1 Message Date
ddidderr 763a55bfba feat(gateway): connect to relay control plane
The gateway binary now has a real relay-facing configuration and QUIC control
handshake. It accepts a relay socket address, expected TLS server name, pinned
DER relay certificate, room code, LAN interface name, and advertised datagram
budget, then connects as role = gateway and waits for a welcome response.

The ALPN token moved into lanparty-ctrl so relay and gateway share the same
protocol identifier instead of carrying duplicate private constants. The gateway
still stops after the control-plane connection; AF_PACKET capture and injection
remain a later slice.

The connector test spins up a local Quinn server with a self-signed certificate,
trusts that certificate explicitly, verifies the outgoing gateway hello, and
checks the received welcome metadata.

Test Plan:
- cargo fmt --check
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings

Refs: PLAN.md Linux gateway outbound relay connection
2026-05-21 18:06:22 +02:00
ddidderr 956650ea8a feat(relay): filter unsafe Ethernet control traffic
Relay forwarding now applies the MVP L2 safety policy before choosing output
peers. It drops jumbo frames, link-local switch-control destinations, EAPOL,
LLDP, and slow-protocol frames in both directions, and it blocks remote clients
from sending DHCP server replies or IPv6 router advertisements toward the LAN.

The filters live in the room forwarding path so the pure admission/forwarding
tests and live QUIC datagram path share the same policy. Gateway-origin DHCP
server replies remain allowed, which preserves the plan's goal that remote TAP
clients can receive LAN DHCP through the tunnel.

Test Plan:
- cargo fmt --check
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings

Refs: PLAN.md L2 control-plane safety filters
2026-05-21 18:00:11 +02:00
ddidderr 756523927a feat(relay): forward live Ethernet datagrams
The relay now keeps active peer sessions alongside room admission state. After
a successful hello/welcome handshake, the connection enters a datagram loop
and stays registered until the QUIC connection closes.

Incoming datagrams are only considered for forwarding when their overlay room
id, peer id, and Ethernet frame type match the peer assigned by the relay.
The relay then reuses the existing room forwarding decision logic, clones the
matching live target sessions, and sends a relay-stamped Ethernet datagram to
each connected target that can carry the frame.

This keeps spoofable wire metadata out of the trust boundary: clients can put
whatever they want in an overlay header, but the relay forwards using the
room and peer identity established during the control handshake.

Test Plan:
- cargo fmt --check
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings

Refs: PLAN.md QUIC DATAGRAM Ethernet forwarding path
2026-05-21 17:55:58 +02:00
ddidderr b8ae95a911 feat(relay): accept control handshakes
The relay now keeps a shared room registry behind the QUIC endpoint and
runs an accept loop instead of only binding the socket. Each accepted
connection must open its first bidirectional control stream with a hello
frame; the relay joins the room registry and replies with welcome or reject.

Admission clamps the hello datagram budget to Quinn's negotiated peer
datagram size before choosing the effective room MTU, so room state is based
on what the connection can actually carry. Accepted peers remain present
until the QUIC connection closes, then the relay removes them through the
existing leave cleanup path.

The development self-signed certificate helper now exposes the certificate
to tests so a loopback Quinn client can trust the relay and exercise the real
stream codec path.

Test Plan:
- cargo fmt --check
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings

Refs: PLAN.md relay QUIC control-stream startup flow
2026-05-21 17:51:40 +02:00
ddidderr 81ad7abe84 feat(relay): clean up peers on leave
Add explicit room leave semantics for future relay connection tasks. Disconnect
handling will need to remove peers from room membership without reaching into the
room internals or leaving stale MAC indexes behind.

Leaving a client now removes both its peer entry and MAC mapping so the same MAC
can rejoin later. Leaving a gateway clears gateway occupancy while preserving any
remaining clients. If the last peer leaves, the room is removed from the
registry. The result reports which peer left and whether the room was removed so
the networking layer can emit lifecycle events cleanly.

Test Plan:
- cargo fmt --check
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings

Refs: PLAN.md relay disconnect reason and reconnect handling groundwork
2026-05-21 17:41:16 +02:00
ddidderr 77894c4706 feat(relay): bind QUIC endpoint
Make the relay binary bind a real Quinn endpoint instead of only printing its
configuration. This is the next runtime step toward the public relay while still
keeping connection handling out of this commit.

The relay now builds a self-signed development TLS configuration, advertises the
lanparty ALPN, enables QUIC datagram buffers, binds the configured UDP address,
prints the actual local address, and waits for Ctrl-C before closing the
endpoint. The generated certificate is explicitly a development placeholder;
production certificate and client trust handling remain future work.

The rustls dependency is pinned to the ring provider to match Quinn's selected
crypto backend and avoid process-level provider ambiguity at runtime.

Test Plan:
- cargo fmt --check
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings
- timeout 2s cargo run -p lanparty-relay -- --listen 127.0.0.1:0 || test $? -eq 124

Refs: PLAN.md public relay QUIC data path
Refs: https://docs.rs/quinn/0.11.9
2026-05-21 17:38:56 +02:00
ddidderr be9596c188 feat(relay): add runtime CLI config
Replace the placeholder relay binary with a typed command-line configuration
entry point. This gives the future QUIC server loop the listen endpoint and room
limit configuration it needs without mixing command parsing into networking or
room-state code.

The relay now accepts --listen as either a socket address or an explicit UDP
shorthand such as 443/udp, defaults to 0.0.0.0:443/udp, and validates that the
per-room client limit is positive. The binary currently reports the parsed
configuration and clearly states that the QUIC server loop is not wired yet, so
this commit does not pretend to provide a working relay.

Test Plan:
- cargo fmt --check
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings
- cargo run -p lanparty-relay -- --listen 443/udp

Refs: PLAN.md public relay --listen requirement
2026-05-21 17:32:47 +02:00
ddidderr b3d1a9c046 feat(relay): add Ethernet forwarding decisions
Add socket-free relay forwarding logic for Ethernet datagrams. The future QUIC
relay loop can now ask the room registry which peer IDs should receive a frame
instead of embedding switching policy in network IO code.

Forwarding validates that the ingress peer belongs to the room, drops malformed
Ethernet frames, rejects client frames whose source MAC does not match the MAC
announced during admission, never reflects frames back to ingress, routes known
client unicasts directly, and floods broadcast/multicast or unknown unicast
frames to the other room peers. The decision reports shared observability action
and drop-reason values so the networking layer can log consistently.

This still does not send bytes over QUIC; it only defines the room-local switch
decision that the datagram loop will use.

Test Plan:
- cargo fmt --check
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings

Refs: PLAN.md Switching model
2026-05-21 17:28:17 +02:00
ddidderr d1e6530829 feat(relay): add room admission state
Add a tested relay room layer before introducing QUIC socket handling. The relay
now has a focused place to enforce room membership rules instead of mixing those
rules into the future networking loop.

RoomRegistry accepts validated endpoint hellos, assigns room and peer IDs,
returns server welcome data, limits clients per room, permits only one gateway,
rejects duplicate client MACs, and keeps the room TAP MTU stable once the first
peer joins. A later peer must support the existing room MTU rather than silently
shrinking it after an earlier client may already have configured its TAP adapter.

The networking pieces still need to call this layer from the reliable control
stream and use the resulting peer metadata for datagram forwarding.

Test Plan:
- cargo fmt --check
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings

Refs: PLAN.md relay responsibilities and MAC identity
2026-05-21 17:21:46 +02:00
ddidderr 3c395db3df chore: first project structure 2026-05-21 16:55:51 +02:00