I've updated the webrev here with the copyright year (thanks Christoph) and extra error codes. I overlooked the codes from the old implementation of tcp_ping4 above this code. These are winsock error codes which I would expect IcmpSendEcho to use, but in our testing it actually returned the system error codes in at least one situation:
https://msdn.microsoft.com/en-gb/library/windows/desktop/ms740668%28v=vs.85%29.aspx https://msdn.microsoft.com/en-us/library/windows/desktop/ms681383%28v=vs.85%29.aspx -Rob On 21/09/16 06:32, Seán Coffey wrote: > spotted an interesting blog on the MSDN timeout issue here : > https://www.frameflow.com/ping-utility-flaw-in-windows-api-creating-false-timeouts/ > > Regards, > Sean. > > On 21/09/16 17:42, Mark Sheppard wrote: > > > >the IcmpSendEcho series of calls come with some idiosyncrasies in that > >there is a minimum timeout that they can handle > >think it is about 1000msecs. isReachable can specify a finer grained > >timeout hence the need for timeout check > > > >regards > >Mark > > > >On 21/09/2016 17:18, Vyom Tewari wrote: > >> > >>Hi Rob, > >> > >>Do you really think this extra check is required ? > >> > >>if (pEchoReply->Status == IP_SUCCESS > >>+ && (int)pEchoReply->RoundTripTime <= timeout) I did not found any > >>doc(MSDN) which explains this. I think in case of IP_SUCCESS > >>"RoundTripTime" is always less than timeout. I think similar changes is > >>required in Inet6Address.c as well ? Thanks, Vyom > >> > >>On Wednesday 21 September 2016 08:46 PM, Rob McKenna wrote: > >>>Hi folks, > >>> > >>>I'd like to fix a bug caused by an incorrect assumption. The IcmpSendEcho* > >>>calls can actually return a similar set of errors regardless of whether > >>>the call itself failed or succeeded. This change checks that both the call > >>>and the ping were successful. In addition to that it takes a number of > >>>common failure causes into account before deciding to throw an exception. > >>> > >>>http://cr.openjdk.java.net/~robm/8159410/webrev.01/ > >>> > >>> -Rob > >> > > >
