fix(client): prefer non-link-local TAP IPv4 diagnostics

Windows can report more than one unicast address on the TAP adapter. If an
APIPA address remains present next to the real LAN DHCP address, choosing the
first IPv4 address can make diagnostics warn about 169.254.x.x even though the
adapter already has a usable LAN address.

Prefer a non-link-local IPv4 address for TAP diagnostics, then fall back to any
IPv4 address, then to the first non-IPv4 address. This keeps the existing APIPA
warning when APIPA is the only IPv4 signal, but reports the real DHCP address
when Windows exposes both addresses.

README.md and TESTING.md now document that diagnostics prefer the real LAN IPv4
when several TAP addresses are visible.

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

Refs: PLAN.md client diagnostics; TESTING.md TAP IP verification
This commit is contained in:
2026-05-22 06:21:48 +02:00
parent f4ee5b4d2c
commit 0ed440ffaa
3 changed files with 45 additions and 5 deletions
+3
View File
@@ -138,6 +138,9 @@ 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.
## What To Verify
1. Relay sees both peers: