[PATCH net-next v5 0/2] selftests: openvswitch: SCTP flow key coverage (IPv6 + NAT)

[PATCH net-next v5 0/2] selftests: openvswitch: SCTP flow key coverage (IPv6 + NAT)

[Minxi Hou]

The merged IPv4 SCTP flow-key test covers only IPv4 and only the
plain forwarding path. This series adds SCTP over IPv6, and SCTP
across conntrack NAT (ovs_nat_update_key() rewrites L4 ports on the
recirculated skb). Patch 2 translates the destination port so that
SCTP branch is load-bearing; address-only NAT cannot tell a working
branch from a missing one.

Full OVS selftest suite is 19/19 OK on a freshly built kernel
(sctp_connect_v4, sctp_connect_v6, sctp_nat_connect_v4 included).

v5 restores the series title and patch 2 subject to the v1/v2 names.
I renamed them in v3 and v4; that was a mistake.

v1: https://lore.kernel.org/netdev/20260823020942.3101898-1-houminxi@gmail.com/
v2: https://lore.kernel.org/netdev/20260902125133.1828572-1-houminxi@gmail.com/
v3: https://lore.kernel.org/netdev/20260906165251.1176875-1-houminxi@gmail.com/
v4: https://lore.kernel.org/netdev/20260909122521.2687193-1-houminxi@gmail.com/

v2:
- rebase after net-next reopened (v1 was deferred while the tree was
  closed). no code change.

v3:
- usage() tab alignment
- wait for the payload with ovs_wait instead of a bare grep
- CONFIG_NF_CT_PROTO_SCTP in the config fragment
- probe with ct(commit,nat) so kernels without NAT skip
- NAT translates the destination port (4443 -> 5555)
- commit messages: drop the INIT/DATA claim; point patch 2 at
  ovs_nat_update_key()

v4:
- keyless ipv6(proto=132) install must be EINVAL 22
- wrap a few over-80 lines; checkpatch --strict clean
- rebase onto 548b86839f7f

v5:
- TEST_LIST descriptions sit at column 48 with the rest of the file;
  shortened so expand -t 8 stays under 80
- skip the v6 test when socat has no WITH_IP6
- CONFIG_NF_NAT=m in the ovs fragment so the NAT test is not skipped
  on the reference config
- CONFIG_NETFILTER_ADVANCED=y so CONFIG_NF_CT_PROTO_SCTP is visible
  (it depends on ADVANCED; without it the symbol is dropped and the
  NAT test skips)

Signed-off-by: Minxi Hou <houminxi@gmail.com>

Minxi Hou (2):
  selftests/net/openvswitch: add SCTP flow key test over IPv6
  selftests/net/openvswitch: add SCTP flow key test across conntrack NAT

 .../testing/selftests/net/openvswitch/config  |   3 +
 .../selftests/net/openvswitch/openvswitch.sh  | 202 ++++++++++++++++++
 2 files changed, 205 insertions(+)


base-commit: 548b86839f7fb819a4d6c83b71c73ec378d24275
-- 
2.55.0

[PATCH net-next v5 1/2] selftests/net/openvswitch: add SCTP flow key test over IPv6

[Minxi Hou]

The merged SCTP test covers only IPv4. The SCTP branch of the IPv6
extractor (the proto=132 walk after parse_ipv6hdr) and the v6 side of
the SCTP netlink validation (match_validate() requires the sctp() key
whenever ipv6(proto=132) is matched) have no selftest coverage.

Add test_sctp_connect_v6 mirroring the v4 test: bare icmpv6() flows
forward NS/NA, and ipv6(proto=132),sctp(dst=4443)/sctp(src=4443)
flows gate the association in the same three phases (flows installed,
removed, reinstalled). A keyless ipv6(proto=132) install must be
refused with EINVAL, pinning the reject side of the match_validate()
rule; without it a regression dropping the requirement would pass
unnoticed. The refusal is asserted to be EINVAL specifically, not a
parse error of the flow string. After the association succeeds the
test also pushes a known payload across and waits for the listener
to log it, proving the datapath carries the association's traffic
end to end, not only its handshake. Skips when the sctp module is
missing, socat lacks SCTP or IPv6 support, or IPv6 is unavailable;
an association or payload failure with the flows installed fails
the test.

Signed-off-by: Minxi Hou <houminxi@gmail.com>
---
 .../selftests/net/openvswitch/openvswitch.sh  | 109 ++++++++++++++++++
 1 file changed, 109 insertions(+)

diff --git a/tools/testing/selftests/net/openvswitch/openvswitch.sh b/tools/testing/selftests/net/openvswitch/openvswitch.sh
index a31f7fb6882d..aa84fafc3201 100755
--- a/tools/testing/selftests/net/openvswitch/openvswitch.sh
+++ b/tools/testing/selftests/net/openvswitch/openvswitch.sh
@@ -34,6 +34,7 @@ tests="
 	trunc					trunc: output truncation
 	icmpv6					icmpv6: ICMPv6 echo type match
 	sctp_connect_v4				sctp: SCTP flow key matching
