[ntp:questions] Re: requestor's time; transmit timestamp?

roy roy at suespammers.org
Mon Nov 28 03:31:47 UTC 2005


Dirk Claessens wrote:
> Verily, on Sun 27 Nov 2005 01:24:58a, Nelson Minar wrote in
> comp.protocols.time.ntp
> [news:cpairufos2v.fsf at cabernet.nelson.monkey.org]:
>
> > In an NTP request which timestamp carries the requestor's notion
> > of what time it is?
> >
>
> I ran into the same problem, a couple of months ago, because of this
> definition in RFC 958:
>
> <quote>
> Transmit Timestamp
>
>       This is a 64-bit timestamp established by the server host and
>       specifying the local time at which the reply departed for the
>       client host.  If no request has ever arrived from the client the
>       value is zero.
> </>
>
> I should have also read RFC2030, which says:
>
>    To calculate the roundtrip delay d and local clock offset t relative
>    to the server, the client sets the **transmit timestamp** in the request
>    to the time of day according to the client clock in NTP timestamp
>    format. The server copies this field to the originate timestamp in
>    the reply and sets the receive timestamp and transmit timestamp to
>    the time of day according to the server clock in NTP timestamp
>    format.
>
There is at least one implementation that does not conform to this
convention.  Instead of sending the local time in the transmitt
timestamp, OpenNTPD sets it to a random 64-bit cookie.  See
http://unduli.bsws.de/papers/21c3/mgp00052.html

So, if the client is OpenNTPD, the NTP server (and anything else
looking at the packets) is unable to determine the time of the client
system.


roy




More information about the questions mailing list