fix: v1.9.9 — Android second disconnect crash + tunnel-node drain correctness

Android (#700 from @ilok67):
- Reordered MhrvVpnService.teardown() to call Native.stopProxy() FIRST. The previous order (tun2proxy.stop → tun.close → join → stopProxy) crashed SIGSEGV ~2s after Disconnect: tun2proxy's worker thread was blocked in native code on a SOCKS5 socket read; after the 2s+4s timeouts expired with the worker still alive, Native.stopProxy freed the runtime including that socket, and the worker hit use-after-free in the next read. The old comment claimed "runtime shutdown will knock the rest of the world over" — wrong, Native.stopProxy can't forcibly terminate a separate native thread, it just frees memory the other thread is still using. New order closes the socket first, the worker's blocking read returns with EOF, the worker exits cleanly through its error path, and the join is then near-instant.

tunnel-node (PR #695 from @dazzling-no-more, merged):
- Cleanup now tracks eof'd sids from drain_now's return value, not the raw atomic — was silently dropping the tail on >16 MiB buffers when EOF arrived between polls.
- Phase-1 `data` op no longer holds the sessions map across upstream write/flush — was head-of-line-blocking every other batch op.
- Mixed TCP+UDP batch wait switched from tokio::join! to tokio::select! — was paying the UDP LONGPOLL_DEADLINE (15 s) on TCP-ready bursts.
- Watcher tasks now wrapped in AbortOnDrop newtype — was leaking Arc<Inner> permits when select!'s loser arm dropped its future.
- 2 new regression tests, 35/35 pass.

Example configs:
- config.exit-node.example.json: added aistudio.google.com + ai.google.dev to default hosts (#701 — AI Studio sanctions Iran IPs).
- config.fronting-groups.example.json: PR #696 from @Shjpr9 added Reddit/Fastly/Pinterest/CNN/BuzzFeed family domains on the Fastly 151.101.x.x edge.

Tests: 179 lib + 35 tunnel-node green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: therealaleph

Cargo.lock

@@ -1,6 +1,6 @@
 [package]
 name = "mhrv-rs"
-version = "1.9.8"
+version = "1.9.9"
 edition = "2021"
 description = "Rust port of MasterHttpRelayVPN -- DPI bypass via Google Apps Script relay with domain fronting"
 license = "MIT"

Cargo.toml

@@ -332,19 +332,37 @@ class MhrvVpnService : VpnService() {
      *
      * Steps, with the bound on each one called out so a hung native call
      * cannot stall the whole teardown thread:
-     *   1. Signal tun2proxy to stop (cooperative). Bounded by a 2s
-     *      side-thread join — if the JNI call hangs we proceed anyway.
-     *   2. Drop our `ParcelFileDescriptor` reference. Because we already
+     *   1. Shut down the Rust proxy FIRST. This closes the listening
+     *      SOCKS5 socket that tun2proxy's worker thread is blocked on
+     *      a read() from. Killing the upstream socket is what makes the
+     *      worker's blocking native call return — we have no other lever
+     *      to wake it. Bounded by `rt.shutdown_timeout(3s)` Rust-side.
+     *   2. Signal tun2proxy to stop (cooperative). Mostly redundant after
+     *      step 1, but cheap and covers the rare path where the worker is
+     *      blocked on something other than its socket read (e.g. a
+     *      smoltcp internal queue waiting on a wake). Bounded by a 2s
+     *      side-thread join.
+     *   3. Drop our `ParcelFileDescriptor` reference. Because we already
      *      called detachFd() at startup, this is a no-op for the
      *      underlying fd — the worker (closeFdOnDrop=true) owns it.
      *      We keep the call only so the PROXY_ONLY / failed-establish
      *      paths still null out the field cleanly.
-     *   3. Join the tun2proxy thread, bounded at 4s. If the worker is
-     *      stuck we log and move on — the runtime shutdown below will
-     *      knock the rest of the world over.
-     *   4. Shut down the Rust proxy runtime, bounded by `rt.shutdown_timeout`
-     *      on the Rust side (5s). This is the hard backstop: the listener
-     *      socket is released here regardless of what the worker is doing.
+     *   4. Join the tun2proxy thread, bounded at 4s. With step 1 having
+     *      already closed the socket the worker was reading from, this
+     *      join almost always completes well under the deadline.
+     *
+     * History (#700 from @ilok67): the original order was
+     * tun2proxy → tun.close → join → stopProxy. That ordering crashed
+     * SIGSEGV ~2s after Disconnect because Native.stopProxy() freed the
+     * Rust runtime (including the SOCKS5 listener) while tun2proxy's
+     * worker was still in a blocking native read against it — classic
+     * use-after-free. The previous comment claimed "the runtime shutdown
+     * below will knock the rest of the world over," but Native.stopProxy
+     * cannot forcibly terminate a separate native thread; it just frees
+     * memory the other thread is still using. Reversing the order means
+     * the worker's blocking read returns with an EOF / socket-closed
+     * error, the worker exits through its own error path, and the join
+     * is effectively just confirming a clean shutdown.
      */
     private fun teardown() {
         // Idempotency guard. Without this, onDestroy racing the
@@ -363,11 +381,24 @@ class MhrvVpnService : VpnService() {
             "(tun2proxy running=${tun2proxyRunning.get()}, proxyHandle=$proxyHandle)",
         )
 
-        // 1. Cooperative stop signal — bounded so a hung Rust call cannot
-        //    stall the entire teardown thread. We've never observed
-        //    Tun2proxy.stop() block in practice, but the contract isn't
-        //    documented as bounded and the rest of teardown already takes
-        //    care to be timeout-bounded; this closes the gap.
+        // 1. Stop the Rust proxy FIRST. Closing the SOCKS5 listener is
+        //    what makes tun2proxy's worker thread's blocking read return
+        //    — without this the worker stays in native code and a later
+        //    Native.stopProxy would race it into use-after-free (#700).
+        val handle = proxyHandle
+        proxyHandle = 0L
+        if (handle != 0L) {
+            Log.i(TAG, "teardown: stopping proxy handle=$handle")
+            try { Native.stopProxy(handle) } catch (t: Throwable) {
+                Log.e(TAG, "Native.stopProxy threw: ${t.message}", t)
+            }
+        }
+
+        // 2. Cooperative stop signal — mostly redundant now that step 1
+        //    has yanked the socket out from under the worker, but cheap
+        //    and covers any future code path where the worker might be
+        //    blocked on something other than its upstream socket read.
+        //    Bounded so a hung JNI call can't stall teardown.
         if (tun2proxyRunning.get()) {
             val stopper = Thread({
                 try { Tun2proxy.stop() } catch (t: Throwable) {
@@ -380,7 +411,7 @@ class MhrvVpnService : VpnService() {
             }
         }
 
-        // 2. Drop our PFD reference. detachFd at startup means this
+        // 3. Drop our PFD reference. detachFd at startup means this
         //    close() is a no-op for the underlying fd — tun2proxy owns
         //    it (closeFdOnDrop = true) and closes it on return from
         //    run(). The call is kept only to null the field cleanly on
@@ -391,9 +422,9 @@ class MhrvVpnService : VpnService() {
         }
         tun = null
 
-        // 3. Join the worker. 4s is enough in the happy case; if tun2proxy
-        //    is stuck on something untoward we'd rather move on and force
-        //    the runtime shutdown than hang forever.
+        // 4. Join the worker. With step 1 having killed its upstream this
+        //    almost always completes immediately; the 4s budget is just
+        //    headroom for tun2proxy's internal close path to drain.
         try {
             tun2proxyThread?.join(4_000)
         } catch (_: InterruptedException) {}
@@ -403,18 +434,6 @@ class MhrvVpnService : VpnService() {
             Log.w(TAG, "tun2proxy thread still alive after join timeout — proceeding anyway")
         }
 
-        // 4. Shut down the Rust proxy. Backed by `rt.shutdown_timeout(3s)`
-        //    on the Rust side, so this is bounded even if the runtime
-        //    has in-flight tasks (common when the Apps Script relay has
-        //    piled up pending 30s timeouts).
-        val handle = proxyHandle
-        proxyHandle = 0L
-        if (handle != 0L) {
-            Log.i(TAG, "teardown: stopping proxy handle=$handle")
-            try { Native.stopProxy(handle) } catch (t: Throwable) {
-                Log.e(TAG, "Native.stopProxy threw: ${t.message}", t)
-            }
-        }
         // Flip UI state last — the button reverts to Connect only after
         // the native-side cleanup actually happened, not optimistically.
         VpnState.setProxyHandle(0L)

android/app/src/main/java/com/therealaleph/mhrv/MhrvVpnService.kt

@@ -27,7 +27,9 @@
       "claude.ai",
       "x.com",
       "grok.com",
-      "openai.com"
+      "openai.com",
+      "aistudio.google.com",
+      "ai.google.dev"
     ]
   }
 }

config.exit-node.example.json

@@ -0,0 +1,22 @@
+<!-- see docs/changelog/v1.1.0.md for the file format: Persian, then `---`, then English. -->
+• Fix v1.9.8 Android: کرش جدید ~۲ ثانیه بعد از Disconnect ([#700](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/issues/700) از @ilok67 با root cause + fix کامل): علی‌رغم fix v1.9.8 برای race lifecycle (#666)، crash جداگانه در `MhrvVpnService.teardown()` باقی مانده بود. ترتیب قبلی: tun2proxy.stop → tun.close → join → Native.stopProxy. مشکل: tun2proxy worker thread در native code blocked روی socket read از SOCKS5 proxy است. وقتی Tun2proxy.stop کالد می‌شه + 2s timeout می‌گذره + 4s join timeout می‌گذره (worker هنوز alive)، Native.stopProxy runtime Rust رو shutdown می‌کنه شامل listener socket — worker thread که در native blocking read از همان socket است → use-after-free → SIGSEGV. comment کد قدیمی ادعا می‌کرد "runtime shutdown will knock the rest of the world over" که اشتباه بود — Native.stopProxy نمی‌تونه force-terminate یک thread native دیگه. ترتیب جدید: **Native.stopProxy اول** (socket رو می‌بنده → blocking read worker با error برمی‌گرده → worker پاک exit می‌کنه از error path)، بعد Tun2proxy.stop (cooperative، redundant ولی ارزان) → tun.close → join (تقریباً همیشه فوری چون worker از قبل تموم شده). تشکر بیشتر از @ilok67 برای triage دقیق دومین crash.
+• Fix tunnel-node batch drain correctness + lock contention (PR [#695](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/pull/695) از @dazzling-no-more): چهار باگ، دو correctness، دو latency.
+  - **Cleanup race tail-bytes drop می‌کرد:** session با buffer > ۱۶ MiB + EOF — `drain_now` صحیح `eof=false` برمی‌گردوند تا tail tail رو در poll بعدی drain کنه، ولی cleanup loop همان atomic رو می‌خوند، `true` می‌دید + session رو حذف می‌کرد + `reader_task` رو abort + tail هدر می‌رفت. حالا cleanup از مقدار return `drain_now` پیروی می‌کنه — session فقط بعد از shipped شدن drain که `eof=true` می‌فرسته، حذف می‌شه. data loss silent در 1Gbps+ VPS که buffer بین poll‌ها پر می‌شد، fix شد.
+  - **Sessions-map lock روی upstream await نگه می‌داشت:** phase-1 `data` op global sessions map رو نگه می‌داشت روی `last_active.lock`، `writer.lock`، `write_all`، و `flush` — head-of-line-block برای هر batch + connect/close op دیگه. حالا (مثل `udp_data` که قبلاً درست بود) Arc از under map clone می‌شه، lock drop، بعد write/flush.
+  - **TCP+UDP batch deadline UDP رو می‌پرداخت:** `tokio::join!(wait_tcp, wait_udp)` conjunctive هست — TCP-ready burst هنوز LONGPOLL_DEADLINE 15 ثانیه‌ای UDP رو می‌پرداخت قبل از پاسخ. comment می‌گفت "either side"، code "both sides" انجام می‌داد. تغییر به `select!`. test جدید `batch_tcp_ready_does_not_pay_udp_longpoll_deadline` این رد رو حفظ می‌کنه.
+  - **Watcher tasks تحت `select!` cancellation leak می‌کرد:** `wait_for_any_drainable` فقط در trailing loop watcher‌ها رو abort می‌کرد — past همه cancel point‌ها. با تبدیل phase-2 wait به `select!`، loser arm's future drop می‌شه و watcher‌هاش *detach* می‌شن (drop کردن `JoinHandle` abort نمی‌کنه). هر orphan یک `Arc<...Inner>` نگه می‌داشت + می‌توانست `notify_one()` permit از batch بعدی بدزده. fix: `AbortOnDrop` newtype روی همه `JoinHandle` watcher.
+  ۲ test جدید + 35/35 pass.
+• Example config exit-node با `aistudio.google.com` و `ai.google.dev` — درخواست از [#701](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/issues/701). AI Studio روی Iran IP sanction می‌خوره (نه Apps Script طرف ما). exit-node IP val.town رو می‌بینه که نه Iran است نه Google datacenter.
+• Example config fronting-groups با Reddit / Fastly / Pinterest / CNN / BuzzFeed family domains اضافه شد (PR [#696](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/pull/696) از @Shjpr9). همه روی Fastly Anycast 151.101.x.x — کاربران می‌تونن از example بیشتر دامنه برداشت کنن، اونی که در شبکه‌شان کار می‌کنه نگه دارن.
+• تست: ۱۷۹ lib + ۳۵ tunnel-node test همه pass.
+---
+• Fix Android `~2-second-delayed` crash on Disconnect from v1.9.8 ([#700](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/issues/700) by @ilok67 with full root cause + fix): despite the v1.9.8 fix for the lifecycle race (#666), a separate crash inside `MhrvVpnService.teardown()` remained. Old order was tun2proxy.stop → tun.close → join → Native.stopProxy. Problem: tun2proxy's worker thread is blocked in native code on a socket read from the proxy's SOCKS5 port. After `Tun2proxy.stop()`'s 2s timeout and the 4s thread join both expire (worker still alive), `Native.stopProxy()` shuts down the Rust runtime — including the listener socket — and the worker, still reading from that socket in native code, hits use-after-free → SIGSEGV. The old code comment claimed "the runtime shutdown will knock the rest of the world over," which was wrong: `Native.stopProxy` cannot forcibly terminate a separate native thread. New order: **`Native.stopProxy` FIRST** (closes the socket → worker's blocking read returns with EOF/error → worker exits cleanly through its error path), then `Tun2proxy.stop` (cooperative, mostly redundant but cheap), `tun.close`, then `join` (almost always immediate now). Thanks @ilok67 again for the precise root-cause work on the second crash.
+• Fix tunnel-node batch drain correctness + lock contention (PR [#695](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/pull/695) from @dazzling-no-more): four bugs, two correctness + two latency.
+  - **Cleanup race dropped tail bytes:** when a session's read buffer > 16 MiB and upstream signaled EOF, `drain_now` correctly returned `eof=false` and left the tail for the next poll, but the cleanup loop read the raw atomic, saw `true`, removed the session, aborted `reader_task`, dropped the tail. Cleanup now tracks eof'd sids from `drain_now`'s return value — the session is only removed once the drain that returned `eof=true` has shipped to the client. Silent data loss on 1Gbps+ VPS that filled the buffer between polls — fixed.
+  - **Sessions-map lock held across upstream awaits:** phase-1 `data` op held the global sessions map across `last_active.lock`, `writer.lock`, `write_all`, and `flush` — head-of-line-blocking every other batch and connect/close op. Now (mirroring `udp_data`'s already-correct shape) it clones the `Arc` under the map lock, drops the lock, then awaits.
+  - **Mixed TCP+UDP batch paid the slower side's deadline:** `tokio::join!(wait_tcp, wait_udp)` is conjunctive — a TCP-ready burst still paid the UDP `LONGPOLL_DEADLINE` (15 s) before responding. Comment said "either side", code did "both sides". Switched to `tokio::select!`. New test `batch_tcp_ready_does_not_pay_udp_longpoll_deadline` locks down the regression.
+  - **Watcher tasks leaked under `select!` cancellation:** `wait_for_any_drainable` only aborted its watcher tasks in a trailing loop, past every cancellation point. With phase-2 wait flipped to `select!`, the loser arm's future drops and *detaches* its watchers (dropping a `JoinHandle` doesn't abort). Each orphan held an `Arc<...Inner>` and could steal a `notify_one()` permit from a future batch. Fix: `AbortOnDrop` newtype wraps every watcher `JoinHandle`.
+  2 new tests + 35/35 pass.
+• Example config exit-node now lists `aistudio.google.com` and `ai.google.dev` — requested in [#701](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/issues/701). AI Studio sanctions Iran IPs (independently of any Apps Script issue on our side). Routing it through the exit-node makes the destination see val.town's IP, which is neither Iran nor a Google datacenter.
+• Example config fronting-groups gained Reddit / Fastly / Pinterest / CNN / BuzzFeed family domains (PR [#696](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/pull/696) from @Shjpr9). All on the Fastly Anycast `151.101.x.x` edge — gives users a richer starter list to trim down based on what works in their network.
+• Tests: 179 lib + 35 tunnel-node tests all passing.