+	sctp_connect_v6				sctp6: SCTP flow keys over IPv6
 	psample					psample: Sampling packets with psample"
 
 info() {
@@ -700,6 +701,114 @@ test_sctp_connect_v4() {
 	return 0
 }
 
+# sctp_connect_v6 test
+# - sctp(dst=4443) matches client-to-server INIT
+# - sctp(src=4443) matches server-to-client INIT-ACK
+# - icmpv6 NS/NA flows forward neighbour discovery
+# - remove flows and verify connection fails, reinstall and recover
+test_sctp_connect_v6() {
+	local t="test_sctp_connect_v6"
+	local v6="eth_type(0x86dd),ipv6(proto=132)"
+	local payload="SCTP6_DATA_OK"
+	local rxfile="${ovs_base}/${t}/sctp-rx.txt"
+
+	modprobe -q sctp 2>/dev/null || return "$ksft_skip"
+	socat -V 2>&1 | grep -q "define WITH_SCTP" || return "$ksft_skip"
+	socat -V 2>&1 | grep -q "define WITH_IP6" || return "$ksft_skip"
+	[ -e /proc/sys/net/ipv6 ] || return "$ksft_skip"
+
+	sbx_add "$t" || return $?
+	ovs_add_dp "$t" sctp6 || return 1
+
+	info "create namespaces"
+	for ns in client server; do
+		ovs_add_netns_and_veths "$t" "sctp6" "$ns" \
+		    "${ns:0:1}0" "${ns:0:1}1" || return 1
+	done
+
+	ip netns exec client ip addr add fd00::1/64 dev c1 nodad
+	ip netns exec client ip link set c1 up
+	ip netns exec server ip addr add fd00::2/64 dev s1 nodad
+	ip netns exec server ip link set s1 up
+
+	# NS/NA forwarding
+	ovs_add_flow "$t" sctp6 \
+	    'in_port(1),eth(),eth_type(0x86dd),ipv6(proto=58),icmpv6()' \
+	    '2' || return 1
+	ovs_add_flow "$t" sctp6 \
+	    'in_port(2),eth(),eth_type(0x86dd),ipv6(proto=58),icmpv6()' \
+	    '1' || return 1
+
+	# SCTP port matching: dst for request, src for reply
+	ovs_add_flow "$t" sctp6 \
+	    "in_port(1),eth(),$v6,sctp(dst=4443)" \
+	    '2' || return 1
+	ovs_add_flow "$t" sctp6 \
+	    "in_port(2),eth(),$v6,sctp(src=4443)" \
+	    '1' || return 1
+
+	# A keyless ipv6(proto=132) install must be refused (EINVAL):
+	# match_validate() requires the sctp() key. Pin the reject side
+	# of that rule; the keyed installs above cover the accept side.
+	# Verify the refusal is EINVAL (missing key), not a parse error.
+	err=$(ovs_sbx "$t" python3 $ovs_base/ovs-dpctl.py add-flow sctp6 \
+	    "in_port(1),eth(),$v6" '2' 2>&1 >/dev/null) \
+	    && { info "keyless SCTP flow should be refused"
+	         return 1; }
+	echo "$err" | grep -q "(22," || {
+		info "keyless SCTP flow refused for wrong reason: $err"
+		return 1
+	}
+
+	ovs_netns_spawn_daemon "$t" "server" \
+	    socat -u -t 1 SCTP6-LISTEN:4443,fork \
+	    OPEN:"$rxfile",creat,append
+	ovs_wait sctp_eps_has server 4443 || return 1
+
+	info "verify SCTP association with port-keyed flows"
+	ovs_sbx "$t" ip netns exec client \
+	    timeout 3 socat -u STDIN "SCTP6-CONNECT:[fd00::2]:4443" </dev/null \
+	    || return 1
+
+	info "verify SCTP DATA chunk crosses the datapath"
+	ovs_sbx "$t" ip netns exec client \
+	    timeout 3 socat -u STDIN "SCTP6-CONNECT:[fd00::2]:4443" \
+	    <<< "$payload" || return 1
+	ovs_wait grep -q "$payload" "$rxfile" \
+	    || { info "server did not receive SCTP DATA payload"
+	         return 1; }
+
+	ovs_del_flows "$t" sctp6
+
+	info "verify connection fails without flows"
+	ovs_add_flow "$t" sctp6 \
+	    'in_port(1),eth(),eth_type(0x86dd),ipv6(proto=58),icmpv6()' \
+	    '2' || return 1
+	ovs_add_flow "$t" sctp6 \
+	    'in_port(2),eth(),eth_type(0x86dd),ipv6(proto=58),icmpv6()' \
+	    '1' || return 1
+
+	ovs_sbx "$t" ip netns exec client \
+	    timeout 3 socat -u STDIN "SCTP6-CONNECT:[fd00::2]:4443" </dev/null \
+	    >/dev/null 2>&1 \
+	    && { info "connection should fail without flows"
+	         return 1; }
+
+	info "reinstall flows and verify recovery"
+	ovs_add_flow "$t" sctp6 \
+	    "in_port(1),eth(),$v6,sctp(dst=4443)" \
+	    '2' || return 1
+	ovs_add_flow "$t" sctp6 \
+	    "in_port(2),eth(),$v6,sctp(src=4443)" \
+	    '1' || return 1
+
+	ovs_sbx "$t" ip netns exec client \
+	    timeout 3 socat -u STDIN "SCTP6-CONNECT:[fd00::2]:4443" </dev/null \
+	    || return 1
+
+	return 0
+}
+
 # psample test
 # - use psample to observe packets
 test_psample() {
-- 
2.55.0

Re: [PATCH net-next v5 1/2] selftests/net/openvswitch: add SCTP flow key test over IPv6

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] The promised skip when IPv6 is unavailable is incomplete in
  test_sctp_connect_v6().

--

selftests/net/openvswitch: add SCTP flow key test over IPv6

This adds test_sctp_connect_v6 to the openvswitch selftest, mirroring the
existing IPv4 SCTP test: icmpv6() flows forward neighbour discovery while
ipv6(proto=132),sctp(dst=4443)/sctp(src=4443) flows gate an SCTP
association across the datapath, with a keyless ipv6(proto=132) install
expected to be refused with EINVAL.

> diff --git a/tools/testing/selftests/net/openvswitch/openvswitch.sh b/tools/testing/selftests/net/openvswitch/openvswitch.sh
> index a31f7fb6882d..aa84fafc3201 100755
> --- a/tools/testing/selftests/net/openvswitch/openvswitch.sh
> +++ b/tools/testing/selftests/net/openvswitch/openvswitch.sh

[ ... ]

> @@ -700,6 +701,114 @@ test_sctp_connect_v4() {
>  	return 0
>  }
>  
> +# sctp_connect_v6 test
> +# - sctp(dst=4443) matches client-to-server INIT
> +# - sctp(src=4443) matches server-to-client INIT-ACK
> +# - icmpv6 NS/NA flows forward neighbour discovery
> +# - remove flows and verify connection fails, reinstall and recover
> +test_sctp_connect_v6() {
> +	local t="test_sctp_connect_v6"
> +	local v6="eth_type(0x86dd),ipv6(proto=132)"
> +	local payload="SCTP6_DATA_OK"
> +	local rxfile="${ovs_base}/${t}/sctp-rx.txt"
> +
> +	modprobe -q sctp 2>/dev/null || return "$ksft_skip"
> +	socat -V 2>&1 | grep -q "define WITH_SCTP" || return "$ksft_skip"
> +	socat -V 2>&1 | grep -q "define WITH_IP6" || return "$ksft_skip"
> +	[ -e /proc/sys/net/ipv6 ] || return "$ksft_skip"

[Severity: Medium]

Is this gate enough to cover the case the changelog describes as "IPv6 is
unavailable"?  /proc/sys/net/ipv6 only tells us inet6_init() ran.  Only
ipv6.disable=1 short-circuits it:

net/ipv6/af_inet6.c:inet6_init() {
	...
	if (disable_ipv6_mod) {
		pr_info("Loaded, but administratively disabled, reboot required to enable\n");
		goto out;
	}
	...
}

With ipv6.disable_ipv6=1 instead, initialization completes and the sysctl
tree exists, so this check passes, but the module default is copied into
every new netns:

net/ipv6/addrconf.c:addrconf_init_net() {
	...
	/* these will be inherited by all namespaces */
	dflt->autoconf = ipv6_defaults.autoconf;
	dflt->disable_ipv6 = ipv6_defaults.disable_ipv6;
	...
}

so the veths created for the client and server namespaces come up with
cnf.disable_ipv6 set, and address assignment is rejected:

net/ipv6/addrconf.c:ipv6_add_addr() {
	...
	if (idev->cnf.disable_ipv6) {
		NL_SET_ERR_MSG_MOD(extack, "IPv6 is disabled on this device");
		err = -EACCES;
		goto out;
	}
	...
}

Would testing something that reflects usability, for example whether an
address can actually be added in a test namespace, match the promised skip
better?

> +
> +	sbx_add "$t" || return $?
> +	ovs_add_dp "$t" sctp6 || return 1
> +
> +	info "create namespaces"
> +	for ns in client server; do
> +		ovs_add_netns_and_veths "$t" "sctp6" "$ns" \
> +		    "${ns:0:1}0" "${ns:0:1}1" || return 1
> +	done
> +
> +	ip netns exec client ip addr add fd00::1/64 dev c1 nodad
> +	ip netns exec client ip link set c1 up
> +	ip netns exec server ip addr add fd00::2/64 dev s1 nodad
> +	ip netns exec server ip link set s1 up

[Severity: Medium]

These four setup commands in test_sctp_connect_v6() discard their exit
status, unlike the surrounding calls which all use "|| return 1".  If the
ip addr add calls fail with EACCES because disable_ipv6 was inherited by
the new namespaces, does the test keep going with no IPv6 addresses
configured and then report a failure at the association check below?

Would checking these with "|| return $ksft_skip" (or at least
"|| return 1" with an info message naming the failed step) make the
outcome match the cause?

[ ... ]

> +	info "verify SCTP association with port-keyed flows"
> +	ovs_sbx "$t" ip netns exec client \
> +	    timeout 3 socat -u STDIN "SCTP6-CONNECT:[fd00::2]:4443" </dev/null \
> +	    || return 1

[Severity: Medium]

This is the point where an unusable IPv6 setup surfaces.  With
ipv6.disable_ipv6=1 the connect cannot succeed, so run_test() reports FAIL,
while the changelog says:

    Skips when the sctp module is missing, socat lacks SCTP or IPv6
    support, or IPv6 is unavailable

Should this configuration end up as a skip rather than a failure, or should
the changelog be narrowed to say the skip only covers IPv6 not being
initialized at all?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260918144647.2024095-1-houminxi%40gmail.com

Re: [PATCH net-next v5 1/2] selftests/net/openvswitch: add SCTP flow key test over IPv6

[Aaron Conole]

netdev-bot+sashiko@kernel.org writes:

> Thank you for your contribution! Sashiko AI review found 1 potential
> issue(s) to consider.
>
> Critical: 0 · High: 0 · Medium: 1 · Low: 0
>
> If you believe none of the issues are legitimate, please reply to each
> issue of Medium severity or higher and explain why the AI is wrong.
> If any of them are legitimate and you plan to respin, please let patchwork
> know by including "pw-bot: cr" as a separate line at the end of your reply
> (one such reply per series is enough).
>
> - [Medium] The promised skip when IPv6 is unavailable is incomplete in
>   test_sctp_connect_v6().
>
> --
>
> selftests/net/openvswitch: add SCTP flow key test over IPv6
>
> This adds test_sctp_connect_v6 to the openvswitch selftest, mirroring the
> existing IPv4 SCTP test: icmpv6() flows forward neighbour discovery while
> ipv6(proto=132),sctp(dst=4443)/sctp(src=4443) flows gate an SCTP
> association across the datapath, with a keyless ipv6(proto=132) install
> expected to be refused with EINVAL.
>
>> diff --git a/tools/testing/selftests/net/openvswitch/openvswitch.sh
>> b/tools/testing/selftests/net/openvswitch/openvswitch.sh
>> index a31f7fb6882d..aa84fafc3201 100755
>> --- a/tools/testing/selftests/net/openvswitch/openvswitch.sh
>> +++ b/tools/testing/selftests/net/openvswitch/openvswitch.sh
>
> [ ... ]
>
>> @@ -700,6 +701,114 @@ test_sctp_connect_v4() {
>>  	return 0
>>  }
>>  
>> +# sctp_connect_v6 test
>> +# - sctp(dst=4443) matches client-to-server INIT
>> +# - sctp(src=4443) matches server-to-client INIT-ACK
>> +# - icmpv6 NS/NA flows forward neighbour discovery
>> +# - remove flows and verify connection fails, reinstall and recover
>> +test_sctp_connect_v6() {
>> +	local t="test_sctp_connect_v6"
>> +	local v6="eth_type(0x86dd),ipv6(proto=132)"
>> +	local payload="SCTP6_DATA_OK"
>> +	local rxfile="${ovs_base}/${t}/sctp-rx.txt"
>> +
>> +	modprobe -q sctp 2>/dev/null || return "$ksft_skip"
>> +	socat -V 2>&1 | grep -q "define WITH_SCTP" || return "$ksft_skip"
>> +	socat -V 2>&1 | grep -q "define WITH_IP6" || return "$ksft_skip"
>> +	[ -e /proc/sys/net/ipv6 ] || return "$ksft_skip"
>
> [Severity: Medium]
>
> Is this gate enough to cover the case the changelog describes as "IPv6 is
> unavailable"?  /proc/sys/net/ipv6 only tells us inet6_init() ran.  Only
> ipv6.disable=1 short-circuits it:

We don't do much to check that ipv6 is available.  The ICMPv6 test
doesn't do any additional safeguards.

> net/ipv6/af_inet6.c:inet6_init() {
> 	...
> 	if (disable_ipv6_mod) {
> 		pr_info("Loaded, but administratively disabled, reboot required to enable\n");
> 		goto out;
> 	}
> 	...
> }
>
> With ipv6.disable_ipv6=1 instead, initialization completes and the sysctl
> tree exists, so this check passes, but the module default is copied into
> every new netns:
>
> net/ipv6/addrconf.c:addrconf_init_net() {
> 	...
> 	/* these will be inherited by all namespaces */
> 	dflt->autoconf = ipv6_defaults.autoconf;
> 	dflt->disable_ipv6 = ipv6_defaults.disable_ipv6;
> 	...
> }
>
> so the veths created for the client and server namespaces come up with
> cnf.disable_ipv6 set, and address assignment is rejected:
>
> net/ipv6/addrconf.c:ipv6_add_addr() {
> 	...
> 	if (idev->cnf.disable_ipv6) {
> 		NL_SET_ERR_MSG_MOD(extack, "IPv6 is disabled on this device");
> 		err = -EACCES;
> 		goto out;
> 	}
> 	...
> }
>
> Would testing something that reflects usability, for example whether an
> address can actually be added in a test namespace, match the promised skip
> better?

We don't generally have a check for this.  Maybe it makes sense, but
that could be a separate cleanup if it really is needed.

>> +
>> +	sbx_add "$t" || return $?
>> +	ovs_add_dp "$t" sctp6 || return 1
>> +
>> +	info "create namespaces"
>> +	for ns in client server; do
>> +		ovs_add_netns_and_veths "$t" "sctp6" "$ns" \
>> +		    "${ns:0:1}0" "${ns:0:1}1" || return 1
>> +	done
>> +
>> +	ip netns exec client ip addr add fd00::1/64 dev c1 nodad
>> +	ip netns exec client ip link set c1 up
>> +	ip netns exec server ip addr add fd00::2/64 dev s1 nodad
>> +	ip netns exec server ip link set s1 up
>
> [Severity: Medium]
>
> These four setup commands in test_sctp_connect_v6() discard their exit
> status, unlike the surrounding calls which all use "|| return 1".  If the
> ip addr add calls fail with EACCES because disable_ipv6 was inherited by
> the new namespaces, does the test keep going with no IPv6 addresses
> configured and then report a failure at the association check below?
>
> Would checking these with "|| return $ksft_skip" (or at least
> "|| return 1" with an info message naming the failed step) make the
> outcome match the cause?

See above - same answer.

> [ ... ]
>
>> +	info "verify SCTP association with port-keyed flows"
>> +	ovs_sbx "$t" ip netns exec client \
>> +	    timeout 3 socat -u STDIN "SCTP6-CONNECT:[fd00::2]:4443" </dev/null \
>> +	    || return 1
>
> [Severity: Medium]
>
> This is the point where an unusable IPv6 setup surfaces.  With
> ipv6.disable_ipv6=1 the connect cannot succeed, so run_test() reports FAIL,
> while the changelog says:
>
>     Skips when the sctp module is missing, socat lacks SCTP or IPv6
>     support, or IPv6 is unavailable
>
> Should this configuration end up as a skip rather than a failure, or should
> the changelog be narrowed to say the skip only covers IPv6 not being
> initialized at all?

I don't think either is needed for this series.

Re: [PATCH net-next v5 1/2] selftests/net/openvswitch: add SCTP flow key test over IPv6

[Jakub Kicinski]

On Wed, 23 Sep 2026 08:31:31 -0400 Aaron Conole wrote:
> I don't think either is needed for this series.

Aaron, did you mean to ack this series? You (rightly) dismissed the AI
slop review, but no ack. Or there's something else that I'm missing?

Re: [PATCH net-next v5 1/2] selftests/net/openvswitch: add SCTP flow key test over IPv6

[Aaron Conole]

Jakub Kicinski <kuba@kernel.org> writes:

> On Wed, 23 Sep 2026 08:31:31 -0400 Aaron Conole wrote:
>> I don't think either is needed for this series.
>
> Aaron, did you mean to ack this series? You (rightly) dismissed the AI
> slop review, but no ack. Or there's something else that I'm missing?

I did, but didn't have access to email while attending a conference.
Sending ACKs now.

Re: [PATCH net-next v5 1/2] selftests/net/openvswitch: add SCTP flow key test over IPv6

[Minxi Hou]

On Tue, 22 Sep 2026 15:05:09 +0000, netdev-bot+sashiko@kernel.org wrote:
> [Medium] The promised skip when IPv6 is unavailable is incomplete in
> test_sctp_connect_v6().

The /proc/sys/net/ipv6 check only sees ipv6.disable=1. ipv6.disable_ipv6=1
still leaves the sysctl tree, and a new netns inherits it, so the address
add fails and this test would FAIL.

test_icmpv6() in the same file does not check disable_ipv6 either, and
its ip addr add calls also ignore the exit status. Aaron already said
this is not something we special-case in one test. A real usability check
belongs in one helper used by every IPv6 test in the file, not in this
series.

No respin for this comment.

Thanks,
Minxi

Re: [PATCH net-next v5 1/2] selftests/net/openvswitch: add SCTP flow key test over IPv6

[Narcisa Vasile]

On Fri, Sep 18, 2026 at 10:46:46AM -0400, Minxi Hou wrote:
> The merged SCTP test covers only IPv4. The SCTP branch of the IPv6
> extractor (the proto=132 walk after parse_ipv6hdr) and the v6 side of
> the SCTP netlink validation (match_validate() requires the sctp() key
> whenever ipv6(proto=132) is matched) have no selftest coverage.
> 
> Add test_sctp_connect_v6 mirroring the v4 test: bare icmpv6() flows
> forward NS/NA, and ipv6(proto=132),sctp(dst=4443)/sctp(src=4443)
> flows gate the association in the same three phases (flows installed,
> removed, reinstalled). A keyless ipv6(proto=132) install must be
> refused with EINVAL, pinning the reject side of the match_validate()
> rule; without it a regression dropping the requirement would pass
> unnoticed. The refusal is asserted to be EINVAL specifically, not a
> parse error of the flow string. After the association succeeds the
> test also pushes a known payload across and waits for the listener
> to log it, proving the datapath carries the association's traffic
> end to end, not only its handshake. Skips when the sctp module is
> missing, socat lacks SCTP or IPv6 support, or IPv6 is unavailable;
> an association or payload failure with the flows installed fails
> the test.
> 
> Signed-off-by: Minxi Hou <houminxi@gmail.com>
> ---
>  .../selftests/net/openvswitch/openvswitch.sh  | 109 ++++++++++++++++++
>  1 file changed, 109 insertions(+)
> 
Reviewed-by: Narcisa Vasile <narcisav.kernel@gmail.com>

Re: [PATCH net-next v5 1/2] selftests/net/openvswitch: add SCTP flow key test over IPv6

[Aaron Conole]

Minxi Hou <houminxi@gmail.com> writes:

> The merged SCTP test covers only IPv4. The SCTP branch of the IPv6
> extractor (the proto=132 walk after parse_ipv6hdr) and the v6 side of
> the SCTP netlink validation (match_validate() requires the sctp() key
> whenever ipv6(proto=132) is matched) have no selftest coverage.
>
> Add test_sctp_connect_v6 mirroring the v4 test: bare icmpv6() flows
> forward NS/NA, and ipv6(proto=132),sctp(dst=4443)/sctp(src=4443)
> flows gate the association in the same three phases (flows installed,
> removed, reinstalled). A keyless ipv6(proto=132) install must be
> refused with EINVAL, pinning the reject side of the match_validate()
> rule; without it a regression dropping the requirement would pass
> unnoticed. The refusal is asserted to be EINVAL specifically, not a
> parse error of the flow string. After the association succeeds the
> test also pushes a known payload across and waits for the listener
> to log it, proving the datapath carries the association's traffic
> end to end, not only its handshake. Skips when the sctp module is
> missing, socat lacks SCTP or IPv6 support, or IPv6 is unavailable;
> an association or payload failure with the flows installed fails
> the test.
>
> Signed-off-by: Minxi Hou <houminxi@gmail.com>
> ---

Reviewed-by: Aaron Conole <aconole@redhat.com>

[PATCH net-next v5 2/2] selftests/net/openvswitch: add SCTP flow key test across conntrack NAT

[Minxi Hou]

After conntrack NAT rewrites a packet, OVS refreshes the cached flow
key in ovs_nat_update_key(), which has a per-protocol branch for the
L4 ports (UDP/TCP/SCTP, conntrack.c). Address-only NAT cannot tell a
working SCTP branch from a missing one: the ports survive unchanged
either way, so a post-recirc match on the original port stays green
even with the branch deleted. The suite's NAT coverage drives TCP
over nc, and the merged SCTP test has no conntrack in the path, so
the SCTP branch goes unexercised.

Add test_sctp_nat_connect_v4: untracked client traffic to
192.168.0.20:4443 hits ct(commit,nat(dst=172.31.110.20:5555)),recirc,
and the post-recirc flows match the translated tuple,
ipv4(dst=172.31.110.20),sctp(dst=5555). Reply traffic is matched on
the restored original tuple, sctp(src=4443). With the SCTP branch
broken the translated port never reaches the key, no post-recirc
flow matches, and the association fails. The probe flow uses the
same ct+nat action as the real flows, so a kernel without
CONFIG_NF_NAT rejects it at flow-add time and the test skips instead
of failing. The config fragment sets CONFIG_NETFILTER_ADVANCED=y so
CONFIG_NF_CT_PROTO_SCTP is visible, CONFIG_NF_CT_PROTO_SCTP=y, and
CONFIG_NF_NAT=m so the reference build actually has those pieces.
After the association succeeds the test pushes a known payload
across and waits for the listener to log it.

Signed-off-by: Minxi Hou <houminxi@gmail.com>
---
 .../testing/selftests/net/openvswitch/config  |  3 +
 .../selftests/net/openvswitch/openvswitch.sh  | 93 +++++++++++++++++++
 2 files changed, 96 insertions(+)

diff --git a/tools/testing/selftests/net/openvswitch/config b/tools/testing/selftests/net/openvswitch/config
index a825e0b5c88e..15685d242813 100644
--- a/tools/testing/selftests/net/openvswitch/config
+++ b/tools/testing/selftests/net/openvswitch/config
@@ -3,10 +3,13 @@ CONFIG_INET_DIAG=y
 CONFIG_IP_SCTP=y
 CONFIG_IPV6=y
 CONFIG_NETFILTER=y
+CONFIG_NETFILTER_ADVANCED=y
 CONFIG_NET_IPGRE=m
 CONFIG_NET_IPGRE_DEMUX=m
 CONFIG_NF_CONNTRACK=m
 CONFIG_NF_CONNTRACK_OVS=y
+CONFIG_NF_CT_PROTO_SCTP=y
+CONFIG_NF_NAT=m
 CONFIG_OPENVSWITCH=m
 CONFIG_PSAMPLE=m
 CONFIG_VETH=y
diff --git a/tools/testing/selftests/net/openvswitch/openvswitch.sh b/tools/testing/selftests/net/openvswitch/openvswitch.sh
index aa84fafc3201..21444657a040 100755
--- a/tools/testing/selftests/net/openvswitch/openvswitch.sh
+++ b/tools/testing/selftests/net/openvswitch/openvswitch.sh
@@ -35,6 +35,7 @@ tests="
 	icmpv6					icmpv6: ICMPv6 echo type match
 	sctp_connect_v4				sctp: SCTP flow key matching
 	sctp_connect_v6				sctp6: SCTP flow keys over IPv6
+	sctp_nat_connect_v4			sctpnat4: SCTP NAT translation
 	psample					psample: Sampling packets with psample"
 
 info() {
@@ -1200,6 +1201,98 @@ test_nat_connect_v4 () {
 	return 0
 }
 
+# sctp_nat_connect_v4 test
+#  - SCTP association crosses a ct(commit,nat(dst=ip:port)) DNAT
+#  - post-recirc flows match the translated address and port, so the
+#    SCTP branch of the post-NAT flow key update is load-bearing
+test_sctp_nat_connect_v4 () {
+	local t="test_sctp_nat_connect_v4"
+	local payload="SCTP_NAT_DATA_OK"
+	local rxfile="${ovs_base}/${t}/sctp-rx.txt"
+
+	modprobe -q sctp 2>/dev/null || return "$ksft_skip"
+	socat -V 2>&1 | grep -q "define WITH_SCTP" || return "$ksft_skip"
+	# SCTP conntrack is compiled into nf_conntrack.ko, so check that
+	# loading it actually exposed the SCTP conntrack sysctls.
+	modprobe -q nf_conntrack 2>/dev/null || return "$ksft_skip"
+	[ -e /proc/sys/net/netfilter/nf_conntrack_sctp_timeout_established ] \
+	    || { info "no SCTP conntrack support - skipping"
+	         return "$ksft_skip"; }
+
+	sbx_add "test_sctp_nat_connect_v4" || return $?
+
+	ovs_add_dp "test_sctp_nat_connect_v4" sctpnat4 || return 1
+	info "create namespaces"
+	for ns in client server; do
+		ovs_add_netns_and_veths "test_sctp_nat_connect_v4" "sctpnat4" \
+		    "$ns" "${ns:0:1}0" "${ns:0:1}1" || return 1
+	done
+
+	ip netns exec client ip addr add 172.31.110.10/24 dev c1
+	ip netns exec client ip link set c1 up
+	ip netns exec server ip addr add 172.31.110.20/24 dev s1
+	ip netns exec server ip link set s1 up
+
+	ip netns exec client ip route add default via 172.31.110.20
+
+	# Check if the ct and nat actions can be configured.
+	ovs_add_flow "test_sctp_nat_connect_v4" sctpnat4 \
+		'in_port(1),eth(),eth_type(0x0800),ipv4()' \
+		'ct(commit,nat(dst=172.31.110.20:5555)),recirc(0x1)' \
+		&> /dev/null
+	if [ $? == 1 ]; then
+		info "no support for ct/nat actions - skipping"
+		ovs_exit_sig
+		return $ksft_skip
+	fi
+
+	ovs_del_flows "test_sctp_nat_connect_v4" sctpnat4
+
+	ovs_add_flow "test_sctp_nat_connect_v4" sctpnat4 \
+		'in_port(1),eth(),eth_type(0x0806),arp()' '2' || return 1
+	ovs_add_flow "test_sctp_nat_connect_v4" sctpnat4 \
+		'in_port(2),eth(),eth_type(0x0806),arp()' '1' || return 1
+	ovs_add_flow "test_sctp_nat_connect_v4" sctpnat4 \
+		"ct_state(-trk),in_port(1),eth(),eth_type(0x0800),"\
+"ipv4(dst=192.168.0.20)" \
+		"ct(commit,nat(dst=172.31.110.20:5555)),recirc(0x1)" || return 1
+	ovs_add_flow "test_sctp_nat_connect_v4" sctpnat4 \
+		"ct_state(-trk),in_port(2),eth(),eth_type(0x0800),ipv4()" \
+		"ct(commit,nat),recirc(0x2)" || return 1
+
+	ovs_add_flow "test_sctp_nat_connect_v4" sctpnat4 \
+		"recirc_id(0x1),ct_state(+trk-inv),in_port(1),eth(),"\
+"eth_type(0x0800),ipv4(dst=172.31.110.20,proto=132),"\
+"sctp(dst=5555)" \
+		"2" || return 1
+	ovs_add_flow "test_sctp_nat_connect_v4" sctpnat4 \
+		"recirc_id(0x2),ct_state(+trk-inv),in_port(2),eth(),"\
+"eth_type(0x0800),ipv4(src=192.168.0.20,proto=132),"\
+"sctp(src=4443)" \
+		"1" || return 1
+
+	ovs_netns_spawn_daemon "test_sctp_nat_connect_v4" "server" \
+		socat -u -t 1 SCTP4-LISTEN:5555,fork \
+		OPEN:"$rxfile",creat,append
+	ovs_wait sctp_eps_has server 5555 || return 1
+
+	info "verify SCTP association across NAT"
+	ovs_sbx "test_sctp_nat_connect_v4" ip netns exec client \
+	    timeout 3 socat -u STDIN "SCTP4-CONNECT:192.168.0.20:4443" \
+	    </dev/null || return 1
+
+	info "verify SCTP DATA chunk crosses NAT"
+	ovs_sbx "test_sctp_nat_connect_v4" ip netns exec client \
+	    timeout 3 socat -u STDIN "SCTP4-CONNECT:192.168.0.20:4443" \
+	    <<< "$payload" || return 1
+	ovs_wait grep -q "$payload" "$rxfile" \
+	    || { info "server did not receive SCTP DATA payload"
+	         return 1; }
+
+	info "done..."
+	return 0
+}
+
 # nat_related_v4 test
 #  - client->server ip packets go via SNAT
 #  - client solicits ICMP destination unreachable packet from server
-- 
2.55.0

Re: [PATCH net-next v5 2/2] selftests/net/openvswitch: add SCTP flow key test across conntrack NAT

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found more severe
issue(s) in other patches of this series. This mail is only an FYI, in case
you want to address the nit picks below when you respin.

Low priority / nit picks for your consideration:

- [Low] test_sctp_nat_connect_v4()
  (tools/testing/selftests/net/openvswitch/openvswitch.sh, new lines…

--

selftests/net/openvswitch: add SCTP flow key test across conntrack NAT

This adds test_sctp_nat_connect_v4, which drives an SCTP association
through ct(commit,nat(dst=172.31.110.20:5555)),recirc and matches the
translated tuple after recirculation, so the SCTP branch of
ovs_nat_update_key() is actually exercised. The config fragment gains
CONFIG_NETFILTER_ADVANCED, CONFIG_NF_CT_PROTO_SCTP and CONFIG_NF_NAT.

One question below about listener teardown.

> diff --git a/tools/testing/selftests/net/openvswitch/openvswitch.sh b/tools/testing/selftests/net/openvswitch/openvswitch.sh
> index aa84fafc3201..21444657a040 100755
> --- a/tools/testing/selftests/net/openvswitch/openvswitch.sh
> +++ b/tools/testing/selftests/net/openvswitch/openvswitch.sh

[ ... ]

> @@ -1200,6 +1201,98 @@ test_nat_connect_v4 () {
>  	return 0
>  }
>  
> +# sctp_nat_connect_v4 test
> +#  - SCTP association crosses a ct(commit,nat(dst=ip:port)) DNAT
> +#  - post-recirc flows match the translated address and port, so the
> +#    SCTP branch of the post-NAT flow key update is load-bearing
> +test_sctp_nat_connect_v4 () {
> +	local t="test_sctp_nat_connect_v4"
> +	local payload="SCTP_NAT_DATA_OK"
> +	local rxfile="${ovs_base}/${t}/sctp-rx.txt"

[ ... ]

> +	ovs_netns_spawn_daemon "test_sctp_nat_connect_v4" "server" \
> +		socat -u -t 1 SCTP4-LISTEN:5555,fork \
> +		OPEN:"$rxfile",creat,append
> +	ovs_wait sctp_eps_has server 5555 || return 1
> +
> +	info "verify SCTP association across NAT"
> +	ovs_sbx "test_sctp_nat_connect_v4" ip netns exec client \
> +	    timeout 3 socat -u STDIN "SCTP4-CONNECT:192.168.0.20:4443" \
> +	    </dev/null || return 1

[Severity: Low]
This isn't a bug, but can a forked socat child outlive teardown here?

The listener in test_sctp_nat_connect_v4() is started with the fork
option, so socat forks one child per accepted association, while
ovs_netns_spawn_daemon() only records the pid of the backgrounded
ip netns exec:

tools/testing/selftests/net/openvswitch/openvswitch.sh:ovs_netns_spawn_daemon() {
	...
		ip netns exec $netns $*  >> $ovs_dir/stdout  2>> $ovs_dir/stderr &
	fi
	pid=$!
	ovs_sbx "$sbx" on_exit "kill -TERM $pid 2>/dev/null"
}

There is no process group kill and no wait, so a child still blocked
reading its SCTP socket is not signalled or reaped. run_test() then runs
ovs_exit_sig() followed immediately by rm -rf "$ovs_dir", and the
registered on_exit actions do ip netns del server, so such a child would
keep a reference on the server netns and an open descriptor on the
unlinked sctp-rx.txt until the association's retransmit/heartbeat timers
give up. The -t 1 option bounds the linger after EOF is seen, not the
wait for EOF itself.

This would show up when the client is killed by timeout 3, or when a
post-recirc flow is missing so the peer's SHUTDOWN/ABORT is dropped. On
the passing path the client closes stdin right away (</dev/null and the
here-string), so the child sees EOF and exits.

The same forking-listener plus single-pid SIGTERM pattern is already used
by test_sctp_connect_v4() and test_sctp_connect_v6() in this file, so
this may simply be the convention here. Would it be worth killing the
process group and waiting for the listener in ovs_netns_spawn_daemon()
instead, which would cover all three tests?

> +
> +	info "verify SCTP DATA chunk crosses NAT"
> +	ovs_sbx "test_sctp_nat_connect_v4" ip netns exec client \
> +	    timeout 3 socat -u STDIN "SCTP4-CONNECT:192.168.0.20:4443" \
> +	    <<< "$payload" || return 1
> +	ovs_wait grep -q "$payload" "$rxfile" \
> +	    || { info "server did not receive SCTP DATA payload"
> +	         return 1; }
> +
> +	info "done..."
> +	return 0
> +}

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260918144647.2024095-1-houminxi%40gmail.com

Re: [PATCH net-next v5 2/2] selftests/net/openvswitch: add SCTP flow key test across conntrack NAT

[Aaron Conole]

netdev-bot+sashiko@kernel.org writes:

> Thank you for your contribution! Sashiko AI review found more severe
> issue(s) in other patches of this series. This mail is only an FYI, in case
> you want to address the nit picks below when you respin.
>
> Low priority / nit picks for your consideration:
>
> - [Low] test_sctp_nat_connect_v4()
>   (tools/testing/selftests/net/openvswitch/openvswitch.sh, new lines…
>
> --
>
> selftests/net/openvswitch: add SCTP flow key test across conntrack NAT
>
> This adds test_sctp_nat_connect_v4, which drives an SCTP association
> through ct(commit,nat(dst=172.31.110.20:5555)),recirc and matches the
> translated tuple after recirculation, so the SCTP branch of
> ovs_nat_update_key() is actually exercised. The config fragment gains
> CONFIG_NETFILTER_ADVANCED, CONFIG_NF_CT_PROTO_SCTP and CONFIG_NF_NAT.
>
> One question below about listener teardown.
>
>> diff --git a/tools/testing/selftests/net/openvswitch/openvswitch.sh
>> b/tools/testing/selftests/net/openvswitch/openvswitch.sh
>> index aa84fafc3201..21444657a040 100755
>> --- a/tools/testing/selftests/net/openvswitch/openvswitch.sh
>> +++ b/tools/testing/selftests/net/openvswitch/openvswitch.sh
>
> [ ... ]
>
>> @@ -1200,6 +1201,98 @@ test_nat_connect_v4 () {
>>  	return 0
>>  }
>>  
>> +# sctp_nat_connect_v4 test
>> +#  - SCTP association crosses a ct(commit,nat(dst=ip:port)) DNAT
>> +#  - post-recirc flows match the translated address and port, so the
>> +#    SCTP branch of the post-NAT flow key update is load-bearing
>> +test_sctp_nat_connect_v4 () {
>> +	local t="test_sctp_nat_connect_v4"
>> +	local payload="SCTP_NAT_DATA_OK"
>> +	local rxfile="${ovs_base}/${t}/sctp-rx.txt"
>
> [ ... ]
>
>> +	ovs_netns_spawn_daemon "test_sctp_nat_connect_v4" "server" \
>> +		socat -u -t 1 SCTP4-LISTEN:5555,fork \
>> +		OPEN:"$rxfile",creat,append
>> +	ovs_wait sctp_eps_has server 5555 || return 1
>> +
>> +	info "verify SCTP association across NAT"
>> +	ovs_sbx "test_sctp_nat_connect_v4" ip netns exec client \
>> +	    timeout 3 socat -u STDIN "SCTP4-CONNECT:192.168.0.20:4443" \
>> +	    </dev/null || return 1
>
> [Severity: Low]
> This isn't a bug, but can a forked socat child outlive teardown here?
>
> The listener in test_sctp_nat_connect_v4() is started with the fork
> option, so socat forks one child per accepted association, while
> ovs_netns_spawn_daemon() only records the pid of the backgrounded
> ip netns exec:
>
> tools/testing/selftests/net/openvswitch/openvswitch.sh:ovs_netns_spawn_daemon() {
> 	...
> 		ip netns exec $netns $*  >> $ovs_dir/stdout  2>> $ovs_dir/stderr &
> 	fi
> 	pid=$!
> 	ovs_sbx "$sbx" on_exit "kill -TERM $pid 2>/dev/null"
> }
>
> There is no process group kill and no wait, so a child still blocked
> reading its SCTP socket is not signalled or reaped. run_test() then runs
> ovs_exit_sig() followed immediately by rm -rf "$ovs_dir", and the
> registered on_exit actions do ip netns del server, so such a child would
> keep a reference on the server netns and an open descriptor on the
> unlinked sctp-rx.txt until the association's retransmit/heartbeat timers
> give up. The -t 1 option bounds the linger after EOF is seen, not the
> wait for EOF itself.
>
> This would show up when the client is killed by timeout 3, or when a
> post-recirc flow is missing so the peer's SHUTDOWN/ABORT is dropped. On
> the passing path the client closes stdin right away (</dev/null and the
> here-string), so the child sees EOF and exits.
>
> The same forking-listener plus single-pid SIGTERM pattern is already used
> by test_sctp_connect_v4() and test_sctp_connect_v6() in this file, so
> this may simply be the convention here. Would it be worth killing the
> process group and waiting for the listener in ovs_netns_spawn_daemon()
> instead, which would cover all three tests?

A separate process group would be over kill.  This is already
convention.

>> +
>> +	info "verify SCTP DATA chunk crosses NAT"
>> +	ovs_sbx "test_sctp_nat_connect_v4" ip netns exec client \
>> +	    timeout 3 socat -u STDIN "SCTP4-CONNECT:192.168.0.20:4443" \
>> +	    <<< "$payload" || return 1
>> +	ovs_wait grep -q "$payload" "$rxfile" \
>> +	    || { info "server did not receive SCTP DATA payload"
>> +	         return 1; }
>> +
>> +	info "done..."
>> +	return 0
>> +}
>
> [ ... ]

Re: [PATCH net-next v5 2/2] selftests/net/openvswitch: add SCTP flow key test across conntrack NAT

[Minxi Hou]

On Tue, 22 Sep 2026 15:05:10 +0000, netdev-bot+sashiko@kernel.org wrote:
> [Low] test_sctp_nat_connect_v4()
> can a forked socat child outlive teardown here?

Same pattern as test_sctp_connect_v4() and test_sctp_connect_v6():
fork on the listener, SIGTERM only the pid that ovs_netns_spawn_daemon()
recorded. A process-group kill inside that helper would change every
caller. Aaron already called that overkill. I am leaving the existing
convention.

No respin for this comment.

Thanks,
Minxi

Re: [PATCH net-next v5 2/2] selftests/net/openvswitch: add SCTP flow key test across conntrack NAT

[Narcisa Vasile]

On Fri, Sep 18, 2026 at 10:46:47AM -0400, Minxi Hou wrote:
> After conntrack NAT rewrites a packet, OVS refreshes the cached flow
> key in ovs_nat_update_key(), which has a per-protocol branch for the
> L4 ports (UDP/TCP/SCTP, conntrack.c). Address-only NAT cannot tell a
> working SCTP branch from a missing one: the ports survive unchanged
> either way, so a post-recirc match on the original port stays green
> even with the branch deleted. The suite's NAT coverage drives TCP
> over nc, and the merged SCTP test has no conntrack in the path, so
> the SCTP branch goes unexercised.
> 
> Add test_sctp_nat_connect_v4: untracked client traffic to
> 192.168.0.20:4443 hits ct(commit,nat(dst=172.31.110.20:5555)),recirc,
> and the post-recirc flows match the translated tuple,
> ipv4(dst=172.31.110.20),sctp(dst=5555). Reply traffic is matched on
> the restored original tuple, sctp(src=4443). With the SCTP branch
> broken the translated port never reaches the key, no post-recirc
> flow matches, and the association fails. The probe flow uses the
> same ct+nat action as the real flows, so a kernel without
> CONFIG_NF_NAT rejects it at flow-add time and the test skips instead
> of failing. The config fragment sets CONFIG_NETFILTER_ADVANCED=y so
> CONFIG_NF_CT_PROTO_SCTP is visible, CONFIG_NF_CT_PROTO_SCTP=y, and
> CONFIG_NF_NAT=m so the reference build actually has those pieces.
> After the association succeeds the test pushes a known payload
> across and waits for the listener to log it.
> 
> Signed-off-by: Minxi Hou <houminxi@gmail.com>
> ---
>  .../testing/selftests/net/openvswitch/config  |  3 +
>  .../selftests/net/openvswitch/openvswitch.sh  | 93 +++++++++++++++++++
>  2 files changed, 96 insertions(+)
> 
Reviewed-by: Narcisa Vasile <narcisav.kernel@gmail.com>

Re: [PATCH net-next v5 2/2] selftests/net/openvswitch: add SCTP flow key test across conntrack NAT

[Aaron Conole]

Minxi Hou <houminxi@gmail.com> writes:

> After conntrack NAT rewrites a packet, OVS refreshes the cached flow
> key in ovs_nat_update_key(), which has a per-protocol branch for the
> L4 ports (UDP/TCP/SCTP, conntrack.c). Address-only NAT cannot tell a
> working SCTP branch from a missing one: the ports survive unchanged
> either way, so a post-recirc match on the original port stays green
> even with the branch deleted. The suite's NAT coverage drives TCP
> over nc, and the merged SCTP test has no conntrack in the path, so
> the SCTP branch goes unexercised.
>
> Add test_sctp_nat_connect_v4: untracked client traffic to
> 192.168.0.20:4443 hits ct(commit,nat(dst=172.31.110.20:5555)),recirc,
> and the post-recirc flows match the translated tuple,
> ipv4(dst=172.31.110.20),sctp(dst=5555). Reply traffic is matched on
> the restored original tuple, sctp(src=4443). With the SCTP branch
> broken the translated port never reaches the key, no post-recirc
> flow matches, and the association fails. The probe flow uses the
> same ct+nat action as the real flows, so a kernel without
> CONFIG_NF_NAT rejects it at flow-add time and the test skips instead
> of failing. The config fragment sets CONFIG_NETFILTER_ADVANCED=y so
> CONFIG_NF_CT_PROTO_SCTP is visible, CONFIG_NF_CT_PROTO_SCTP=y, and
> CONFIG_NF_NAT=m so the reference build actually has those pieces.
> After the association succeeds the test pushes a known payload
> across and waits for the listener to log it.
>
> Signed-off-by: Minxi Hou <houminxi@gmail.com>
> ---

Reviewed-by: Aaron Conole <aconole@redhat.com>

Re: [PATCH net-next v5 0/2] selftests: openvswitch: SCTP flow key coverage (IPv6 + NAT)

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Fri, 18 Sep 2026 10:46:45 -0400 you wrote:
> The merged IPv4 SCTP flow-key test covers only IPv4 and only the
> plain forwarding path. This series adds SCTP over IPv6, and SCTP
> across conntrack NAT (ovs_nat_update_key() rewrites L4 ports on the
> recirculated skb). Patch 2 translates the destination port so that
> SCTP branch is load-bearing; address-only NAT cannot tell a working
> branch from a missing one.
> 
> [...]

Here is the summary with links:
  - [net-next,v5,1/2] selftests/net/openvswitch: add SCTP flow key test over IPv6
    https://git.kernel.org/netdev/net-next/c/392551884f44
  - [net-next,v5,2/2] selftests/net/openvswitch: add SCTP flow key test across conntrack NAT
    https://git.kernel.org/netdev/net-next/c/3e5e024c2075

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html