<div dir="ltr">FYI,<div><br><div>I've cleaned up the tests that were relying on ping where:</div><div><br></div><div>- packet 1 triggering OE</div><div>- packet 2 flowing because OE finished in under a second</div><div><br></div><div>For instance:</div><div><br></div><div> east #<br>- # trigger OE<br> east #<br>- ping -n -q -c 4 -I 192.1.2.23 192.1.3.209<br>-PING 192.1.3.209 (192.1.3.209) from 192.1.2.23 : 56(84) bytes of data.<br>---- 192.1.3.209 ping statistics ---<br>-4 packets transmitted, 3 received, 25% packet loss, time XXXX<br>-rtt min/avg/max/mdev = 0.XXX/0.XXX/0.XXX/0.XXX ms</div><div><br></div><div>If you were lucky, they worked.  But the odds were not in your favour.  Instead the code uses wait-for.sh to keep things in sync with pluto vis:</div><div><br>+ ../../guestbin/ping-once.sh --forget -I 192.1.2.23 192.1.3.209<br>+fired and forgotten<br> east #<br></div></div><div>+ ../../guestbin/wait-for.sh --match private-or-clear -- ipsec trafficstatus<br>+006 #2: "private-or-clear#<a href="http://192.1.3.0/24">192.1.3.0/24</a>"[1] ...192.1.3.209, type=ESP, add_time=1234567890, inBytes=0, outBytes=0, ...<br> east #<br>+ ../../guestbin/ping-once.sh --up -I 192.1.2.23 192.1.3.209<br>+up<br>+east #</div><div>  ipsec trafficstatus<br> 006 #2: "private-or-clear#<a href="http://192.1.3.0/24">192.1.3.0/24</a>"[1] ...192.1.3.209, type=ESP, add_time=1234567890, inBytes=84, outBytes=84, ...<br></div><div><br></div><div>when adding new tests please don't use the old method.</div></div>