docs: tighten MVP test guide

Make the manual MVP proof easier to run without adding product fluff. Add a
short fast path, explicit log-capture commands, the expected release binary
paths, an extra Windows route-table check, and the relay-route pin disposition
to the report-back checklist.

The test guide remains centered on the real acceptance criteria: DHCP over the
TAP tunnel, TAP-sourced ping to a LAN host, switch MAC learning on the gateway
port, LAN-game discovery or join, and a gateway restart sanity check.

Test Plan:
- git diff --check
- git diff --cached --check

Refs: MVP E2E handoff
This commit is contained in:
2026-05-22 08:22:45 +02:00
parent f82b658e3c
commit 1a98b8c4a7
+42
View File
@@ -9,6 +9,19 @@ Windows TAP client -> public QUIC relay -> Linux AF_PACKET gateway -> LAN
The MVP is intentionally manual. It does not include an installer, GUI, The MVP is intentionally manual. It does not include an installer, GUI,
production certificates, auth, or end-to-end payload encryption. production certificates, auth, or end-to-end payload encryption.
## Fast Path
Run the test in this order:
1. Build the relay and gateway on Linux, and build the Windows client on
Windows.
2. Start the relay and keep `relay-cert.der`.
3. Copy `relay-cert.der` to the gateway and Windows client.
4. Start the Linux gateway on the wired LAN interface.
5. Start the Windows client from an elevated terminal.
6. Verify DHCP, `ping -S`, switch MAC learning, and one LAN game.
7. Restart the gateway once while the client stays up.
## MVP Pass Conditions ## MVP Pass Conditions
The MVP proof is successful when all of these are true: The MVP proof is successful when all of these are true:
@@ -48,6 +61,25 @@ Windows TAP IPv4:
Use the same room code everywhere, for example `ROOM1`. Use the same room code everywhere, for example `ROOM1`.
Start order is relay first, gateway second, Windows client last. Start order is relay first, gateway second, Windows client last.
## Log Capture
Keep one log per process. They are the easiest way to diagnose a failed run.
On Linux:
```bash
./target/release/lanparty-relay ... 2>&1 | tee relay.log
sudo ./target/release/lanparty-gateway ... 2>&1 | tee gateway.log
```
On Windows PowerShell:
```powershell
Start-Transcript .\client.log
.\target\release\lanparty-client-win.exe ...
Stop-Transcript
```
## Build Prerequisites ## Build Prerequisites
On Windows, use the Rust MSVC toolchain and install Visual Studio Build Tools On Windows, use the Rust MSVC toolchain and install Visual Studio Build Tools
@@ -79,6 +111,14 @@ On Windows, in an Administrator terminal:
cargo build --release -p lanparty-client-win cargo build --release -p lanparty-client-win
``` ```
The binaries used below are:
```text
Linux: ./target/release/lanparty-relay
Linux: ./target/release/lanparty-gateway
Windows: .\target\release\lanparty-client-win.exe
```
The Windows client must run elevated because it opens TAP and edits routes. The Windows client must run elevated because it opens TAP and edits routes.
The gateway usually needs root because it opens an AF_PACKET raw socket. The gateway usually needs root because it opens an AF_PACKET raw socket.
@@ -214,6 +254,7 @@ Connected to LAN gateway
```powershell ```powershell
Get-NetIPAddress | ? InterfaceAlias -like "*TAP*" Get-NetIPAddress | ? InterfaceAlias -like "*TAP*"
Get-NetRoute | ? InterfaceAlias -like "*TAP*" | ft -AutoSize
``` ```
Use the non-link-local IPv4 address as `<tap-ip>` in the next step. Use the non-link-local IPv4 address as `<tap-ip>` in the next step.
@@ -395,3 +436,4 @@ For a useful test report, capture:
- switch MAC-table entry for the Windows client MAC - switch MAC-table entry for the Windows client MAC
- LAN game discovery or join result - LAN game discovery or join result
- lifecycle sanity-check result - lifecycle sanity-check result
- whether the relay route pin was `(created)` or `(already existed)`