<div dir="ltr"><br><br>On Sat, 27 Mar 2021 at 14:36, Paul Wouters <<a href="mailto:paul@nohats.ca">paul@nohats.ca</a>> wrote:<br>><br>> Begin forwarded message:<br>><br>> > New commits:<br>> > commit d49d315ec8b71377a1fc9de9f0277d1396fec5c7<br>> > Author: Andrew Cagney <<a href="mailto:cagney@gnu.org">cagney@gnu.org</a>><br>> > Date:   Sat Mar 27 12:52:52 2021 -0400<br>> ><br>> >    testing: sprinkle ping-once<br>> ><br>> >    things are getting interesting for instance, replacing:<br>> >      ping -c 2 ...<br>> >      50% packet loss, but sometimes 100%<br>> >    with:<br>> >      ping-once --forget<br>> >      wait-for traffic status<br>> >      ping-once --up<br>><br>> Remember an on-demand tunnel eats the first icmp packet, maybe two on occasion if things are slow. That is why I usually now do a single ping they triggers the tunnel and a second -c4 ping to show no packet loss.<br><br>Right, ping + sleep + ping-c4 is an improvement.  However, there's still no guarantee that the sleep is long enough, and ping-c4 can miss the last response.  Hence, this change:<div><br><div><div>- send a single packet, barely wait for a response:</div><div><br><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div> # one packet, which gets eaten by XFRM, so east does not initiate</div><div>road #</div><div> ../../pluto/bin/ping-once.sh --forget -I 192.1.3.209 192.1.2.23</div><div>fired and forgotten</div><div>road #</div></blockquote><div><br></div><div>- now wait for the negotiation to complete - notice how, at this point, in/out bytes are, as expected, zero:</div><br><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div> # wait on OE IKE negotiation</div><div>road #</div><div> ../../pluto/bin/wait-for.sh --match private-or-clear -- ipsec whack --trafficstatus</div><div>006 #2: "private-or-clear#<a href="http://192.1.2.0/24">192.1.2.0/24</a>"[1] <a href="http://10.0.10.1/32===">10.0.10.1/32===</a> ...192.1.2.23, type=ESP, add_time=1234567890, inBytes=0, outBytes=0, id='C=CA, ST=Ontario, L=Toronto, O=Libreswan, OU=Test Department, CN=e</div><div><a href="http://ast.testing.libreswan.org">ast.testing.libreswan.org</a>, E=<a href="mailto:user-east@testing.libreswan.org">user-east@testing.libreswan.org</a>', lease=<a href="http://10.0.10.1/32">10.0.10.1/32</a></div><div>road #</div></blockquote><div><br></div>- next send out a packet that should travel through the tunnel; since a response is expected, wait a long time for the response (at least when compared to default ping):</div><div><br><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div> # should show established tunnel and no bare shunts</div><div>road #</div><div> ../../pluto/bin/ping-once.sh --up -I 192.1.3.209 192.1.2.23</div><div>up</div></blockquote><div><br></div>- finally confirm the packet was tunneled:</div><div><br></div><div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>road #</div><div> ipsec whack --trafficstatus</div><div>006 #2: "private-or-clear#<a href="http://192.1.2.0/24">192.1.2.0/24</a>"[1] <a href="http://10.0.10.1/32===">10.0.10.1/32===</a> ...192.1.2.23, type=ESP, add_time=1234567890, inBytes=84, outBytes=84, id='C=CA, ST=Ontario, L=Toronto, O=Libreswan, OU=Test Department, CN</div><div>=<a href="http://east.testing.libreswan.org">east.testing.libreswan.org</a>, E=<a href="mailto:user-east@testing.libreswan.org">user-east@testing.libreswan.org</a>', lease=<a href="http://10.0.10.1/32">10.0.10.1/32</a></div><div>road #</div><div> ipsec whack --shuntstatus</div><div>000 Bare Shunt list:</div><div>000  </div></blockquote></div><div><br>(I am so tempted to sanitize outBytes=84 to outBytes=1-ping)<br><br></div></div></div></div>