Minxi Hou <[email protected]> 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 <[email protected]> > ---
Reviewed-by: Aaron Conole <[email protected]> _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
