fix(trafficgen): pin the trafficgen gate — select veth by IPv4, not link order #256

Merged
vxfemboy merged 1 commit from fix/trafficgen-iface-select-by-ipv4 into main 2026-08-03 00:56:48 +00:00
Owner

The trafficgen-foundation gate ran in CI for the first time (once the deception-nft fix #254 let the lab job get past gate 6) and failed — same container-netns bug as #254, in a second crate.

From the self-diagnosing dump (#251):

not ok 2 - assert target/debug/trafficgen send --dst 10.0.0.1 ...   # exit 1 != 0
# ===== sink/run.log =====
#   { "total": {"packets": 0}, "kernel_rx_packets": 0 }

Root cause. blackwall_trafficgen::io::first_non_loopback_iface() returned the first non-lo link. In the runner's container netns, auto-created tunnel stubs (sit0/tunl0/ip6tnl0) sort ahead of the veth and carry no address, so both send and recv bound AF_PACKET to a tunnel stub — the flood went into the void (kernel_rx_packets: 0), and send's ≥50%-of-target fidelity self-check failed (exit 1). Passed on bare metal, whose netns has only lo + the veth.

Fix. Select the interface by scanning ip -o -4 addr show — both ends of the lab /30 link carry an IPv4, so the veth is picked on each side. (Identical to #254's deception fix, other crate.)

Verified. trafficgen-foundation passes 3/3 locally; clippy --deny warnings + fmt clean. The ip-selection change is the same one proven in #254 (a no-IP dummy iface sorted ahead of an addressed veth: old logic picks the dummy, new logic picks the veth).

The `trafficgen-foundation` gate ran in CI for the first time (once the deception-nft fix #254 let the lab job get past gate 6) and failed — same container-netns bug as #254, in a second crate. **From the self-diagnosing dump (#251):** ``` not ok 2 - assert target/debug/trafficgen send --dst 10.0.0.1 ... # exit 1 != 0 # ===== sink/run.log ===== # { "total": {"packets": 0}, "kernel_rx_packets": 0 } ``` **Root cause.** `blackwall_trafficgen::io::first_non_loopback_iface()` returned the *first non-`lo` link*. In the runner's container netns, auto-created tunnel stubs (`sit0`/`tunl0`/`ip6tnl0`) sort ahead of the veth and carry no address, so **both** `send` and `recv` bound `AF_PACKET` to a tunnel stub — the flood went into the void (`kernel_rx_packets: 0`), and `send`'s ≥50%-of-target fidelity self-check failed (exit 1). Passed on bare metal, whose netns has only `lo` + the veth. **Fix.** Select the interface by scanning `ip -o -4 addr show` — both ends of the lab `/30` link carry an IPv4, so the veth is picked on each side. (Identical to #254's deception fix, other crate.) **Verified.** `trafficgen-foundation` passes 3/3 locally; clippy `--deny warnings` + fmt clean. The `ip`-selection change is the same one proven in #254 (a no-IP dummy iface sorted ahead of an addressed veth: old logic picks the dummy, new logic picks the veth).
fix(trafficgen): select the veth by its IPv4, not link order
Some checks failed
CI / check (pull_request) Successful in 41m54s
CI / lab (pull_request) Failing after 11m57s
a4a99e129a
Same container-netns bug the deception gate had (#254): first_non_loopback_iface()
returned the first non-lo link, but the CI runner's container netns auto-creates
tunnel stubs (sit0/tunl0/ip6tnl0) that sort ahead of the veth and carry no
address. Both send and recv bound AF_PACKET to a tunnel stub, so the flood went
into the void — the sink logged kernel_rx_packets: 0 and send's >=50%-of-target
fidelity check failed (exit 1). Passed on bare metal, whose netns has only lo +
the veth.

Select the interface by scanning 'ip -o -4 addr show' — both ends of the lab
/30 link carry an IPv4, so the veth is picked on each side. The trafficgen-
foundation gate passes 3/3 locally.
Sign in to join this conversation.
No description provided.