On Tue, Apr 23, 2024 at 11:26 AM <martin.kal...@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.kal...@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 <amu...@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 -- Ales Musil Senior Software Engineer - OVN Core Red Hat EMEA <https://www.redhat.com> amu...@redhat.com <https://red.ht/sig> _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
