Dirk Claessens wrote: > Verily, on Sun 27 Nov 2005 01:24:58a, Nelson Minar wrote in > comp.protocols.time.ntp > [news:[EMAIL PROTECTED]: > > > 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 _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
