fix(#136): bound connect-flood by its deadline so it can never hang #145

Merged

vxfemboy merged 3 commits from sp-fix-136-connect-flood into main

2026-07-07 08:17:50 +00:00

vxfemboy commented

2026-07-07 07:28:25 +00:00

(Migrated from github.com)

Fixes the root cause of #136 — the deception-resilience gate's connect-flood step hung indefinitely (600 concurrent connections against the engine's drop-at-cap defense), wedging the whole lab job.

Root cause: run_connect_flood workers could block past the --duration deadline on a connect/read when the engine accepts-then-stalls or holds connections at the cap.
Fix (io/connect.rs): every connect (2s) and read (500ms) is bounded, and each attempt is raced against the global deadline via tokio::select!, so run_connect_flood always returns within duration + grace even if every target connection hangs. A held/stalled connection still counts toward the flood, preserving the served>0 AND dropped+failed>0 self-assertion.
Regression tests: two tests prove a flood against an accept-then-never-respond listener returns within duration + grace instead of hanging.

Gate status: I re-enabled deception-resilience to verify in CI and it passed green (confirming the fix + that CI has working tproxy, unlike this dev box's kernel). BUT the next gate, rtbh, then wedged — reproducibly only when deception-resilience runs before it — so re-enabling it correlates with a downstream BIRD-gate wedge (the #137 systemic daemon-teardown issue). I therefore reverted the re-enable in this PR (net ci.yml change = zero): this PR lands only the connect-flood fix; all four gates are re-enabled together once #137's teardown-on-kill fix lands. The fix itself is verified.

Gate: fmt + clippy --deny warnings clean, blackwall-trafficgen connect tests pass (4, incl. 2 new), coverage 95.38%. No as casts.

Fixes the root cause of #136 — the `deception-resilience` gate's `connect-flood` step hung indefinitely (600 concurrent connections against the engine's drop-at-cap defense), wedging the whole lab job. - **Root cause:** `run_connect_flood` workers could block past the `--duration` deadline on a `connect`/read when the engine accepts-then-stalls or holds connections at the cap. - **Fix (`io/connect.rs`):** every connect (2s) and read (500ms) is bounded, and each attempt is raced against the global deadline via `tokio::select!`, so `run_connect_flood` **always returns within `duration` + grace** even if every target connection hangs. A held/stalled connection still counts toward the flood, preserving the `served>0 AND dropped+failed>0` self-assertion. - **Regression tests:** two tests prove a flood against an accept-then-never-respond listener returns within `duration + grace` instead of hanging. **Gate status:** I re-enabled `deception-resilience` to verify in CI and **it passed green** (confirming the fix + that CI has working tproxy, unlike this dev box's kernel). BUT the next gate, `rtbh`, then wedged — reproducibly only when `deception-resilience` runs before it — so re-enabling it correlates with a downstream BIRD-gate wedge (the #137 systemic daemon-teardown issue). I therefore reverted the re-enable in this PR (net ci.yml change = zero): **this PR lands only the connect-flood fix**; all four gates are re-enabled together once #137's teardown-on-kill fix lands. The fix itself is verified. Gate: fmt + clippy `--deny warnings` clean, `blackwall-trafficgen` connect tests pass (4, incl. 2 new), coverage 95.38%. No `as` casts.