2nd packet and subsequent packets are sent based on SIGALRM and
it depends on poll(2) returns with EINTR by the signal. However,
currently poll is rump-ified while signals aren't so the signal
doesn't wake up poll and ping6 doesn't work expectedly.
Rump-ifying signals is unsure (nobody does it for now) and the
combination use of signals and poll makes the logic a bit complex.
So let's fix the defect by stopping using signals for packet
transmissions. The new logic is derived from ping(8).
Bonus: ping6 -i 0.01 works as we expect now while the original
didn't work enough fast.
It exited with status 0 when at least one packet was received
and timed out. However, when we specify -c N (while N > 0),
we expect that it fails if it times out before all sent requests
are replied.
ipsec_*_policy() functions, as it was documented and used by clients
-remove "ipsec_policy_t" which was undocumented and only present
in the KAME version of the ipsec.h header
-misc cleanup of historical artefacts, and to remove unnecessary
differences between KAME ans FAST_IPSEC
packets have already sent because of the preload count handling, we
shouldn't start off by sending another one right away. The reversed
test causes ping6 to wait one interval before sending anything at all
if you don't use -l. PR bin/39732.
for non-related samples. There are several websites that explain why we
should use this form instead of the normal formula to compute the std. dev.
(Wikipedia is one of them).
Also, ping(8) (where this "new" formula came from) already does it this way
so, I'm trying to score some extra points by making both utilities behave
the same way.
Thanks to wrtstuden@ for the initial clarification.
* RFC 3542 isn't binary compatible with RFC 2292.
* RFC 2292 support is on by default but can be disabled.
* update ping6, telnet and traceroute6 to the new API.
From the KAME project (www.kame.net).
Reviewed by core.
