Hi Ales,
Sorry that these new tests are causing problems. Just out of curiosity,
do you have link to some failing test runs? I'll add few thoughts
below.

On Tue, 2024-04-23 at 09:41 +0200, Ales Musil wrote:
> The netcat 7.94 allows multiple connections over udp (-k/--keep-open)
> [0],
> without this option the connection can be closed "unexpctedly". This
> to keep the test backward compatible make new servers for every UDP
> connection.
> 
> The second issue is that netcat is attempting to listen on IPv4 when
> the there isn't any server address specified and fails to do so. Add
> -6 flag to indicate that this is pure IPv6 connection.
> 
> [0]
> https://github.com/nmap/nmap/commit/4e6c8feb153c0c9ff8a68cd841669d650319ab45
> Fixes: 40136a2f2c84 ("northd: Fix direct access to SNAT network.")
> Signed-off-by: Ales Musil <[email protected]>
> ---
>  tests/system-ovn.at | 14 +++++++++++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/tests/system-ovn.at b/tests/system-ovn.at
> index 41c051c1e..6dcdb45d1 100644
> --- a/tests/system-ovn.at
> +++ b/tests/system-ovn.at
> @@ -3582,7 +3582,6 @@ test_connectivity_from_ext() {
>      local ip=$1; shift
>  
>      # Start listening daemons for UDP and TCP connections

nit: Comment above should be adjusted to reflect that UDP server is no
longer started here.
 
> -    NETNS_DAEMONIZE($vm, [nc -l -u 1234], [nc-$vm-$ip-udp.pid])
>      NETNS_DAEMONIZE($vm, [nc -l -k 1235], [nc-$vm-$ip-tcp.pid])
>  
>      # Ensure that vm can be pinged on the specified IP
> @@ -3592,8 +3591,13 @@ test_connectivity_from_ext() {
>  ])
>  
>      # Perform two consecutive UDP connections to the specified IP
> +    NETNS_DAEMONIZE($vm, [nc -l -u 1234], [nc-$vm-$ip-udp.pid])
>      NS_CHECK_EXEC([alice1], [nc -u $ip 1234 -p 2000 -z])
> +    kill $(cat nc-$vm-$ip-udp.pid)
> +
> +    NETNS_DAEMONIZE($vm, [nc -l -u 1234], [nc-$vm-$ip-udp.pid])
>      NS_CHECK_EXEC([alice1], [nc -u $ip 1234 -p 2000 -z])
> +    kill $(cat nc-$vm-$ip-udp.pid)

In the original tests, the two separate, consecutive, client
connections used same source port, which should ensure that the test
passes even without the '-k' option. This should work because a socket
is opened (and kept alive) between source IP:PORT and destination
IP:PORT on the server side. So if two client processes use the same
source port, to the server it just looks like a single client sending
two datagrams.

The reason why I decided to go with two consecutive client connections
is that inlining script for a single 'nc' process to send two messages
was very cumbersome

I'm just wondering that if the connection is "unexpectedly closed"
between the two client messages, whether it could signal some kind of
connection problem that should be investigated.

>  
>      # Send data over TCP connection to the specified IP
>      NS_CHECK_EXEC([alice1], [echo "TCP test" | nc --send-only $ip
> 1235])
> @@ -3781,8 +3785,7 @@ test_connectivity_from_ext() {
>      local ip=$1; shift
>  
>      # Start listening daemons for UDP and TCP connections

nit: Same nitpick about the comment as above

> -    NETNS_DAEMONIZE($vm, [nc -l -u 1234], [nc-$vm-$ip-udp.pid])
> -    NETNS_DAEMONIZE($vm, [nc -l -k 1235], [nc-$vm-$ip-tcp.pid])
> +    NETNS_DAEMONIZE($vm, [nc -6 -l -k 1235], [nc-$vm-$ip-tcp.pid])
>  
>      # Ensure that vm can be pinged on the specified IP
>      NS_CHECK_EXEC([alice1], [ping -q -c 3 -i 0.3 -w 2 $ip |
> FORMAT_PING], \
> @@ -3791,8 +3794,13 @@ test_connectivity_from_ext() {
>  ])
>  
>      # Perform two consecutive UDP connections to the specified IP
> +    NETNS_DAEMONIZE($vm, [nc -6 -l -u 1234], [nc-$vm-$ip-udp.pid])
>      NS_CHECK_EXEC([alice1], [nc -u $ip 1234 -p 2000 -z])
> +    kill $(cat nc-$vm-$ip-udp.pid)
> +
> +    NETNS_DAEMONIZE($vm, [nc -6 -l -u 1234], [nc-$vm-$ip-udp.pid])
>      NS_CHECK_EXEC([alice1], [nc -u $ip 1234 -p 2000 -z])
> +    kill $(cat nc-$vm-$ip-udp.pid)
>  
>      # Send data over TCP connection to the specified IP
>      NS_CHECK_EXEC([alice1], [echo "TCP test" | nc --send-only $ip
> 1235])

Thanks,
Martin.

_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to