<div dir="ltr"><div><div><div>One thing I&#39;ve noticed with tests is that they can end up spending a lot of time trying to push a train wreck up hill.<br><br></div>For instance, looking in basic-pluto-01/westinit.sh:<br><br>/testing/guestbin/swan-prep<br># confirm that the network is alive<br>ping -n -c 4 -I 192.0.1.254 192.0.2.254<br># make sure that clear text does not get through<br>iptables -A INPUT -i eth1 -s <a href="http://192.0.2.0/24">192.0.2.0/24</a> -j LOGDROP<br># confirm with a ping<br>ping -n -c 4 -I 192.0.1.254 192.0.2.254<br>ipsec setup start<br>/testing/pluto/bin/wait-until-pluto-started<br>ipsec auto --add westnet-eastnet<br>ipsec auto --status<br>echo &quot;initdone&quot;<br><br></div>should either swan-prep or wait-until-pluto-started fail then there really is no point in continuing with the test; yet we do.<br><br></div><div>The obvious fix is to tweak the code feeding these commands to the remote end so that it checks the exit code.  Something like:<br><br>               test_domain.domain.log(&quot;[%s]# %s&quot;, basename, line)<br>                status = test_domain.shell.run(line, timeout=TEST_TIMEOUT)<br>                if status:<br>                    # XXX: Can&#39;t abort as some ping commands are<br>                    # expected to fail.<br>                    test_domain.domain.log(&quot;command &#39;%s&#39; failed with status %d&quot;, line, status)<br><br></div><div>as the comment notes, there are some got-yas:<br><br></div><div>- some commands are expected to fail; we&#39;d need to tweak them (for instance changing some &quot;ping ...&quot; commands to  &quot;! ping ...&quot;)<br><br></div><div>- sometimes things just fail (again pings), yet the test stumbles on and the rest seems to pass; a retry should flush this out<br></div><div><br></div><div>thoughts?<br><br></div><div>Andrew<br></div></div>