fix(proto): reject reserved overlay flags

The MVP overlay reserves its flags field for later features such as
fragmentation or payload encryption, but version 1 does not define any flag
semantics. Accepting nonzero flags would let unknown behavior silently traverse
the relay and reach the tunnel endpoints.

Make zero the only valid v1 flag value. Overlay encoding and decoding now reject
reserved nonzero flags, production send paths use the explicit
OVERLAY_FLAGS_NONE constant, and the relay emits forwarded datagrams with the
same zero-flag policy instead of preserving peer-supplied bits.

Document the reserved-flag rule in the protocol crate overview.

Test Plan:
- cargo test -p lanparty-proto overlay
- cargo test --workspace
- cargo clippy --workspace --all-targets -- -D warnings
- cargo fmt --check
- git diff --check

Refs: PLAN.md no-fragmentation MVP overlay format
This commit is contained in:
2026-05-22 05:28:52 +02:00
parent 0a97b77ad9
commit da937a50c4
6 changed files with 47 additions and 11 deletions
+4 -2
View File
@@ -8,7 +8,9 @@ use lanparty_ctrl::{
ServerWelcome, decode_control_frame, encode_control_message,
};
use lanparty_obs::{DropReason, FrameDirection, FrameLog, TunnelStats};
use lanparty_proto::{EthernetFrame, FrameType, decode_datagram, encode_datagram};
use lanparty_proto::{
EthernetFrame, FrameType, OVERLAY_FLAGS_NONE, decode_datagram, encode_datagram,
};
use quinn::crypto::rustls::QuicServerConfig;
use quinn::{Endpoint, Incoming, RecvStream, SendStream, ServerConfig, TransportConfig};
use rustls::pki_types::{CertificateDer, PrivateKeyDer, PrivatePkcs8KeyDer};
@@ -424,7 +426,7 @@ async fn forward_peer_datagram(
FrameType::Ethernet,
accepted.welcome.room_id(),
accepted.peer.peer_id(),
header.flags(),
OVERLAY_FLAGS_NONE,
packet.payload(),
)?;
let target_sessions = collect_target_sessions(sessions, &accepted.room, &target_peer_ids).await;