The reason I did t use ping-once is because it seems bound to a —up or —down and I didn’t want the connection modified ?
Am I misunderstanding the script? A lot of carefully timed tests will fail with a 3 second random delay though. Especially those engineered with short timers Sent from my iPhone > On Feb 7, 2020, at 21:43, Andrew Cagney <[email protected]> wrote: > > > > On Fri, 7 Feb 2020 at 16:45, Paul Wouters <[email protected]> wrote: > > commit e70651a682602916773c0a09fa12a7ac8bda8c0e > > Author: Paul Wouters <[email protected]> > > Date: Fri Feb 7 16:28:22 2020 -0500 > > > > testing: stabilize newoe-25-cat-4 > > > > road # > sleep 3 > > waiting a magic 3 seconds isn't more stable - load the machine and watch it > fail. Nor is 'ping -n -c 3' (it can send 4 pings). Try this: > road # > # trigger OE > road # > ../../pluto/bin/ping-once.sh --down -I 192.1.3.209 192.1.2.23 > down > road # > ../../pluto/bin/wait-for.sh --match '"private-or-clear#192.1.2.0/24"' -- > ipsec whack --trafficstatus > 006 #2: "private-or-clear#192.1.2.0/24"[1] ...192.1.2.23, type=ESP, > add_time=1234567890, inBytes=0, outBytes=0, id='ID_NULL' > road # > ../../pluto/bin/ping-once.sh --up -I 192.1.3.209 192.1.2.23 > up > > > > road # > ping -n -c 3 -I 192.1.3.209 192.1.2.23 > PING 192.1.2.23 (192.1.2.23) from 192.1.3.209 : 56(84) bytes of data. > 64 bytes from 192.1.2.23: icmp_seq=1 ttl=64 time=0.XXX ms > 64 bytes from 192.1.2.23: icmp_seq=2 ttl=64 time=0.XXX ms > 64 bytes from 192.1.2.23: icmp_seq=3 ttl=64 time=0.XXX ms > 64 bytes from 192.1.2.23: icmp_seq=4 ttl=64 time=0.XXX ms > --- 192.1.2.23 ping statistics --- > 4 packets transmitted, 3 received, 25% packet loss, time XXXX > 3 packets transmitted, 3 received, 0% packet loss, time XXXX > _______________________________________________ > Swan-dev mailing list > [email protected] > https://lists.libreswan.org/mailman/listinfo/swan-dev
_______________________________________________ Swan-dev mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan-dev
