On 7/14/26 2:01 PM, 侯敏熙 wrote:

Hi Ilya,

Thanks for pointing this out.  I looked into this and found that
nc (netcat-openbsd) on Debian/Ubuntu does not have SCTP support at
all. The upstream OpenBSD nc only handles TCP, UDP, and
Unix-domain sockets, and the Debian patches don't add SCTP either.

AFAICT, 'nc' in netdev CI is the nmap version of netcat, it's not
the openbsd one.  Does nmap version support sctp?  Google seems to
think so at least.  The test should be skipped though if sctp is
not supported.

Note: sashiko had some comments on the daemon pid handling in v2.

Best regards, Ilya Maximets.

I see two cleaner alternatives that already have precedent in the
kernel selftests:

1. socat: net/netfilter/nft_queue.sh already uses
   "socat -u SCTP-LISTEN:PORT STDOUT" for SCTP data-plane testing.
   Many drivers/net/ selftests already gate on require_cmd("socat").

2. A small C helper: similar to sctp_hello.c used by sctp_vrf.sh
   and conntrack_sctp_collision.sh.  The shell test would call
   "./sctp_test server/client IP PORT" instead of ncat.

Which approach would you prefer for v3?

Best regards,
Minxi

侯敏熙 [off-list ref] 于2026年7月13日周一 11:02写道：

quoted

Ah so many thanks for your suggestions, Please forgive me,
I've always used ncat to write test cases.

I will re-spin this patch.

Ilya Maximets [off-list ref] 于2026年7月13日周一 10:39写道：

quoted

On 7/7/26 5:47 AM, Minxi Hou wrote:

quoted

Register OVS_KEY_ATTR_SCTP in the flow key parser so that sctp()
can be used in flow specifications. The ovs_key_sctp class already
exists (with src/dst fields matching the TCP/UDP siblings) but was
not wired into the parser, so the token was silently dropped and the
kernel rejected the flow.

Add test_sctp_connect_v4 exercising the SCTP flow key with
port-specific matching: sctp(dst=4443) for client-to-server and
sctp(src=4443) for server-to-client.

Wait for ncat readiness with ovs_wait instead of a fixed sleep so
the test does not race against ncat startup. Use grep -c on the
listening message to distinguish between successive ncat instances
that share the same stderr log. Kill the previous server before
respawning to avoid EADDRINUSE on the SCTP port.

Signed-off-by: Minxi Hou <redacted>
---
v1 -> v2: replace sleep with ovs_wait on ncat listening output,
          kill previous ncat server before respawning to avoid
          port conflict (Aaron review feedback)

 .../selftests/net/openvswitch/openvswitch.sh  | 102 ++++++++++++++++++
 .../selftests/net/openvswitch/ovs-dpctl.py    |   5 +
 2 files changed, 107 insertions(+)

diff --git a/tools/testing/selftests/net/openvswitch/openvswitch.sh

b/tools/testing/selftests/net/openvswitch/openvswitch.sh

quoted

index 2954245129a2..9c364eeb2ec2 100755

--- a/tools/testing/selftests/net/openvswitch/openvswitch.sh
+++ b/tools/testing/selftests/net/openvswitch/openvswitch.sh

@@ -32,6 +32,7 @@ tests="
      dec_ttl                                 ttl: dec_ttl decrements

IP TTL

quoted

      flow_set                                flow-set: Flow modify
      action_set                              set: SET action rewrites

fields

quoted

+     sctp_connect_v4                         sctp: SCTP flow key

matching

quoted

      psample                                 psample: Sampling packets

with psample"

quoted

 info() {

@@ -443,6 +444,107 @@ test_action_set() {
      return 0
 }

+# sctp_connect_v4 test
+# - sctp(dst=4443) matches client-to-server INIT
+# - sctp(src=4443) matches server-to-client INIT-ACK
+# - remove flows and verify connection fails, reinstall and recover
+test_sctp_connect_v4() {
+     local t="test_sctp_connect_v4"
+
+     which ncat >/dev/null 2>&1 || return $ksft_skip

Not a full review, but can we avoid ncat?  We already use nc in other
tests, using different implementations of the same thing in different
tests doesn't sound like a good idea.  On mnay systems nc and ncat
will be different implementations with different options and behavior.

Best regards, Ilya Maximets.

_______________________________________________
dev mailing list
dev@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev