[ntp:questions] NTP client basic
peter.martinez at btinternet.com
Mon Mar 5 11:38:53 UTC 2007
>From Peter Martinez:
Thanks to all for helpful coments. I think I can wrap this one up now. I
asked my Belgian friend to continue running my new SNTP client program with
the logging on, and send me the log. One interesting tell-tale event
consisted of a run of three spurious NTP response packets which arrived
within a few ms of each other, after evidently leaving the server within ms
of each other, but which had 'orig' timestamps from adjacent (5-minute
interval) requests. This surely places the source of the spurious repeats
very close indeed to the originator, perhaps in his PC, or his router, or at
the ISP end of the copper wire run. I have neither the resources nor the
inclination to chase that bug further.
A couple of academic final comments from me..
Although clearly a repeated NTP response is meaningless (there's no such
thing as 'old' time), you cannot deduce "the network should never repeat an
NTP packet". NTP is transported in UDP packets but UDP isn't aware of that.
There is no law which says UDP (or the levels below it) must not repeat
packets if they thought it was a good idea, and I can see that other uses
for UDP (eg DNS) would not malfunction if repeats occured. Classic
communication theory knows all about this - it's safe for me to use UDP to
say "my name is Peter" twice, but unsafe to for me to repeat "I owe you
$100", even if I thought you were a bit deaf!
RFC2030 isn't clear about this. It even says the inclusion of the
'time-of-origen' of the request is optional. The requestor can implement the
(t1-t1-t2+t4)/2 algorithm without sending t1, but he can't detect duplicates
without sending something unique like t1 and matching it in the response.
This lack of emphasis in RFC2030 may have been the reason why the NTP client
package I originally used, was not written well-enough to protect itself
from the situation I encountered in Belgium.
I learnt something this week.
More information about the questions