Re: [ntp:questions] Trace ntp sanity checks?
In article [EMAIL PROTECTED], Richard B. Gilbert [EMAIL PROTECTED] wrote: The local clock driver is harmless as long as people configure it to stratum 10! This very thread demonstrates a case where it wasn't harmless! What has happened here appears to be that it has provided a much more attractive indication of the time than proper time sources. I'm not exactly sure why that is in this case, but, in other cases people have had more local clock derived sources than real sources, and, because the reference implementation claims zero root delay and zero root dispersion (because it assumes that the local clock is being disciplined by some other means, rather than free running), an upstream local clock can have a very low apparent error band, so it can be quite difficult for other sources to fall within the same cluster. The other basic problem is that downstream nodes don't receive any indication that they are disconnected from real time, whereas an alarm condition would be signalled by a server without a local clock driver. Note that using stratum 10 doesn't prevent these problems, it simply stops nodes that more than about 2 hops downstream from having problems from that particular local clock driver; it limits the area subject to harm. As to the urban myth. Whilst a lot of it is simply copy and paste programming, I think there is a significant myth that, without the local clock driver, the software clock will revert to its natural frequency, when it loses all time sources. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Any samples for NTP/SNTP client code?
Danny Mayer wrote: Jan Ceuleers wrote: This means that there is no need to allocate memory for constructing the reply packet, no need to copy data from received to transmitted packet, etc. This is also false. That's not what the code does. The recvbuf structure is not even the same size as the transmitbuf structure. I wasn't talking about the recvbuf and transmitbuf structures, but the socket receive and transmit buffers. Besides, transmitbuf appears to only exist in the Windows port. Jan ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] SNMP support
Does NTP include SNMP support (on Windows), and if not, are there any plans to add support? Thanks, David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] SNMP support
In article [EMAIL PROTECTED], David J Taylor [EMAIL PROTECTED] writes: David Does NTP include SNMP support (on Windows), and if not, are there any David plans to add support? I gather nobody has written the .whatever file to build the current sntp code under windows. We are (slowly) working on a new sntp client - no idea when it will be ready. -- Harlan Stenn [EMAIL PROTECTED] http://ntpforum.isc.org - be a member! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Source address in response always the same as target address in request?
Brian, I beg to differ with your beg to differ. RFC 768 requires that the UDP checksom includes the pseudo header, which itself contains the IP source and destination addresses. Technically speaking the addresses don't have to mean anything, but it would be pretty silly for a RPC server not to know how to return the goods to its client. Maybe you are talking about the socket interface, rather than the protocol data unit. I wasn't. Dave Brian Utterback wrote: I beg to differ. Most UDP based protocols do not have this requirement. If they did, it would not be the case that in the (mumble mumble) years since the invention of the UDP protocol and the sockets interface, that the interface even provided the ability for the application to to do this within the interface within the last few years. The UDP protocol itself has no such requirement. Although the Hosts requirements RFC says that a host SHOULD provide a mechanism to do it, until IPv6 came along, few systems actually did. The only way to guarantee it was using the awful bind every interface trick that the reference implementation uses. The RPC protocol itself (RFC 1050) does not have this requirement. I do not know why the original designers of UDP did not include this requirement. I suspect they did not foresee the security requirements we have today. Or perhaps they had a good reason. But in any case the NTPv3 spec does not have the requirement in it. If I recall correctly, the NTPv4 spec does have the requirement, but I also recall commenting on this ages ago, comments that were ignored. I don't disagree that UDP should have the requirement, but it does not, and as such I do object to gratuitously adding the requirement to NTP, which has complicated the code base to no end. Of course, as I said above, it is now possible to implement this cleanly on many OS's, which would allow us to simplify the code immensely. But until such support is universal, that won't happen. Brian David L. Mills wrote: Guys, In both the NTPv4 specification and reference implementation the destination address used by the client when mobilizeing the association and sending the request must match the source address when receiving the response. This is a property of all RPC protocols known to me that use addresses to match requests with responses. This is so obvious a requirement that maybe the specification doesn't make it clear enough. Dave Brian Utterback wrote: [EMAIL PROTECTED] wrote: Are there any clear requirements in NTP/SNTP RFC docs about the UDP source address in all responses the same as the UDP target address in the original requests? I doubt it would be a UDP requirement because this is domain of upper protocols. Yes and no. The basic protocol does not require it. The reference implementation does require it. The Autokey crypto authentication scheme currently requires it, but there has been some discussion recently about the nature of that requirement and whether it could be relaxed, but I don't see that discussion going anywhere in this regard. Brian Utterback ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Trace ntp sanity checks?
Hi, thank you very much for your responses. summary: you see no reason, why a ntp-client that does not serve its time to someone else should have a local clock configured? did i get this right? i will change my configuration and try that. does anyone of you have details regarding my original question: How can i find out which of the sanity-checks failed? regards Frank -Original Message- From: DE/SYS Routing - Linux, Team Sent: Friday, December 07, 2007 9:16 AM To: D1/OBT-ho Hornung, Frank; D1/OBT-ha Harle, Christoph Subject: FW: [ntp:questions] Trace ntp sanity checks? --- From: [EMAIL PROTECTED] on behalf of [EMAIL PROTECTED]:[EMAIL PROTECTED] VLID] Sent: Friday, December 07, 2007 8:56:31 AM To: questions@lists.ntp.org Subject: Re: [ntp:questions] Trace ntp sanity checks? Auto forwarded by a Rule In article [EMAIL PROTECTED], Richard B. Gilbert [EMAIL PROTECTED] wrote: The local clock driver is harmless as long as people configure it to stratum 10! This very thread demonstrates a case where it wasn't harmless! What has happened here appears to be that it has provided a much more attractive indication of the time than proper time sources. I'm not exactly sure why that is in this case, but, in other cases people have had more local clock derived sources than real sources, and, because the reference implementation claims zero root delay and zero root dispersion (because it assumes that the local clock is being disciplined by some other means, rather than free running), an upstream local clock can have a very low apparent error band, so it can be quite difficult for other sources to fall within the same cluster. The other basic problem is that downstream nodes don't receive any indication that they are disconnected from real time, whereas an alarm condition would be signalled by a server without a local clock driver. Note that using stratum 10 doesn't prevent these problems, it simply stops nodes that more than about 2 hops downstream from having problems from that particular local clock driver; it limits the area subject to harm. As to the urban myth. Whilst a lot of it is simply copy and paste programming, I think there is a significant myth that, without the local clock driver, the software clock will revert to its natural frequency, when it loses all time sources. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions ___ This E-Mail is confidential. If you are not the intended recipient, you must not copy, disclose or use its contents. If you have received it in error, please inform us immediately by return E-Mail and delete the document. Diese E-Mail ist vertraulich. Wenn Sie nicht der rechtmäßige Empfänger sind, dürfen Sie den Inhalt weder kopieren, verbreiten noch benutzen. Sollten Sie diese E-Mail versehentlich erhalten haben, senden Sie sie bitte an uns zurück und löschen sie anschließend. Cet e-mail est confidentiel. Si vous n'etes pas le destinataire de ce message, vous ne devez pas copier, divulguer ou utiliser le contenu. Si vous avez recu cet e-mail par erreur, veuillez nous informer en retournant ce message a l'expediteur et detruisez-le. Esta mensagem, e qualquer de seus anexos, eh confidencial e privilegiada. Caso voce nao seja o destinatario, nao esta autorizado a reproduzir ou divulgar a terceiros o conteudo desta mensagem e de qualquer anexo da mesma e deve apagar com os seus respectivos anexos. ___ ANDREAS STIHL AG Co. KG Kommanditgesellschaft mit Sitz in Waiblingen, HRA 260269, Amtsgericht Stuttgart Persönlich haftende Gesellschafter: Hans Peter Stihl und STIHL Aktiengesellschaft mit Sitz in Waiblingen, HRB 263722, Amtsgericht Stuttgart Vorstand der STIHL AG: Dr. Bertram Kandziora (Vorstandsvorsitzender), Dr. Peter Dürolf, Jürgen Steinhauser, Wolfgang Zahn Vorsitzender des Aufsichtsrats der STIHL AG: Hans Peter Stihl ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
