Many system tests currently use ping with the combination of a
low packet count (-c 3), short interval between sends (-i 0.3)
and a _deadline_ of 2 seconds (-d 2).
This combination of options may lead to a situation where more
than count packets are sent however ping will stop when count
packets are received. This results in a failed test due to how
the result is checked, for example:
ping6 -q -c 3 -i 0.3 -w 2 fc00::3 | FORMAT_PING
@@ -1,2 +1,2 @@
-3 packets transmitted, 3 received, 0% packet loss, time 0ms
+4 packets transmitted, 3 received, 25% packet loss, time 0ms
To reiterate, in the above example there is no packet loss, but
ping stops after _receiving_ 3 packets, not bothering with
waiting for the response to the fourth packet it just sent out.
If we look at the iputils ping manual for the -w deadline option
we can read that this is expected behavior:
> Specify a timeout, in seconds, before ping exits regardless of
> how many packets have been sent or received. In this case ping
> does not stop after count packet are sent, it waits either for
> deadline expire or until count probes are answered or for some
> error notification from network.
To avoid these kinds of failures in checks where a response is
expected, we replace ping -w with ping -W.
We keep ping -w for checks where it is expected to NOT get a
response.
Acked-by: Simon Horman <horms@ovn.org>
Signed-off-by: Frode Nordahl <frode.nordahl@canonical.com>
Signed-off-by: Ilya Maximets <i.maximets@ovn.org>
34ae81c1f4