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

[Aaron Conole <aconole@redhat.com>]

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>