Re: NTP client basic - NTP

This is a discussion on Re: NTP client basic - NTP ; >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. ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: NTP client basic

  1. Re: NTP client basic

    >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.

    regards
    Peter M

    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  2. Re: NTP client basic

    Peter Martinez wrote:
    >
    > 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!


    Peter,

    UDP is defined in RFC 768, see http://www.ietf.org/rfc/rfc768.txt for
    the full text. There is *no* provision at all for UDP sending packets on
    its own for *any* reason, especially as it has no idea whether or not it
    has been received by the recipient of the packet. The "U" in UDP also
    stands for "Unreliable" though technically it's supposed to stand for
    User. Since the sender has no way of knowing if the packet was received
    it has no way of deciding to send another packet. The protocol won't do
    it and that's intentional. If the protocol using it decides to send
    another packet that's a decision that the protocol definers that utilize
    it as a transport mechanism make. UDP does not send another packet and
    NTP doesn't do that either. If you want reliable protocol you use TCP.
    You *can* deduce that the network should never repeat since there is
    nothing in the network protocol that says that should be done. UDP is
    over 25 years old, and still going strong. Network retransmissions can
    occur because a node thought it hadn't been transmitted but they
    likelihood of that is becoming rarer and rarer with increasingly
    reliable networks.

    BTW, DNS will ignore duplicate packets as they are more likely to be
    spoofers, not because of retransmission.

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


+ Reply to Thread