fix(drill): delete every listener — refused-vs-dropped already answers it #23

Merged
dan-claude-bot merged 1 commit from drill/listenerless-probes into main 2026-07-13 23:03:15 +00:00
dan-claude-bot commented 2026-07-13 23:02:50 +00:00 (Migrated from github.com)

Follow-up to #22. That PR made the in-box reads hang-proof; this one removes the reason the run could hang at all.

The listener was never load-bearing

curl's exit code already separates the two cases the audit cares about:

exit meaning verdict
0 connected reachable
7 connection refused the packet ARRIVED, a closed port answered with a RST — not isolated
28 timed out the packet was dropped in flightisolated

A closed port is a perfectly good target: it answers, or it doesn't. The listener added nothing the exit code didn't already say — and it is precisely what wedged runs 1 and 4, because a backgrounded process inside an incus exec session holds that session open no matter what you redirect. The host-side one also leaked a python3 -m http.server on every run.

All three listeners are gone. The drill now starts no background process anywhere (grep -cE 'http\.server|nohup|&$' → 0).

Sharper findings, not just safer plumbing

  • C4 (A3, sibling) now runs TCP and ping. tcp dropped + icmp replying is partial isolation — a real finding that the old listener-based probe would have reported as a clean pass.
  • C2 (A2, box→host) drops its gateway listener: the host already listens there (dnsmasq on :53, by design — that carve-out is what makes egress DNS work). Probing an unserved port and reading refused-vs-dropped is both safer and more honest about what the firewall must prevent.
  • C7 (A7, inbound) same treatment from the host side.

Merge, then one clean end-to-end run

cd claudebox && git pull && bash drill/drill.sh --yes

The drill reinstalls claudebox from main at the start of every run, so a pull is what brings this down. This should be the all-green run that closes #15: A3 answered, B3 settled (transient vs broken), and 49/49.

🤖 Generated with Claude Code

Follow-up to #22. That PR made the in-box *reads* hang-proof; this one removes the reason the run could hang at all. ## The listener was never load-bearing curl's exit code already separates the two cases the audit cares about: | exit | meaning | verdict | | --- | --- | --- | | 0 | connected | reachable | | **7** | connection **refused** | the packet **ARRIVED**, a closed port answered with a RST — **not isolated** | | **28** | timed out | the packet was **dropped in flight** — **isolated** | A closed port is a perfectly good target: it answers, or it doesn't. The listener added nothing the exit code didn't already say — and it is precisely what wedged runs 1 and 4, because a backgrounded process inside an `incus exec` session holds that session open no matter what you redirect. The host-side one also leaked a `python3 -m http.server` on every run. **All three listeners are gone. The drill now starts no background process anywhere** (`grep -cE 'http\.server|nohup|&$'` → 0). ## Sharper findings, not just safer plumbing - **C4 (A3, sibling)** now runs TCP *and* ping. `tcp dropped + icmp replying` is **partial isolation** — a real finding that the old listener-based probe would have reported as a clean pass. - **C2 (A2, box→host)** drops its gateway listener: the host *already* listens there (dnsmasq on `:53`, by design — that carve-out is what makes egress DNS work). Probing an unserved port and reading refused-vs-dropped is both safer and more honest about what the firewall must prevent. - **C7 (A7, inbound)** same treatment from the host side. ## Merge, then one clean end-to-end run ```sh cd claudebox && git pull && bash drill/drill.sh --yes ``` The drill reinstalls claudebox from `main` at the start of every run, so a pull is what brings this down. This should be the all-green run that closes #15: **A3 answered, B3 settled (transient vs broken), and 49/49.** 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Sign in to join this conversation.
No reviewers
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: heavy-duty/box#23
No description provided.