2 Commits

Include renames

Author	SHA1	Message	Date
mrambossekandClaude Fable 5	ce1aaa332a	server: send granted traffic from the address the session actually used ... fmr binds two IPv4 addresses. connFor picked whichever socket of the right family came first in the bind list, so a downtrain for a session established on .150 went out from .151 — and every packet was dropped by the client's NAT, which has no mapping for that pair. tcpdump on the server showed all 50 leaving; the client saw none. Read as "100% downstream loss", which is the worst kind of wrong: a confident measurement of something that never happened. Sessions now record which of our own bound addresses received their traffic, and granted sends (and delayed echo) go back out through that socket. The fallback to a family match is kept for the case where nothing has been received yet, and the test pins both paths — a single-homed lab can never reproduce this. Also: the client-side halves of the same work — anonymizer (core-privacy), local run archive with retention (core-archive), upload client, and the app's settings and history screens. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-01 10:45:43 +02:00
mrambossekandClaude Opus 5	4ae744aae5	server: self-test — sysctl audit + egress-MTU self-proof ("server proven good") ... A measurement server must prove its own host isn't distorting results: - sysctl audit (/proc/sys): flags accept_ra on a static host, ICMP redirects, ICMP rate-limiting of the server's own errors, and disabled TCP options — each a measurement-fidelity hazard, with the "why". - egress-MTU self-proof: DF PMTUD probe (IP_MTU_DISCOVER + getsockopt IP_MTU, no root — Linux-only, stub elsewhere) to external anchors. If the server's own uplink is below 1500, client MTU tests measure THIS server, so we say so. Exposed at GET /admin/selftest (full report) and as server_selftest {mtu_ok, sysctl_ok} in the profile so clients can trust or skip MTU tests. Recommended deploy/99-echolot-sysctl.conf + README section. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-31 20:44:38 +02:00