fix(trafficgen): pin the trafficgen gate — select veth by IPv4, not link order #256
No reviewers
Labels
No labels
bug
deploy
documentation
duplicate
enhancement
good first issue
help wanted
invalid
pull-request
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
femboy/blackwall!256
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/trafficgen-iface-select-by-ipv4"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The
trafficgen-foundationgate 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):
Root cause.
blackwall_trafficgen::io::first_non_loopback_iface()returned the first non-lolink. In the runner's container netns, auto-created tunnel stubs (sit0/tunl0/ip6tnl0) sort ahead of the veth and carry no address, so bothsendandrecvboundAF_PACKETto a tunnel stub — the flood went into the void (kernel_rx_packets: 0), andsend's ≥50%-of-target fidelity self-check failed (exit 1). Passed on bare metal, whose netns has onlylo+ the veth.Fix. Select the interface by scanning
ip -o -4 addr show— both ends of the lab/30link carry an IPv4, so the veth is picked on each side. (Identical to #254's deception fix, other crate.)Verified.
trafficgen-foundationpasses 3/3 locally; clippy--deny warnings+ fmt clean. Theip-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).