3 Commits

Include renames

Author	SHA1	Message	Date
mrambossekandClaude Fable 5	ad85f3bfcd	enrollment: the server mints the §2.1 bootstrap link, the app consumes it ... POST /admin/enroll-tokens now returns the whole link, not just the token: echolot://enroll?v=1&u=<control URL>&p=pin-sha256:<b64>&t=<token> The server is the only party that knows all three parts at once, and the part an operator gets wrong by hand is the base64 pin — which does not fail loudly, it just never matches, surfacing days later as an inscrutable TLS error. The app takes the link from a paste or from an echolot:// deep link (QR scan), and writes URL, pin and credential together or not at all. One trap the tests pin: an unencoded "+" in a query string decodes to a space, so a hand-assembled link arrives with a pin wrong by one character. Base64 has no spaces, so they are restored — unambiguous, and it cannot damage a correctly encoded pin. Also fixes a spec divergence: §2.1 names the field device_credential and the first implementation shipped "credential". Both are sent now and the client prefers the spec's; the alias goes once nothing reads it. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-08-01 12:06:22 +02:00
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	49c6197aff	app: core-engine — run engine; full server-facing vertical proven vs fmr ... Composes core-protocol probes into core-measurement documents. Injected clock/UUID source keeps it pure and unit-testable. Runs a server ECHO train and derives RTT distribution, loss, and NAT-rebinding detection (from the server's observed source port) as train.udp_updown, then findings + a §7.3 summary. Verified end-to-end against fmr: 20-packet train, 0% loss, RTT 1.7/2.5/6.9ms, no rebinding → valid MeasurementDocument (2.3kB), overall GREEN. The whole server-facing stack (protocol → engine → schema → verdict) now produces the real product artifact against the live server, no device required. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-31 21:28:09 +02:00