The helper logged "exiting" but never terminated: the WinTun blocking
receive runs on a thread that task.abort() cannot cancel, so it kept the
ostp_tun adapter (and its metric-0 default route) alive and hung the tokio
runtime as a zombie. The next connect then faced two competing default
routes and failed to install the per-server /32 bypass, so the client's own
handshake packets looped back into the dead tunnel — every OSTP handshake
timed out and there was no internet.
- ostp-tun-helper: std::process::exit(0) after run_server returns so the
kernel reclaims the adapter and all routes bound to it.
- ostp-tun/windows_route: dedupe bypass IPs, purge any stale /32 for the
dest before adding (enumerate + delete), and log add failures at warn!
instead of debug! so the cause is visible in the INFO-level helper log.
- ostp-tun/windows: keep .destination() LUID default route (reliable
capture) alongside the racy friendly-name route; retry create() through
the transient ERROR_INVALID_PARAMETER window.
- ostp-client: wire BridgeMetrics.connection_state through runner and
inbounds so the GUI reflects connecting/connected/disconnected.
- ostp-gui: parse JSONC config (strip // and /* */) in the settings view.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Log::message is deserialized from the IPC stream but not acted on
(informational variant, GUI shows it via the tray). HelperState::port
is stored for potential reconnection but not read back after initial
connection. Both are correctly annotated with #[allow(dead_code)].
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
tun-helper: the GUI encrypts all IPC commands with ChaCha20Poly1305 and
sends them as hex, but the helper was reading plain JSON — every command
was silently dropped and the tunnel core was never started. Fix by:
- Moving IpcCrypto + derive_key into ostp-client/src/ipc_crypto.rs as a
shared module so GUI and helper always use identical crypto logic.
- Rewriting tun-helper/src/main.rs to hex-decode and decrypt every
incoming line before JSON-parsing, and to encrypt + hex-encode every
outgoing HelperMsg before sending.
- Replacing the custom log_to_file() helper with tracing::info/warn/error
so all helper output goes through the standard tracing pipeline.
- Adding tracing and hex to ostp-tun-helper Cargo.toml; dropping chrono
(no longer needed after removing log_to_file).
logging: unify output format across all OSTP binaries to match the
standard tracing-subscriber style:
2026-06-21T19:11:18.643226Z INFO ostp_server: message
- Enable the `time` feature in tracing-subscriber and set UTC RFC-3339
timer on both file and stderr layers in init_tracing.
- Remove with_line_number(true) — line numbers are not part of the
desired format and bloat the target field.
- Replace println! in runner.rs with tracing::info!.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Add IPC encryption using ChaCha20Poly1305
- Reduce helper connection timeout from 60s to 15s
- Replace unwrap() with proper error handling in helper connection
- Encrypt all messages between GUI and helper with derived key
- Add ipc_crypto module for secure communication
- Properly decode/encode encrypted messages in IPC loop
When using xhttp (UoT) mode on Android, the underlying TcpStream was
not protected with VpnService.protect(fd). This caused the TCP connection
to be routed back into the TUN interface, creating an infinite routing
loop and failing the connection immediately.
Added Android-specific socket protection to the TcpStream in connect_xhttp.
This fixes xhttp/UoT mode on mobile networks.
The core bug: server sent 5 TLS records in server_hello but client only
read the first one (ServerHello), then passed remaining bytes (CCS + fake
records) into RealityStream. RealityStream saw 0x14 (CCS) != 0x17 and
immediately returned an error, killing the connection.
Changes:
- reality.rs: append ChangeCipherSpec after ClientHello (RFC 8446 D.4)
export REALITY_SERVER_HANDSHAKE_RECORDS=5 constant
- xhttp.rs: drain all 5 server handshake records before creating RealityStream
- uot.rs: rebuild server_hello as proper 5-record TLS 1.3 flight:
ServerHello + CCS + fake EE (108B) + fake Cert (812B) + fake Fin (52B)
drain client CCS from raw stream before wrapping in RealityStream
ospab