| Message ID | 20240423074136.392737-1-amusil@redhat.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [ovs-dev] tests: Fix netcat 7.94 issues. | expand |
| Context | Check | Description |
|---|---|---|
| ovsrobot/apply-robot | success | apply and check: success |
| ovsrobot/github-robot-_Build_and_Test | success | github build: passed |
| ovsrobot/github-robot-_ovn-kubernetes | fail | github build: failed |
On 4/23/24 09:41, 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 <amusil@redhat.com> > --- Applied to main and 24.03, thanks! Best regards, Dumitru
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 <amusil@redhat.com> > --- > 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.
On 4/23/24 11:12, martin.kalcok@canonical.com wrote: > 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 <amusil@redhat.com> >> --- >> 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. > I forgot to mention in my previous email that I had fixed this up. Same for the other comment. >> - 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. >
Thanks Dumitru, I didn't noticed that the patch was applied while I was typing my message :D Overall I think it's fine if it stays as it was proposed by Ales. I just wanted to raise a very fringe concern that perhaps using two separate UDP servers could mask some underlying issue and if there's a way to consistently reproduce failures of this test, I'd be happy to take a look at it. On Tue, 2024-04-23 at 11:15 +0200, Dumitru Ceara wrote: > On 4/23/24 11:12, martin.kalcok@canonical.com wrote: > > 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 <amusil@redhat.com> > > > --- > > > 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. > > > > I forgot to mention in my previous email that I had fixed this up. > Same > for the other comment. > > > > - 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. > > > Martin.
On Tue, Apr 23, 2024 at 11:26 AM <martin.kalcok@canonical.com> wrote: > Thanks Dumitru, > I didn't noticed that the patch was applied while I was typing my > message :D > > Overall I think it's fine if it stays as it was proposed by Ales. I > just wanted to raise a very fringe concern that perhaps using two > separate UDP servers could mask some underlying issue and if there's a > way to consistently reproduce failures of this test, I'd be happy to > take a look at it. > Hi Martin, so I doubt that this is some hidden issue because the listening netcat is really closed after the first connection, as this is not the first time I have encountered this. However for transparency I have included logs from both runs [0]. And you can reproduce it very easily just getting netcat 7.94 or running the tests with the Fedora container should be enough. > > > On Tue, 2024-04-23 at 11:15 +0200, Dumitru Ceara wrote: > > On 4/23/24 11:12, martin.kalcok@canonical.com wrote: > > > 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 <amusil@redhat.com> > > > > --- > > > > 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. > > > > > > > I forgot to mention in my previous email that I had fixed this up. > > Same > > for the other comment. > > > > > > - 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. > > > > > > > > Martin. > > [0] https://paste.centos.org/view/34a2c30f Thanks, Ales
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 - 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) # 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 - 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])
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 <amusil@redhat.com> --- tests/system-ovn.at | 14 +++++++++++--- 1 file changed, 11 insertions(+), 3 deletions(-)