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:
+42
@@ -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,
|
||||
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
|
||||
|
||||
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`.
|
||||
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
|
||||
|
||||
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
|
||||
```
|
||||
|
||||
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 gateway usually needs root because it opens an AF_PACKET raw socket.
|
||||
|
||||
@@ -214,6 +254,7 @@ Connected to LAN gateway
|
||||
|
||||
```powershell
|
||||
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.
|
||||
@@ -395,3 +436,4 @@ For a useful test report, capture:
|
||||
- switch MAC-table entry for the Windows client MAC
|
||||
- LAN game discovery or join result
|
||||
- lifecycle sanity-check result
|
||||
- whether the relay route pin was `(created)` or `(already existed)`
|
||||
|
||||
Reference in New Issue
Block a user