ddidderr/softlan-vpn
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

justfile, AGENTS.md

Browse Source
This commit is contained in:
ddidderr
2026-08-16 10:36:27 +02:00
parent a66ea31ab3
commit 16d0886f36
8 changed files with 321 additions and 213 deletions
Download Patch File Download Diff File Expand all files Collapse all files
TESTING.md
+24 -25
View File
@@ -58,8 +58,8 @@ Windows TAP IPv4:
- Gateway: Linux machine plugged into the LAN party switch with wired Ethernet.
- Client: Windows 11 machine with TAP-Windows6 installed.
Use the same room code everywhere, for example `ROOM1`.
Start order is relay first, gateway second, Windows client last.
Use the same room code everywhere, for example `ROOM1`. Start order is relay
first, gateway second, Windows client last.
## Log Capture
@@ -153,8 +153,8 @@ 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.
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.
## Start The Relay
@@ -196,8 +196,8 @@ sudo ./target/release/lanparty-gateway \
```
Use the real wired LAN interface name for `--interface`. `--iface` is accepted
as a shorter alias. Do not use Wi-Fi. The gateway fails before joining the
relay if sysfs reports no Ethernet carrier.
as a shorter alias. Do not use Wi-Fi. The gateway fails before joining the relay
if sysfs reports no Ethernet carrier.
Expected gateway output:
@@ -245,7 +245,8 @@ one explicitly:
Expected client output:
```text
prepared TAP adapter ... MAC ... configured and media disconnected before relay connect
prepared TAP adapter ... MAC ... configured and media disconnected before relay
connect
relay route pinned before TAP ...
relay route verified before TAP activation ...
lanparty-client-win connecting virtual MAC ... to relay ... room ROOM1
@@ -261,11 +262,10 @@ relay event: LAN gateway connected as peer ...
The route pin line ends with `(created)` or `(already existed)`. Either is OK.
`already existed` usually means a matching relay host route was already present,
for example after a previous crashed test run.
You may also see TAP IPv4/IPv6 MTU, metric, and default-route protection lines
between the connect and TAP-open lines. Those are expected.
The lifecycle event may appear after the bridge starts because event logging
begins once TAP and route protection are ready.
for example after a previous crashed test run. You may also see TAP IPv4/IPv6
MTU, metric, and default-route protection lines between the connect and TAP-open
lines. Those are expected. The lifecycle event may appear after the bridge
starts because event logging begins once TAP and route protection are ready.
The first diagnostics line may show `IP unknown`. After DHCP succeeds, a later
line should show:
@@ -274,8 +274,8 @@ line should show:
DHCP received: 10.x.x.x
```
If Windows reports both a `169.254.x.x` TAP address and a real LAN IPv4
address, the client diagnostics should prefer the real LAN address.
If Windows reports both a `169.254.x.x` TAP address and a real LAN IPv4 address,
the client diagnostics should prefer the real LAN address.
## Verify The Tunnel
@@ -395,10 +395,9 @@ 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.
`TapMtuExceeded` means a host emitted an Ethernet frame larger than the
negotiated tunnel MTU; occasional drops can happen while testing software that
does not honor the smaller adapter MTU yet.
the relay. `TapMtuExceeded` means a host emitted an Ethernet frame larger than
the negotiated tunnel MTU; occasional drops can happen while testing software
that does not honor the smaller adapter MTU yet.
Drops that should be investigated if they dominate:
@@ -414,8 +413,8 @@ drop_reason=Ipv6Fragment
```
On gateway `RemoteToLan` logs, `UnauthorizedSourceMac` means the relayed peer id
did not match the client MAC announced by lifecycle events. If it repeats,
check relay lifecycle logs and duplicate-MAC rejection first.
did not match the client MAC announced by lifecycle events. If it repeats, check
relay lifecycle logs and duplicate-MAC rejection first.
## Troubleshooting
@@ -454,11 +453,11 @@ If ping fails but DHCP worked, check Windows firewall, the target LAN host
firewall, and whether the LAN subnet conflicts with the client's home LAN.
Uncommon LAN subnets such as `10.73.42.0/24` are safer than `192.168.0.0/24`.
If switch MAC learning does not show the Windows client MAC on the gateway
port, look for `gateway CAM refresh ... reason=peer_joined` immediately after
join and `gateway CAM refresh ... reason=periodic` about once per minute after
that. If those lines are present but the switch still does not learn it, check
the selected gateway interface and switch port first.
If switch MAC learning does not show the Windows client MAC on the gateway port,
look for `gateway CAM refresh ... reason=peer_joined` immediately after join and
`gateway CAM refresh ... reason=periodic` about once per minute after that. If
those lines are present but the switch still does not learn it, check the
selected gateway interface and switch port first.
## Cleanup