fix(gateway): drop unrelated LAN unicast locally

The gateway runs in promiscuous mode so it can capture frames for remote client
MACs, but that also means it sees unrelated unicast traffic between physical
LAN machines. Before this change those frames were sent to the public relay and
only then discarded as unknown destinations.

Use the remote-client table seeded by relay lifecycle events to decide whether
a LAN frame should leave the gateway. Broadcast and multicast traffic still
flows to the relay, and unicast to a connected remote client still flows to the
relay. Unicast to any other destination is counted and logged locally as
UnknownDestination.

This keeps busy LAN traffic out of the relay data path and makes the gateway
behavior match the MVP switching model: LAN frames go to matching remote
clients, while broadcast and multicast fan out.

README.md documents the local filter, and TESTING.md explains why
LanToRemote UnknownDestination can be normal on a busy LAN.

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

Refs: PLAN.md switching model; TESTING.md MVP log signals

This commit is contained in:

ddidderr

2026-05-22 06:18:37 +02:00

parent 566f2d43a8

commit f4ee5b4d2c

3 changed files with 85 additions and 4 deletions

									
										TESTING.md
									
		+4
		
												View File
												
				@@ -208,6 +208,10 @@ drop_reason=DatagramBudget

				drop_reason=RateLimit

				```

				On gateway `LanToRemote` logs, `UnknownDestination` usually means the gateway

				captured unrelated LAN unicast and dropped it locally instead of sending it to

				the relay.

				Drops that should be investigated if they dominate:

				```text