>From Peter Martinez: Per: Thanks for your remarks. I see that I should have written "SNTP" instead of "NTP" wherever this appears in my original posting. When I encountered this problem initially, the third-party SNTP client package I had used did indeed have the socket open continuously but only read it after sending a request, so if there had been a spurious reply earlier, it would thereafter read the reply to it's previous request! On seeing that it did this, I realised it was badly written, ditched it, and wrote my own, half hoping that this would also stop the repeats themselves (which in any case only show up in Belgium!)
When the repeats still appeared in my own SNTP client implementation (now trapped, but logged), it seemed to me that I might have stumbled on a possible source of trouble. RFC2030 didn't seem to say that you MUST take steps to discard repeats which COULD arise in the underlying UDP protocol, it seemed to be saying that you could keep an eye on the xmit timestamp in the request - but it's not essential. RFC768 (which describes UDP) doesn't shed any light on whether a corrupted UDP packet could be repeated. That's the only reason for raising the topic. I don't need any more help to achieve my own objective. I am just puzzled by what I see might be a flaw. Peter M _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
