Adds a tiny built-in probe (ttl_probe) that measures the hop distance to the
server, so the TTL-desync decoys are aimed automatically instead of by a
hand-guessed number — without pulling in the whole ostp-prober and without any
new server endpoint or exposed port.
How it works, and why it needs no prober-server: the OSTP server answers only a
valid handshake and silently drops everything else, so the client sends the real
handshake with a rising IP TTL and watches for the first TTL that draws a reply.
Datagrams whose TTL is too low die on a router before the server and create no
state there; the first responding TTL is the server distance. Decoys are then
stamped at hops-1, so they clear the DPI (which sits far closer than the server)
yet expire before the server. This is inherently key-gated — no key, no valid
handshake, no reply, so an unauthenticated caller learns nothing — and rides the
existing UDP port, which is exactly the "works for key holders, no prober-server,
no ports exposed to the internet" property that was asked for.
Config: transport.ttl_desync_auto (on by default). When on and desync is
enabled, the measured value overrides ttl_desync_ttl; measurement runs once and
is cached, cleared on a config change. On measurement failure it falls back to
the configured fixed TTL rather than skipping desync. The whole path is gated
behind ttl_desync (off by default), so a normal connection never runs it.
The probe logic is unit-tested (measures against a local responder; decoy-TTL
math). The real hop measurement and the desync effect both need a real network
to confirm and cannot be exercised here.
- fix(cli): stop printing the startup banner ("ostp-cli vX.Y.Z | OS: ...")
to stderr on every single command invocation. init_tracing() ran
unconditionally before command dispatch, so `ostp -V`, `ostp gk`, etc. all
showed it. It's still written to the log file (useful there), just no
longer echoed via the stderr tracing layer for one-shot commands.
- feat(client): add ostp-client::migrate, the ONE place config migration
runs. Previously there were three uncoordinated migration paths: a Python
snippet embedded in scripts/install.sh (only touched server api.* fields,
ran on every update), the old 0.3.x line's auto-migration on every hot
reload (silent besides a log warning), and nothing at all for the current
rebuild. Consolidated into one module covering every config shape that's
actually existed:
- v0.3.1-v0.3.21 modular (inbounds/outbounds/routing) -> current flat
schema, including correctly resolving routing.default_outbound through
a urltest/selector group to the real server, and reporting (not
silently dropping) every additional server a multi-server config had.
- pre-0.3.1 flat configs carrying now-dead fields (tun.wintun_path,
tun.ipv4_address, transport.wss) -> dropped with an explicit reason,
everything else passes through untouched.
- server configs -> backfills api.* defaults and drops legacy api.token
(ported straight from the install.sh Python, same behavior, correct
place).
6 unit tests cover all of the above against realistic fixtures. Wired up
as `ostp migrate` (was missing from Commands entirely) — no other code
path calls into this module, so a config's shape only ever changes when
explicitly asked.
- feat(cli): `ostp import <url>` now asks the same TUN/mux/debug questions
`ostp connect <url>` always did. Previously import just wrote flat
defaults to disk with no way to turn any of that on short of hand-editing
the resulting config.json afterward. Extracted the shared prompt into
prompt_client_options() so both paths stay in sync.
- chore(install): remove the embedded Python config-migration snippet from
install.sh; schema migration must never happen implicitly during an
install/update. Points users at `ostp migrate` instead.
ospab
ospab