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
>
> 侯敏熙 <[email protected]> 于2026年7月13日周一 11:02写道：
>
>> 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 <[email protected]> 于2026年7月13日周一 10:39写道：
>>
>>> On 7/7/26 5:47 AM, Minxi Hou wrote:
>>>> 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 <[email protected]>
>>>> ---
>>>> 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
>>>> 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
>>>> flow_set flow-set: Flow modify
>>>> action_set set: SET action rewrites
>>> fields
>>>> + sctp_connect_v4 sctp: SCTP flow key
>>> matching
>>>> psample psample: Sampling packets
>>> with psample"
>>>>
>>>> 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
> [email protected]
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
