>
>
> I am testing with different stable kernels to uncover timing issues.
>
> With nf and nf-next kernels with instrumentions, **this works just fine**.
>
> But I triggered a weird issue with Debian's 6.1.0-31-amd64:
>
> # ./nft_conntrack_reject_established.sh
> ...
> ERROR: backend filter-ip6: fail to connect to [dead:2::99]:8080
> ERROR: backend filter-ip6: fail to connect over the established connection to [dead:4::a]:8080
> ERROR: backend filter-ip6: fail to connect to [dead:4::a]:8080
> ERROR: backend filter-ip6: fail to connect over the established connection to [dead:4::a]:8080
> ERROR: backend filter-ip6: fail to connect to [dead:2::99]:8080
>
> interestingly if I reversed the order, ie. I run ipv6 before ipv4
> test, then ipv4 fails:
>
> for testname in "${!testcases[@]}"; do
> - test_conntrack_reject_established "ip" "$testname" "${testcases[$testname]}"
> test_conntrack_reject_established "ip6" "$testname" "${testcases[$testname]}"
> + test_conntrack_reject_established "ip" "$testname" "${testcases[$testname]}"
> done
>
> also, running standalone ipv4 test, ie.:
>
> for testname in "${!testcases[@]}"; do
> test_conntrack_reject_established "ip" "$testname" "${testcases[$testname]}"
> done
>
> or ipv6 test, ie.:
>
> for testname in "${!testcases[@]}"; do
> test_conntrack_reject_established "ip6" "$testname" "${testcases[$testname]}"
> done
>
> works perfectly fine.
>
> Hm, where is the issue? I have to double check, maybe -stable 6.1 is
> missing a backport fix.
>
>
Naive question, the nft client used on the tests is the same in all
environments?
The fact that individually works but together doesn't and that the
test is using "inet" tables can point to something related to that
dual stack support?
