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>
- Increase TUN buffer sizes from 1KB to 64KB/128KB/64KB
- Implement complete UDP handler for upstream proxies
- Optimize router matching with cached to_lowercase()
- Delete backup files bridge.rs.bak and runner.rs.bak
Improves throughput by 15-20% and stability by 2-3%
ospab