SNTP server + ntpd 4.2.4 client - NTP
This is a discussion on SNTP server + ntpd 4.2.4 client - NTP ; Danny Mayer wrote:
> Harlan Stenn wrote:
>
>>David> NTP clients must use NTP servers, not SNTP ones.
>>
>>I do not believe this is true.
>>
>
>
> Correct.
>
>
>>The problem is one might want to ...
-
Re: SNTP server + ntpd 4.2.4 client
Danny Mayer wrote:
> Harlan Stenn wrote:
>
>>David> NTP clients must use NTP servers, not SNTP ones.
>>
>>I do not believe this is true.
>>
>
>
> Correct.
>
>
>>The problem is one might want to *know* that the SNTP server is actually
>>talking to a refclock, or more generally, that the SNTP "instance" is
>>playing by the rules.
>>
>
>
> There is no way to ensure that. Furthermore there is nothing in the
> protocol which allows you to differentiate between the two. This is
> really a non-starter.
>
> Danny
I can't say it's worth doing but you could always add some sort of a tag
to the NTP packet that says "I am an NTP server" or "I am an SNTP Server
with a reference clock" or "I am an SNTP leaf node and I'm not supposed
to talk to you"
-
Re: SNTP server + ntpd 4.2.4 client
"Richard B. Gilbert" writes:
>Danny Mayer wrote:
>> Harlan Stenn wrote:
>>
>>>David> NTP clients must use NTP servers, not SNTP ones.
>>>
>>>I do not believe this is true.
>>>
>>
>>
>> Correct.
>>
>>
>>>The problem is one might want to *know* that the SNTP server is actually
>>>talking to a refclock, or more generally, that the SNTP "instance" is
>>>playing by the rules.
>>>
>>
>>
>> There is no way to ensure that. Furthermore there is nothing in the
>> protocol which allows you to differentiate between the two. This is
>> really a non-starter.
>>
>> Danny
>I can't say it's worth doing but you could always add some sort of a tag
>to the NTP packet that says "I am an NTP server" or "I am an SNTP Server
>with a reference clock" or "I am an SNTP leaf node and I'm not supposed
>to talk to you"
Look, an SNTP client is not supposed to act as a server. Period. If it does
it means whoever programmed it broke the rules. Do you really thing having
him program in an extra flag saying "I did not break the rules" is going to
do anything? It is the same person who programmed it in the first place who
also programs what it sends out in the packet.
An sntp client is not supposed to respond to server requests. You want it
to respond. Why? I would think that the "flag" of no-response is far more
effective than some bit in the packet.
-
Re: SNTP server + ntpd 4.2.4 client
>>> In article <47E51FF4.8030708@comcast.net>, "Richard B. Gilbert" writes:
Richard> Danny Mayer wrote:
Harlan> The problem is one might want to *know* that the SNTP server is
Harlan> actually talking to a refclock, or more generally, that the SNTP
Harlan> "instance" is playing by the rules.
Danny> There is no way to ensure that. Furthermore there is nothing in the
Danny> protocol which allows you to differentiate between the two. This is
Danny> really a non-starter.
What is the "non-starter" Danny?
Richard> I can't say it's worth doing but you could always add some sort of
Richard> a tag to the NTP packet that says "I am an NTP server" or "I am an
Richard> SNTP Server with a reference clock" or "I am an SNTP leaf node and
Richard> I'm not supposed to talk to you"
It's already been done. It's called the NTP RFC. The "stratum" tells you
this.
What difference does it make if somebody blows the stratum code v. somebody
blows the code to say "believe me when I tell you that I am an NTP server"?
--
Harlan Stenn
http://ntpforum.isc.org - be a member!
-
Re: SNTP server + ntpd 4.2.4 client
Unruh wrote:
> "Richard B. Gilbert" writes:
>
>> Danny Mayer wrote:
>>> Harlan Stenn wrote:
>>>
>>>> David> NTP clients must use NTP servers, not SNTP ones.
>>>>
>>>> I do not believe this is true.
>>>>
>>>
>>> Correct.
>>>
>>>
>>>> The problem is one might want to *know* that the SNTP server is actually
>>>> talking to a refclock, or more generally, that the SNTP "instance" is
>>>> playing by the rules.
>>>>
>>>
>>> There is no way to ensure that. Furthermore there is nothing in the
>>> protocol which allows you to differentiate between the two. This is
>>> really a non-starter.
>>>
>>> Danny
>
>> I can't say it's worth doing but you could always add some sort of a tag
>> to the NTP packet that says "I am an NTP server" or "I am an SNTP Server
>> with a reference clock" or "I am an SNTP leaf node and I'm not supposed
>> to talk to you"
>
> Look, an SNTP client is not supposed to act as a server. Period. If it does
> it means whoever programmed it broke the rules. Do you really thing having
> him program in an extra flag saying "I did not break the rules" is going to
> do anything? It is the same person who programmed it in the first place who
> also programs what it sends out in the packet.
> An sntp client is not supposed to respond to server requests. You want it
> to respond. Why? I would think that the "flag" of no-response is far more
> effective than some bit in the packet.
I'm going to need to point you to the RFC draft for the definition of an
SNTP server. However, no RFC will prevent anyone from writing code that
allow an SNTP client also serving that time to other clients. The
Internet police just aren't up to the task. That's the difference
between an RFC and reality.
Danny
-
Re: SNTP server + ntpd 4.2.4 client
Harlan Stenn wrote:
>>>> In article <47E51FF4.8030708@comcast.net>, "Richard B. Gilbert" writes:
>
> Richard> Danny Mayer wrote:
>
> Harlan> The problem is one might want to *know* that the SNTP server is
> Harlan> actually talking to a refclock, or more generally, that the SNTP
> Harlan> "instance" is playing by the rules.
>
> Danny> There is no way to ensure that. Furthermore there is nothing in the
> Danny> protocol which allows you to differentiate between the two. This is
> Danny> really a non-starter.
>
> What is the "non-starter" Danny?
>
That there's a way of telling the difference. The RFC only tells you
want you need to send in the packet. It says nothing about identifying
the type of server and you have no way of probing it for that answer.
> Richard> I can't say it's worth doing but you could always add some sort of
> Richard> a tag to the NTP packet that says "I am an NTP server" or "I am an
> Richard> SNTP Server with a reference clock" or "I am an SNTP leaf node and
> Richard> I'm not supposed to talk to you"
>
> It's already been done. It's called the NTP RFC. The "stratum" tells you
> this.
>
The stratum is what the server says it is. Why else would Microsoft have
their time servers that claim that they are all stratum 2 servers?
They are not even NTP servers.
> What difference does it make if somebody blows the stratum code v. somebody
> blows the code to say "believe me when I tell you that I am an NTP server"?
Nothing. That's why you cannot differentiate between them and that's why
it's a nonstarter.
Danny
-
Re: SNTP server + ntpd 4.2.4 client
Noob wrote:
> Unruh wrote:
>
>> SNTP is a client protocol, not a server, according to RFC.
>
> You keep saying that. Which RFC are you referring to?
>
SNTP is defined in the NTPv4 draft in
http://www.ietf.org/internet-drafts/...4-proto-09.txt in
section 14. You can also look at RFC 4330 but that's about to be
obsoleted by the NTPv4 draft. SNTP is *not* a client protocol.
>> We have absolutely no idea what you are running on all your machines. You
>> never told us. This was an assumption based on the weird conditions you
>> stated. It really really helps if you give information when you ask for
>> help so that the help may actually be helpful. Tell us what your system is,
>> what "SNTP program" you are using as the server, what the other client
>> machines on the lan are running.
>
> The only client is an x86 PC running Linux 2.6.22.1-rt9 (i.e. with
> real-time extensions) and ntpd 4.2.4p0@1.1472.
>
> The server is an embedded device (HEOL-T101) with a GPS receiver and a
> Fast Ethernet port. I have no idea what operating system runs on the
> device; there might not even be an OS. The manufacturer claims the
> device implements SNTPv4 instead of the full NTP.
>
> ( http://www.heoldesign.com/index.php?id=58 )
>
Since it hads a GPS receiver in it, it only needs the SNTP part of the
spec and be an SNTP server. See the NTPv4 draft.
Danny
-
Re: SNTP server + ntpd 4.2.4 client
Danny Mayer wrote:
> SNTP is defined in the NTPv4 draft in section 14. You can also look
> at RFC 4330 but that's about to be obsoleted by the NTPv4 draft.
Thanks for the pointer.
The HTML version of the draft adds incremental diffs.
http://tools.ietf.org/html/draft-iet...ntpv4-proto-09
-
Re: SNTP server + ntpd 4.2.4 client
Richard B. Gilbert wrote:
> I can't say it's worth doing but you could always add some sort of a tag
> to the NTP packet that says "I am an NTP server" or "I am an SNTP Server
> with a reference clock" or "I am an SNTP leaf node and I'm not supposed
> to talk to you"
No need for that. The SNTP client should just ignore incoming packets
that it didn't send. Only server mode and broadcast mode packets are valid.
Danny
-
Re: SNTP server + ntpd 4.2.4 client
"Unruh" wrote in message
news:RHcFj.95365$FO1.58226@edtnps82...
[...]
> Look, an SNTP client is not supposed to act as a server. Period.
Unless... its clock is disciplined by means external to NTP.
For example, by a reference clock. Not all reference clocks must
necessarily be NTP servers; there are other ways to use them to
make sure that some clock in the next computer over runs Very Close
to UTC.
It has been said right here that many if not most of the black box
stratum-1 servers operate by the exact mechanism you condemn: an
SNTP client polling a local refclock at some suitably short interval,
presumably with a simple feedback loop but without the full NTP and
its higher math & other assorted magic.
Groetjes,
Maarten Wiltink
-
Re: SNTP server + ntpd 4.2.4 client
Harlan Stenn wrote:
>
> Richard> I can't say it's worth doing but you could always add some sort of
> Richard> a tag to the NTP packet that says "I am an NTP server" or "I am an
> Richard> SNTP Server with a reference clock" or "I am an SNTP leaf node and
> Richard> I'm not supposed to talk to you"
>
> It's already been done. It's called the NTP RFC. The "stratum" tells you
> this.
Note that Microsfoft's "SNTP" implementation claims stratum 2, when
acting as an a server with an illegal time source.
-
Re: SNTP server + ntpd 4.2.4 client
On Mar 25, 7:21*am, David Woolley
wrote:
> Note that Microsfoft's "SNTP" implementation claims stratum 2, when
> acting as an a server with an illegal time source.
This is not true in Windows 2003 and newer. Considering that Windows
2000 sales ended in 2003, and mainstream support ended in 2005, I
think your statement needs qualification.
Windows Time Service (w32time) is an RFC-1305-compliant NTP (not
SNTP!) implementation, and has been for 5 years or more. It reports
the correct statum, has the clock discipline algorithms, etc. Yes, it
has some limitations (precision is -6), and is easy to mis-configure
(so is ntpd), but it mostly just works. I advise most of my clients to
use it rather than messing with the complexity of ntpd on Windows if
possible.
I know a lot of people hate MSFT, but let's not let that get in the
way of the actual facts. Not everyone can or should run the reference
ntpd implementation. There will always be other commercial and open
source implementations of the NTP and SNTP protocols. This is a very
good thing from a security perspective, and also from a competitive
perspective. Would we have the pool scheme in the development versions
of ntpd now if OpenNTPD hadn't implemented it first?
-
Re: SNTP server + ntpd 4.2.4 client
Ryan Malayter wrote:
> This is not true in Windows 2003 and newer. Considering that Windows
Depends on the service pack. I believe it was finally fixed about two
years ago. The reference implementation is still better.
> 2000 sales ended in 2003, and mainstream support ended in 2005, I
> think your statement needs qualification.
But noting that Windows XP support life has been extended because users
refused to move to Vista.
-
Re: SNTP server + ntpd 4.2.4 client
On 2008-03-25, Ryan Malayter wrote:
> On Mar 25, 7:21*am, David Woolley wrote:
>
>> Note that Microsfoft's "SNTP" implementation claims stratum 2, when
>> acting as an a server with an illegal time source.
>
> This is not true in Windows 2003 and newer. Considering that Windows
> 2000 sales ended in 2003, and mainstream support ended in 2005, I
> think your statement needs qualification.
>
> Windows Time Service (w32time) is an RFC-1305-compliant NTP (not
> SNTP!) implementation, and has been for 5 years or more.
We all now how long older versions of Windows remain in service well
past the EOL.
What _version_ of w32time is RFC-1305 compliant?
> Would we have the pool scheme in the development versions of ntpd now
> if OpenNTPD hadn't implemented it first?
Really? They did?
Are you sure that the person who wrote the pool configuration directive
code for the Reference Implementation of NTP pays any attention to
OpenNTPD?
--
Steve Kostecke
NTP Public Services Project - http://support.ntp.org/
-
Re: SNTP server + ntpd 4.2.4 client
"Steve Kostecke" wrote in message
news:slrnfui44t.cui.kostecke@stasis.kostecke.net.. .
> On 2008-03-25, Ryan Malayter wrote:
[...]
>> Would we have the pool scheme in the development versions of ntpd
>> now if OpenNTPD hadn't implemented it first?
>
> Really? They did?
The NTP Pool was implemented at first as a bunch of public NTP servers,
with clever use of DNS to make it work. The point I'm trying to make is
that it worked before and without any NTP implementation knowing about
it.
It does work better when the NTP client is aware of the need to
re-resolve hostnames under certain circumstances, but those same
circumstances occur outside the pool, just not as often or as pressing.
Groetjes,
Maarten Wiltink
-
Re: SNTP server + ntpd 4.2.4 client
"Maarten Wiltink" writes:
>"Unruh" wrote in message
>news:RHcFj.95365$FO1.58226@edtnps82...
>[...]
>> Look, an SNTP client is not supposed to act as a server. Period.
>Unless... its clock is disciplined by means external to NTP.
>For example, by a reference clock. Not all reference clocks must
>necessarily be NTP servers; there are other ways to use them to
>make sure that some clock in the next computer over runs Very Close
>to UTC.
>It has been said right here that many if not most of the black box
>stratum-1 servers operate by the exact mechanism you condemn: an
>SNTP client polling a local refclock at some suitably short interval,
>presumably with a simple feedback loop but without the full NTP and
>its higher math & other assorted magic.
The problem with netnews-- your mistakes far outlive your recognition that
you have made a mistake. Yes, I have admitted that I was out and out wrong.
Period. You are perfectly correct.
-
Re: SNTP server + ntpd 4.2.4 client
On Mar 25, 9:47*am, Steve Kostecke wrote:
> What _version_ of w32time is RFC-1305 compliant?
Microsoft's documentation indicates that all versions of w32time in
Windows 2003 are RFC-1305 compliant. I know from testing that the
versions in Windows 2003 SP1 (releleased March 30 2005) and later are
RFC-1305 compliant when configured properly. I did not test the RTM
version of Windows 2003.
> > Would we have the pool scheme in the development versions of ntpd now
> > if OpenNTPD hadn't implemented it first?
> Really? They did?
Yes, they did, back in 2004. See the "servers" keyword:
http://www.openbsd.org/cgi-bin/man.c...86&format=html
> Are you sure that the person who wrote the pool configuration directive
> code for the Reference Implementation of NTP pays any attention to
> OpenNTPD?
No, I am not sure. But I do recall the OpenNTPD "servers" keyword
being mentioned on the NTP Pool project mailing list long before the
"pool" directive appeared in the development versions NTPD.
Shouldn't any software developer be looking at other solutions in the
same problem space for ideas? Especially in an open souce world?
--
RPM