`cmd_status` has two paths. The `--name` path filters on an exact tag and
works. The no-name path — the "show me every switch on this box" survey,
which is how an orphan switch under a different name would be found —
built its python with shell quote-juggling and never closed the string
literal, so it died with a SyntaxError every time.
It failed loudly (rc=1, a traceback) rather than reporting "no rules", so
it never lied about the state. But it also meant the survey path had
never once run, which is the more useful lesson: every branch of a safety
tool needs exercising, not just the branch the happy path takes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Three times now the same sequence has broken the client path: a build guard
correctly refuses to start the Rust replacement, and the `switch on` that
follows in the same script arms anyway, because it never checked whether
anything was listening. The redirect then lands on a closed socket and the
working Python service is bypassed for no benefit.
`on` now refuses unless the target port is listening. ALLOW_DEAD_TARGET=1
overrides it for arming ahead of a service that is about to start, but that has
to be deliberate. Verified both ways: rc=2 and nothing installed against a dead
port, rc=0 and two rules with the override.
The watchdog now writes a pidfile. Stopping it by command-line match is unsafe
-- any shell whose arguments merely mention the script name matches too, which
has now killed the wrong process twice here (once via `pkill -f`, once via a
/proc/*/cmdline substring loop).
The Blaze switch was hardwired to 42130 and could not intercept the redirector.
Rather than clone it, the iptables logic now lives in one place:
openfut-switch.sh generic: --server-ip --intercept-port --target-port
--name [--client-ip] [--legacy-tag]
blaze-switch.sh thin wrapper, CLI and output UNCHANGED so the validated
gate runbook and sidecar.sh's cross-check keep working
No deployment IP or port literal in the generic tool; 42130 is supplied by the
wrapper, 42127 by the redirector experiment.
VERIFICATION IS INDEPENDENT OF REMOVAL. Rules are created and deleted by their
comment tag; they are verified by parsing the kernel's own FIELDS (chain,
destination, dport, to-ports) with no reference to the comment. Status detects
duplicates, incomplete pairs, conflicting targets under one name, and foreign
redirects on the same port -- which it reports but never deletes. `off` removes
only rules bearing this switch's exact tag, then re-reads the table to confirm.
THREE BUGS FOUND WHILE BUILDING IT, all in the same family as the original
lying rollback:
1. Renaming the tag ORPHANED live rules. Gate 10 deliberately ended with the
switch on, so rules carrying the old tag were still installed and the
renamed tool could not see them -- `off` would have reported success while
traffic stayed redirected. Hence --legacy-tag: a rename must not strand
rules it owns.
2. Deleting by re-feeding the raw `iptables-save` line through the shell fails
on this iptables, which prints `--comment "tag"` WITH quotes; word-splitting
leaves the quotes inside the value so nothing matches. Bare-comment rules
deleted fine, which is exactly what made it look like it worked. Deletes are
now rebuilt from parsed fields and passed as argv elements.
3. `IFS=$'\t' read` collapsed consecutive tabs because tab is IFS *whitespace*,
so an absent `-s` shifted every later field left and produced
`-s <dport> --dport <to_ports> --to-ports ''`. Harmless here, but a shifted
spec that matched a real rule would delete the wrong one. Now uses \x1f.
Mutation-tested against all seven required cases: wrong intercept port, wrong
target port, missing rule, duplicate rule, changed comment representation
(bare vs quoted), and a rollback that leaves a foreign redirect installed --
which exits non-zero rather than claiming success.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
funman300