fix(deception): pin the deception-nft gate — select veth by IPv4, not link order #254

Merged

vxfemboy merged 1 commit from fix/deception-iface-select-by-ipv4 into main

2026-08-02 22:23:47 +00:00

vxfemboy commented

2026-08-02 22:09:01 +00:00

Owner

The deception-nft lab gate has never passed in CI. With the new failure-log dump (#251) the cause is finally visible:

thread 'serves_deception_banner' panicked at crates/blackwall-deception/tests/interop.rs:51:
no inet addr on iface

Root cause. first_non_loopback_iface() returned the first non-lo link. In the CI runner's container, a fresh netns auto-creates tunnel devices (sit0/tunl0/ip6tnl0) that sort ahead of the veth in ip link show but carry no address — so the helper returned a tunnel stub and first_ipv4_of() panicked. It passed on bare metal, whose netns holds only lo + the veth. Not a product bug; a test-harness iface-selection bug.

Fix. Select the interface by scanning ip -o -4 addr show — the veth is the only non-lo interface carrying an inet address, so tunnel stubs are skipped. Test-only change to the interop driver.

Verified. Reproduced the selection difference directly: with a no-IP dummy0 sorted ahead of an addressed veth, the old logic picks dummy0 (→ the panic), the new logic picks the veth. deception-nft passes 2/2 locally; fmt + clippy clean. The other deception gates (resilience, syncookie) share the helper and gain the same robustness — they'd have hit this too once deception-nft stopped failing first.

The `deception-nft` lab gate has never passed in CI. With the new failure-log dump (#251) the cause is finally visible: ``` thread 'serves_deception_banner' panicked at crates/blackwall-deception/tests/interop.rs:51: no inet addr on iface ``` **Root cause.** `first_non_loopback_iface()` returned the *first non-`lo` link*. In the CI runner's container, a fresh netns auto-creates tunnel devices (`sit0`/`tunl0`/`ip6tnl0`) that sort ahead of the veth in `ip link show` but carry no address — so the helper returned a tunnel stub and `first_ipv4_of()` panicked. It passed on bare metal, whose netns holds only `lo` + the veth. Not a product bug; a test-harness iface-selection bug. **Fix.** Select the interface by scanning `ip -o -4 addr show` — the veth is the only non-`lo` interface carrying an inet address, so tunnel stubs are skipped. Test-only change to the interop driver. **Verified.** Reproduced the selection difference directly: with a no-IP `dummy0` sorted ahead of an addressed veth, the old logic picks `dummy0` (→ the panic), the new logic picks the veth. `deception-nft` passes 2/2 locally; fmt + clippy clean. The other deception gates (resilience, syncookie) share the helper and gain the same robustness — they'd have hit this too once deception-nft stopped failing first.

vxfemboy added 1 commit

2026-08-02 22:09:01 +00:00

fix(deception): select the veth by its IPv4, not link order

CI / check (pull_request) Successful in 12m4s

Details

CI / lab (pull_request) Failing after 12m14s

Details

046c424381

The deception-nft lab gate panicked "no inet addr on iface" at setup in
the CI runner's container: a fresh netns there auto-creates tunnel
devices (sit0/tunl0/ip6tnl0) that sort ahead of the veth in `ip link
show`, so first_non_loopback_iface() returned a tunnel stub and
first_ipv4_of() found no address. It passed on bare metal, whose netns
has only lo + the veth.

Pick the interface by scanning `ip -o -4 addr show` — the veth is the
only non-lo interface carrying an inet address, so tunnel stubs are
skipped. The other deception gates (resilience, syncookie) share the
helper and get the same robustness.

vxfemboy merged commit e8b464c4d7 into main

2026-08-02 22:23:47 +00:00

vxfemboy referenced this pull request from a commit

2026-08-02 22:23:49 +00:00

fix(deception): pin the deception-nft gate — select veth by IPv4, not link order (#254)

vxfemboy referenced this pull request from a commit

2026-08-03 00:13:06 +00:00

fix(trafficgen): select the veth by its IPv4, not link order

vxfemboy referenced this pull request

2026-08-03 00:13:35 +00:00

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

vxfemboy referenced this pull request from a commit