Files
echolot/echolot-app
mrambossekandClaude Opus 5 cfa58e8d60 app: a DNS reply is not a DNS answer
The probe counted any well-formed packet from the server as "the server
answers", checking only the transaction id and a minimum length. REFUSED
and SERVFAIL are well-formed packets. So a server actively refusing this
client would have been reported as healthy, and the finding — whose whole
output is "the network is fine, your device is not" — would have pointed
confidently at the wrong component.

It now requires rcode 0 and at least one record, and reports a refusal as
what it is: a working server saying no, which points back at the network.
The rcode is named rather than numbered, because "REFUSED" is a fact an
operator can act on and "rcode 5" is a lookup.

Caught by decoding what fmr's router actually replied — ab cd 81 80 00 01
00 02, NOERROR with two answers — after realising the earlier check only
counted bytes. The reply was genuinely good, so the finding on the tablet
stands; the check was wrong regardless.

The advice is broader too. That tablet's fault survived a reboot, which
makes "toggle wifi and it clears" wrong as a flat claim: it now says what
to look at when a restart does not fix it — something on the device
filtering DNS, or a per-client rule on the router.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-02 10:10:36 +02:00
..
2026-08-02 10:10:36 +02:00

Echolot app

The production Android client (spec). Native Kotlin + Jetpack Compose. Multi-module; built bottom-up from a verifiable protocol spine.

Modules

Module Type Status
core-protocol pure Kotlin/JVM done — client half of probe-protocol.md, verified live against the server
core-measurement pure Kotlin/JVM planned — measurement-schema.md types
core-probe Android lib planned — app-tier probes, ported from echolot-prober
core-shizuku Android lib planned — dual-path executor (UserService + newProcess fallback)
app Android app planned — Compose UI

core-protocol is deliberately Android-free so it builds and unit-tests on any JDK (no Android SDK) and can run integration tests against a live server.

core-protocol

Implements the control plane (SPKI-pinned enrollment/profile/sessions via HttpsURLConnection — Android-API-1 compatible, hostname verification off because trust is the pin), the HKDF-SHA256 session-key schedule, and the binary ELT1 UDP data plane (HMAC gate, ECHO + observation block, MTU probe) — byte-compatible with the Go server.

./gradlew :core-protocol:test              # unit tests (crypto vectors, wire round-trip)
scripts/test-fmr.sh                         # live end-to-end test against the deployed server

test-fmr.sh mints an enrollment token over SSH, enrolls via the public control plane, computes the SPKI pin from the served cert, and runs LiveServerTest — proving the client speaks the wire protocol to the real server (enroll → profile → session → echo+observation → MTU → observations). The live test self-skips when ECHOLOT_LIVE_* env vars are absent, so unit runs and CI stay green offline.