Re: [ntp:questions] ntp pool servers disappear - more data

[Danny Mayer]

On 6/25/21 12:10 PM, William Unruh wrote:

You could try specifying the server by IP rather than by name, so DNS is
not needed. Of course this rule out using pool, unless you put them in
by IP. DNS is just used to translate names to IP, so if you use IP, then
DNS is not needed.


We strongly discourage that unless you own the IP address. Owners of the 
servers have the right to change the system to use for NTP as well as 
remove it from service altogether. We've had IP addresses bombarded at 
high rates for years when a formerly active server has been taken out of 
service.


Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntp pool servers disappear

[Danny Mayer]

On 6/24/21 11:22 AM, Jim Pennino wrote:

Maybe it should, and I think it should, but it doesn't.

Where do I file this bug report?


https://bugs.ntp.org


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntp pool servers disappear

[Danny Mayer]

On 6/23/21 10:26 AM, Jim Pennino wrote:

It seems that any server in ntp.conf that is specified as a name, as
the pool servers are, will after a sufficiently long DNS outage just
disappear and not come back after the outage without restarting ntp.

It would seem to me that ntp should only need to do a DNS lookup on
startup and from then on continue to use the address found.

But that is not how ntp works.


No, you shouldn't assume that once you have an IP address you can decide 
to use it forever. The owner of any server has the right to change the 
DNS entry used to point to a different server. We have had no end of 
problems with clients bombarding an IP address with packets long after 
it has stopped serving time.


If you have a DNS issue then you should address that. ntpd should pick 
up new addresses if one is available. If it doesn't do that please file 
a bug report.


Danny


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP packets with MACs longer than SHA1

[Danny Mayer]

On 3/12/19 4:22 AM, Miroslav Lichvar wrote:
> On 2019-03-11, Nelson Bolyard  wrote:
>> NTPv3 supported MD5 and SHA1 Message Authentication Code (MACs) of
>> length 16 and 20 bytes respectively.  RFC 5906 says that NTP V4
>> supports any MAC, but offers no advice about how to send MACs that are
>> longer than 20 bytes, such as SHA256 MACs.
>>
>> Are longer MACs sent in their entirety?
>> Are they truncated to 20 bytes? or to 16 bytes?
> The digests are truncated to 20 bytes in order to follow RFC 7822.
>
Actually it says that they can be no longer than 24 unless otherwise
negotiated by client and server. See Section 7.5.1.3. In the
introduction it says it can be 20 or 24 bytes.

Danny


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP Support SHA2 or not

[Danny Mayer]

Sorry for the delay in responding. No, it doesn't work right now. I did
test this out several years ago but the problem with SHA2 is the length
of the resultant hash. There's no problem creating and sending such a
MAC but the other side needs to be changed to be able to properly handle
the resulting MAC. There are plans to change the code to properly deal
with this and other types of hashing algorithms.

Danny

On 10/8/18 2:29 AM, Sharma12, Sachin wrote:
> Hi,
>
> We are using ntp-4.2.6p5-28.el7, Please let us know whether the NTP support 
> SHA2 with FIPS enable and disable?
>
> If not then please let us know when NTP support for SHA2 in future release?
>
> Regards
> Sachin
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
>
>

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntp.4.2.8 not supporting sha1

[Danny Mayer]

On 12/9/2016 1:20 AM, sneha b wrote:
> Hi All,
> 
> I am building ntp.4.2.8, source code I got from ntp.org.
> We have openssl1.0.2, but the ntpd.exe is not supporting sha1.
> Its only supporting MD5 till key id 10.
> Can some one point me what are all the openssl libraries needed for
> supporting SHA1 and also openssl version is correct.
> 

Make sure you put it in your keys file in upper case SHA1. I'm not sure
we are checking case or forcing it to uppercase. I've been building on
OpenSSL 1.0.1j and it works fine. What does the line in your keys file
look like? (You can  out the salt). What do you mean by key id 10?
what does the logs say during startup? Did you specify the keyid as a
trustedkey or if for control the requestkey or controlkey? Your report
is a bit vague.

> OS I am testing on is windowss7.
> 

yep. Works for me on both 32-bit and 64-bit Windows.

Danny


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Weak Security algorithms used in NTP Autokey protocol

[Danny Mayer]

On 3/21/2016 12:11 PM, Joe Smithian wrote:
> H All,
> 
> I am surprised that NTP still supports insecure algorithms such as MD2, MD5
> and small key sizes  256,512,1024 in the Autokey authentication! Any plan
> to deprecate weak algorithms and add more secure algorithms such as SHA-2
> and SHA-3?
> 

Yes, although autokey is going to be replaced by NTS. The code needs to
be upgraded so that it can figure out whether or not it has a MAC and if
so how big it is.

> 
> Below is a list of supported keys and algorithms in ntp-keygen version
> 4.2.8p6
> 
> 
> ntp-keygen(8) - Linux man pageName
> 
> ntp-keygen - generate public and private keys
> 
> Synopsis
> 
> *ntp-keygen [ -deGgHIMPT ] [ -c [RSA-MD2 | RSA-MD5 | RSA-SHA | RSA-SHA1 |
> RSA-MDC2 | RSA-RIPEMD160 | DSA-SHA | DSA-SHA1 ] ] [ -i name ] [
> -m modulus ] [ -p password ] [ -q password ] [ -S [ RSA | DSA ] ] [
> -s name ] [ -vnkeys ] [ -V params ]*

We should aim to handle whatever algorithm becomes available, currently
whatever OpenSSL has for digests at any particular version. Note that
both ends need to understand the same algorithm for that to work.

Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Authenticated time

[Danny Mayer]

On 2/29/2016 3:20 AM, Juhasz Gabor wrote:
> Hi All,
> 
> I am newbie in NTP world so it is possible that my question
> has been already answered. Sorry for it.
> 
> The latest openNTP (openntpd-5.7p4) contains a very
> useful feature: CONSTRAINTS
> 
> openntpd.conf.5:
> 
> "openntpd(8) can be configured to query the ‘Date’ from trusted
> HTTPS servers via TLS. This time information is not used
> for precision but acts as an authenticated constraint, thereby
> reducing the impact of unauthenticated NTP man-in-the-middle
> attacks. Received NTP packets with time information falling
> outside of a range near the constraint will be discarded and
> such NTP servers will be marked as invalid."

RFC2616 Section 14.18 talks about the Date field in the http header.
What it does NOT guarantee is that the date is correct or valid for any
purpose. It does state that it is the date and time that the message was
originated but there is nothing to say that it is valid. Neither HTTPS
nor TLS guarantee that. In fact if the clock was off by 2 years, as long
as the relevant certificates in the certificate change were valid at
that time it would allow the TLS protocol to complete and you'd get that
date in the header. Not only that you have no idea how reliable it is,
how much jitter there is what the root delay or dispersion is, whether
it is coasting along or using a valid NTP server. Where does the trusted
part come from? This is one of those ideas that look good on the outside
but fail to solve the problem that you think you are solving. ntpd will
not let the clock move too far (except during startup if you override
the panic gate).

How will this proposal make ntpd better?

Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Idea to improve ntpd accuracy

[Danny Mayer]

On 2/25/2016 10:29 PM, Weber wrote:
> Thanks for the link. I'm not surprised that someone else already had the
> idea. I was poking around and see that 1588 does something similar with
> a "follow up" packet.
> 

I should have mentioned that this checksum trailer extension field is
needed to get the idea to work for NTP. Unfortunately you can't have
security or a MAC to do this as it needs to make changes to the
timestamps and then add the extension field to fix the UDP checksum. Tal
can say more.

Danny
> 
> On 2/25/2016 7:09 PM, Danny Mayer wrote:
>> Already thought of so it's a good idea! See
>> https://datatracker.ietf.org/doc/draft-ietf-ntp-checksum-trailer/ for
>> details.
>>
>> Danny
>>
>> On 2/25/2016 4:52 PM, Weber wrote:
>>> This may or may not be worthwhile, but I thought I'd throw it out there
>>> and see what happens:
>>>
>>> Recent work testing some microsecond-accurate NTP servers lead me to an
>>> idea that could improve accuracy of measurements made by ntpd. These NTP
>>> servers have hardware timestamps on receive but that's not possible on
>>> transmit w/o a custom NIC. I've seen this issue discussed before.
>>>
>>> The next best thing is to generate the transmit timestamp based on a
>>> guess as to how long it takes the NIC to get on the wire and send the
>>> packet. That works pretty well as long as there's no other network
>>> traffic. In this situation, it is possible to make use of microsecond
>>> accuracy in an NTP server.
>>>
>>> Now, add some typical network traffic and the time it takes the NIC to
>>> get on the wire becomes unpredictable to the tune of 200us or more (for
>>> 100 base-T Ethernet). The server's microsecond accuracy is largely lost
>>> in the noise.
>>>
>>> The NIC generates an interrupt after the packet is sent which can result
>>> in a fairly accurate trailing hardstamp. The problem is...the packet is
>>> already gone and has the wrong transmit timestamp.
>>>
>>> Here's my idea:
>>>
>>> What if the poll response packet contained a flag or indication of some
>>> sort which means "this is an approximate transmit timestamp". That
>>> packet would then be immediately followed by a second response packet
>>> with a more accurate transmit time. The second packet could be otherwise
>>> identical to the first, or it could be a new flavor of packet that
>>> contained only the transmit time (that would save on network bandwidth).
>>>
>>> The ntpd process would need to use the receive time of the first packet
>>> (the one with an approximate tx timestamp) and merge in the following
>>> accurate tx timestamp before performing the normal processing associated
>>> with a poll response.
>>>
>>> Here are the pros and cons I can think of:
>>>
>>> Pros
>>>
>>> * Possible accuracy improvement of 1-2 orders of magnitude. I know ntpd
>>> already does some work to try and filter out network delay variation so
>>> the improvement might not be a full 2 orders of magnitude.
>>> * Could potentially be made compatible backwards compatible with ntp 3/4
>>> protocols
>>>
>>> Cons
>>>
>>> * Increased network traffic
>>> * Improvement to that level of accuracy might not be of interest to
>>> anyone
>>> * Could be a fair bit of work for at least a couple of folks
>>> * I may have (or probably) missed some stuff regarding network behavior
>>> that would reduce the level of improvement that could be realized.
>>> * Perhaps this is less of an issue on G-bit Ethernet?
>>>
>>> Wondering if anyone thinks this idea is worth pursuing further...?
>>
>>
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
> 
> 

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Idea to improve ntpd accuracy

[Danny Mayer]

Already thought of so it's a good idea! See
https://datatracker.ietf.org/doc/draft-ietf-ntp-checksum-trailer/ for
details.

Danny

On 2/25/2016 4:52 PM, Weber wrote:
> This may or may not be worthwhile, but I thought I'd throw it out there
> and see what happens:
> 
> Recent work testing some microsecond-accurate NTP servers lead me to an
> idea that could improve accuracy of measurements made by ntpd. These NTP
> servers have hardware timestamps on receive but that's not possible on
> transmit w/o a custom NIC. I've seen this issue discussed before.
> 
> The next best thing is to generate the transmit timestamp based on a
> guess as to how long it takes the NIC to get on the wire and send the
> packet. That works pretty well as long as there's no other network
> traffic. In this situation, it is possible to make use of microsecond
> accuracy in an NTP server.
> 
> Now, add some typical network traffic and the time it takes the NIC to
> get on the wire becomes unpredictable to the tune of 200us or more (for
> 100 base-T Ethernet). The server's microsecond accuracy is largely lost
> in the noise.
> 
> The NIC generates an interrupt after the packet is sent which can result
> in a fairly accurate trailing hardstamp. The problem is...the packet is
> already gone and has the wrong transmit timestamp.
> 
> Here's my idea:
> 
> What if the poll response packet contained a flag or indication of some
> sort which means "this is an approximate transmit timestamp". That
> packet would then be immediately followed by a second response packet
> with a more accurate transmit time. The second packet could be otherwise
> identical to the first, or it could be a new flavor of packet that
> contained only the transmit time (that would save on network bandwidth).
> 
> The ntpd process would need to use the receive time of the first packet
> (the one with an approximate tx timestamp) and merge in the following
> accurate tx timestamp before performing the normal processing associated
> with a poll response.
> 
> Here are the pros and cons I can think of:
> 
> Pros
> 
> * Possible accuracy improvement of 1-2 orders of magnitude. I know ntpd
> already does some work to try and filter out network delay variation so
> the improvement might not be a full 2 orders of magnitude.
> * Could potentially be made compatible backwards compatible with ntp 3/4
> protocols
> 
> Cons
> 
> * Increased network traffic
> * Improvement to that level of accuracy might not be of interest to anyone
> * Could be a fair bit of work for at least a couple of folks
> * I may have (or probably) missed some stuff regarding network behavior
> that would reduce the level of improvement that could be realized.
> * Perhaps this is less of an issue on G-bit Ethernet?
> 
> Wondering if anyone thinks this idea is worth pursuing further...?


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] How to specify interface for multicastclient

[Danny Mayer]

On 1/13/2016 4:30 PM, brian utterback wrote:
> I am sure this has been asked before but I can't find the answer. On a
> multihomed system, is there anyway to specify which interfaces you want
> multicastclient to listen on? If so, how. If not, why not? I would have
> expected it to listen on all interfaces, but it doesn't do that.
> 

Unfortunately no. The server tries to figure out which interface to use
and sometimes it's wrong. I've had development code to allow admins to
specify in the config file where to listen but that's not in the current
code and I'd need to rework it to get it in there. I'm not sure you can
bind more than one interface to a multicast address as you are asking as
I don't think that the O/S would allow it. Does Solaris all something
like that?

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] IPv6 link local

[Danny Mayer]

On 12/16/2015 9:08 PM, Danny Mayer wrote:
> On 12/16/2015 4:45 PM, Greg Dowd wrote:
>> Does open source ntpd support using IPv6 link local addresses for 
>> client/server/peer modes?  I have not been able to use link local addresses 
>> to peer 2 servers on the same subnet.
>>
>> Thanks...Greg
> 
> It's supposed to work. Did you set up anything in the conf file that
> might restrict it or force IPv4 addresses?

Can you add -D2 to the command line and see if it transmits to the
link-local address? you should see a transmit line in the output. Also
can you do this for both systems? If it's receiving the packet it should
see it in the receive line in the output. Also does ntpq work with
pointing to the other system using the link-local address. Finally does
the switch on the LAN work with IPv6? Just checking.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] IPv6 link local

[Danny Mayer]

On 12/16/2015 4:45 PM, Greg Dowd wrote:
> Does open source ntpd support using IPv6 link local addresses for 
> client/server/peer modes?  I have not been able to use link local addresses 
> to peer 2 servers on the same subnet.
> 
> Thanks...Greg

It's supposed to work. Did you set up anything in the conf file that
might restrict it or force IPv4 addresses?

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Reargding ntp (ntp 4.2.8 or higher) on Wince /WEC 2013

[Danny Mayer]

On 8/31/2015 1:18 PM, Sowmya Manapragada wrote:
> Hello All,
> I am trying to use ntp  (ntp-4.2.8 in specific) on wince environment. Just
> wanted to check if anybody compiled ntpd for wince (Windows embedded
> compact-2013 in specific). I am trying compiling, but I see lots of errors
> on open-ssl front. Any information will help.
> 

ntpd will only run on NT technology O/S's because of the library
functions being used. OpenSSL is pretty straightforward to compil.

Danny

> Thanks a lot
> Shyam

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntp-4.2.8p1 ntpd unable to start as service

[Danny Mayer]

On 4/2/2015 7:18 PM, Naren P wrote:
> Hello All,
> I was able to build ntp-4.2.6p5 dated 24-DEC-2011 with openssl-1.0.2a using
> VS2008 and use the same under windows 7 x64 environment without any issues.
> 
> But, when I build ntp-4.2.8p1 dated 04-Feb-2015 with openssl-1.0.2a using
> VS2008 or VS2013 x32 or x64 bit and attempt to use the same under windows 7
> x64 environment, I see the following error:
> 
> ntpd -g -N -c ntp.conf
> ntpd: unable to start as service:
> The service process could not connect to the service controller.
> Use -d, -q, -n, -?, --help or --saveconfigquit to run interactive.
> 
> There do not seem to be any changes in the ntpd arguments for the ones I am
> attempting to use.
> Could you please help me understand, what I am missing?
> 

The binary is not installed as a service. How did you set up the service?

Danny

> -NVAP
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
> 
> 

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP 4.2.8 for Windows, not branded

[Danny Mayer]

On 1/12/2015 3:24 AM, Guy wrote:
> Brian Inglis wrote:
> 
 On 2015-01-10 11:13, Martin Burnicki wrote:

> Please note that beside the NTP binaries you also need the
> openssl DLL in the version against which the binaries have been
> built, otherwise ntpd fails to  start.

> 
> 
>   "...an application compiled and dynamically linked
>with 1.0.0 does not need to be recompiled when the
>shared library is updated to 1.0.2."[1]
> 
> 
>> Or could the current OpenSSL version be made a command line and/or
>> config parameter of ntpd, to allow updating without rebuilding?
>>
> 
> 
> If you feel you have need to update OpenSSL,
> you may simply 'drop-in' the binaries.

While this may be seem to be true I have found that the link ID's don't
always match so you should always go with the dll of the library you
linked with.

Please stop using the ntp.org name in your reply-to:
Reply-To: g...@lists.ntp.org, , a...@lists.ntp.org,
guysal...@lists.ntp.org, d...@lists.ntp.org, t...@lists.ntp.org

None of these are valid nor are they for you to use.

Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP 4.2.8 for Windows, not branded

[Danny Mayer]

On 1/10/2015 10:08 AM, trackeroft...@gmail.com wrote:
>> Assuming it's something like 4.2.8p1-beta5:
>>
>> 4.2.8P1BetaN are newer than 4.2.8 but they're not release candidates like
>> 4.2.8.pN-RCm will be.
>>
>> You can see the 4.2  releases here: .
> 
> Thanks Paul for the explanation. Now it is clear. RCm is pre, betaM is post. 
> So now the version can be defined by 4 digits: x.y.zpN.
> Where can I find changelog for the p1 and betas?
> I can't find it here:
> http://archive.ntp.org/ntp4/ntp-4.2/NEWS
> 
> best regards
> Johny

There was a last minute change to the code before the release of NTP
4.2.8 and as a result it didn't build on Windows. The beta's are mainly
to fix the problem with the Windows build. 4.2.8p1 should be released in
a week or so as soon as we can be sure that it is working properly.

To correct your above statement, beta's are prior to Release Candidates
(RC).

Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Thoughts on KOD

[Danny Mayer]

On 7/7/2014 10:08 AM, Jason Rabel wrote:
> Has that *always* been the case? Or has the code be changed over time?
> 

I'm not sure how far back this goes. I can try and find out. I do
remember the discussion I had with Dave Mills on this but that was just
a couple of years ago. I will need to find the code that does this and
dig into the archives for this one.

> Remember, not everyone is running the latest development (or even stable) 
> version of NTP... 
> 

Yep. But this is not a recent development.

>> KOD already sets a timestamp that is the requesters timestamp. See my
>> previous response. It's better than your idea since it is gradual.
>>
>> Danny
> 

Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Thoughts on KOD

[Danny Mayer]

On 7/6/2014 7:22 AM, Jan Ceuleers wrote:
> On 07/06/2014 11:23 AM, Rob wrote:
>> Jan Ceuleers  wrote:
>>> I recommend providing motivation for the undesired clients to stop using
>>> the server, by the server sending a regular response indicating that it
>>> is not synchronised or replying in some other way that has no
>>> timekeeping value to the offending client.
>>
>> Well, that is what KOD actually is.
> 
> Sorry, I was not clear. By a 'regular' response I mean one that has a
> non-zero stratum value. I had actually forgotten that a stratum value of
> zero indicates that the server is not synchronised (as it is a collision
> with LI=3, which also means that).
> 
> So I guess I'm dropping my first suggestion.
> 
> The second-one stands: pick a non-zero stratum value and report an
> immutable time stamp. Note that the stratum field occupies 8 bits in the
> packet format, but currently only values between 0 and 15 are defined
> (where we have seen that a value of 0 is not uniformly understood by
> real-life clients). So the choice of stratum value should be in the
> range 1-15.
> 
> I have no particular preference for the immutable time stamp value to
> pick. Could be zero, could be some other "meaningful" value (such as
> 0xeee4baadeee4baad - twice Eek! Bad!).
> 
KOD already sets a timestamp that is the requesters timestamp. See my
previous response. It's better than your idea since it is gradual.

Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Thoughts on KOD

[Danny Mayer]

On 7/6/2014 12:29 PM, Magnus Danielson wrote:
> Detha,
> 
> On 07/06/2014 03:23 PM, detha wrote:
>> On Sun, 06 Jul 2014 12:28:09 +, Magnus Danielson wrote:
>>> For cases like that, KOD won't help at all.
>>>
>>
>> All the state table/KOD/filter rules mitigation approaches I have seen so
>> far are limited to one server. Maybe time to take a look at a DNSBL-type
>> approach for abusive clients; that way, once a client is labeled
>> 'abusive', it will stop working with any of the pool servers that use the
>> blacklist.
>>
>> Policies (for how long to auto-blacklist, how to prevent DoS by
>> blacklisting the competition, how to 'promise to behave and
>> express-delist' etc.) to be defined.
> 
> Maybe. For the moment I think it is sufficient if we provide a mechanism
> by which offenders gets reported to *some* system.
> We *could* also provide a method by which white/black-list can be
> dynamically set from an external source, so enough hooks exists, but I
> do not think that NTPD should be burned with the rest of that system.
> 
> Once NTPD can report it feels offended by a source, and beyond KODing it
> also report to some external mechanism that could potentially block it
> by any external means, NTPD does not have to do much more.
> 
> My point being with this line of thinking is that KOD in itself makes
> assumptions on the offending source actually respects it, and while KOD
> rules probably can be improved, it does not provide a very effective
> means of protection with sources not respecting KOD, and thus we also
> needs to think i broader terms.
> 
> In my mind, the defenses is according to these lines:
> 
> 0) NTPD tolerates a source, packet approval checks
> 1) NTPD does not tolerate a source, fires of KOD, source is expected to
> shut up
> 2) NTPD admin does not tolerate a source, blacklist it, NTPD will drop
> the traffic
> 3) NTPD admin does not tolerate a source, filters in in box firewall,
> box firewall drops the traffic
> 4) NTPD admin does not tolerate a source, filters in network firewall,
> network firewall drops the traffic
> 
> Notice how step 2-4 moves the traffic load further away from NTPD
> process, interface and eventually subnetwork. What I proposed would
> allow for automation of these steps.
> 
> It is reasonable that escalation should be done when a source does not
> respect KOD and keeps transmitting requests.
> 
> It is also resonable that blocking times out, such that blocking is
> removed after some reasonable time, as offenders can be on dynamic
> addresses, and usually works over limited time when intentional.
> 
> How to automate step 2-4 is however not a core concern for NTPD, but
> feeding the data out of NTPD in a way that is handy for such a mechanism
> is. Separate block-log file as I proposed is probably better than only a
> syslog file, as it removes the need to parse syslog for matching blocks,
> but rather can focus on changes in a dedicated file.
> 

The experience with blocking has actually being negative and we have
seen traffic actually INCREASE after it is blocked because the client,
not having received a response, tries more often. This has been observed
in the wild.

Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Thoughts on KOD

[Danny Mayer]

On 7/6/2014 2:42 AM, Rob wrote:
> Harlan Stenn  wrote:
>> Discussion appreciated.
> 
> I think it is best to remove KOD from ntpd.
> It does not serve a useful purpose, because precisely the kind of
> clients that you want to say goodbye to, do not support it.
> 
> In real life it has either no effect at all, or it even has a negative
> effect because the client does not understand it and re-tries the
> request sooner than it would when no reply was sent at all.

You haven't read the code. Any client that ignores the KOD flag will
find (if they ever looked) that their clock will be drifting away
further and further from the proper time. When KOD is set the value of
the received and sent timestamps are the same as the initial client sent
timestamp. It doesn't use the system time for the returned packet.
Calculate what this does to the resulting clock.

Please also note that there is more than one type of KOD packet. See RFC
5905 Section 7.4. See also Figure 13. You need to clearly distinguish
the different ones when talking about them. Most of this discussion
seems to be about action a. As discussed above this is an extremely
useful feature because any client ignoring the KOD flag and using the
packet any way will get pushed way of the actual time that they would
normally expect regardless of the client software used.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Why DNS servers should not be NTP servers

[Danny Mayer]

On 6/18/2014 2:08 PM, Harlan Stenn wrote:
> Others have made good points, and I'll just add that DNSSEC requires
> "good time".

Irrespective of DNSSEC you should be running NTP on all such servers
regardless of DNSSEC, TSIG, etc., especially so that your logs are
accurate. Whether or not to allow the NTP server to provide NTP service
to other clients depends a great deal on bandwidth requirements, how
busy the DNS server is and a number of other factors.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP aaccount password

[Danny Mayer]

On 5/28/2014 6:00 PM, E-Mail Sent to this address will be added to the
BlackLists wrote:
> On 5/28/2014 1:47 PM, garrettbrian1...@gmail.com wrote:
>> I have been trying to install the Meinberg NTP build
>>   for Windows and the install is going through,
>>   yet NTP won't start because the client is saying
>>   the password is wrong.
>>  I did have NTP on there years ago but I uninstalled it,
>>   but apparently the password is still in there
>>   and I don't remember what it was.
>>  Where does Meinberg's NTP client store its password?
>>  I would imagine it's a registry key but I have no idea where to look.
> 
> Its a hidden windows user,
>  just make the ntp user visible,
> 

No, it's just a windows account. You don't say what version of Windows
you are running so it's hard to advise on how to find it. I don't know
how Meinberg's installer works so I don't know if it uses a fixed
account name.

>   {Search the registry for SpecialAccounts,
> remove it from the UserList,
> it won't be hidden anymore}
> 
Huh? You cannot normally search the Registry for SAM accounts.

>  Delete the account, and Reinstall Meinberg?
> 

There are two parts to this. First is the account, which if Meinberg's
installer is doing it correctly will be a restricted account with just a
few privileges, and will not be a member of the Users group. The second
part is that ntpd runs as a windows service and you need to have the
password to the account running the service the same as the windows
account. Having different passwords in the two places will cause the
windows sevice to fail to start.

Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Problem facing with Ntp client Configuration

[Danny Mayer]

On 3/25/2014 8:35 AM, Biswajit Panigrahi wrote:
> 
> Hi All,
> When ever I configure ntp client ,then its takes more time even if 7minute to 
> 8 minute difference is there between client and server.
> Please provide me the configuration which will sync within less time.
> Currently ntp.drift file is empty.shall we need to modify the same?
> 
> Current NTP Client configuration is :
> 
> server 10.16.188.254
Add iburst to this line.
Since this is an internal server can you add any more NTP servers? One
is not a good number 3 is good and 4 is better. Never use 2.

> server 127.127.1.0
> fudge 127.127.1.0 stratum 10
> 

Get rid of these last two lines. Unless the ntp client is serving time
elsewhere it's not needed.

> restrict 10.16.188.254 mask 255.255.255.255 nomodify notrap noquery
> restrict 127.0.0.1
> 
> broadcastclient novolley
> broadcastdelay 0
> keys /var/ntp/keys
> 
> logfile /var/log/ntp/ntpd.log
> driftfile /var/log/ntp/ntp.drift
> statsdir /var/log/ntp/
> statistics loopstats peerstats
> filegen loopstats file loopstats type day enable
> filegen peerstats file peerstats type day enable
> 
> 
> 
> 
> Disclaimer:  This message and the information contained herein is proprietary 
> and confidential and subject to the Tech Mahindra policy statement, you may 
> review the policy at http://www.techmahindra.com/Disclaimer.html externally 
> http://tim.techmahindra.com/tim/disclaimer.html internally within 
> TechMahindra.
> 

Not any more. This is a public mailing list and this message is now
available through Google search.

Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Quality vs. Quantity

[Danny Mayer]

On 3/23/2014 9:43 AM, steven Sommars wrote:
> Background:
> 
> NIST operates a DNS load balancer for NTP:  time.nist.gov
> See http://tf.nist.gov/tf-cgi/servers.cgi
> 
> USNO operates a server load balancer for NTP.  See for example:
> http://tycho.usno.navy.mil/ptti/2010papers/paper9.pdf
> 

That's a misconception. While I trust Richard Schmidt in what he says,
that's is not what you think he says. A DNS server can only respond with
a list of IP addresses and the normal design of most users is to take
the first one in the list. That's why most DNS servers will do
round-robin of the list, and is certainly true of BIND and Microsoft's
DNS servers. However an NTP server (and just about every application
that uses DNS) usually takes the first one and holds onto it for the
life of the application. In NTP we have started to take a different
approach and the pool option will use all of the returned IP addresses.
On the drawing boards is the idea that if a server doesn't respond after
a while the address can be dropped and another DNS query is done to get
a new set of addresses to be used.

On the NTP inference engine side, keeping the same address allows it to
stabilize since if you get different answers from what is claimed to be
the same address you will be receiving entirely diffeent timestamps that
will have that address with wildly fluctuating information and that will
always get dropped as a candidate for a truechimer.

Danny

> 
> 
> On Sun, Mar 23, 2014 at 2:43 AM, Terje Mathisen wrote:
> 
>> Daniel Quick wrote:
>>
>>> While this should be obvious, I always have to ask how and why...
>>> While considering that the number of requests to our time servers
>>> will grow over time since the client decides which server to sync
>>> with.
>>>
>>> Do we want a Netspeed setting that assists with taking the load off
>>> some of the more heavily, higher-speed servers? or do we want to keep
>>> a setting where we serve fewer clients with the highest resolution of
>>> time given specific setup and let the client queries grow from there?
>>> I suppose this also takes into the smart dns load-balancing that goes
>>> on in the background.
>>>
>>
>> You really do NOT want load-balancing of ntp servers!!!
>>
>> Put them all in a pool and let the clients connect to all, distributing
>> the load automatically.
>>
>> Terje
>>
>>
>>> Any input would be appreciated.
>>>
>>> Thanks,
>>>
>>> Daniel
>>>
>>>
>>
>> --
>> - 
>> "almost all programming can be viewed as an exercise in caching"
>>
>>
>> ___
>> questions mailing list
>> questions@lists.ntp.org
>> http://lists.ntp.org/listinfo/questions
>>
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
> 
> 

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Quality vs. Quantity

[Danny Mayer]

On 3/22/2014 8:54 PM, Daniel Quick wrote:
> While this should be obvious, I always have to ask how and why...
While considering that the number of requests to our time servers will
grow over time since the client decides which server to sync with.
> 
> Do we want a Netspeed setting that assists with taking the load off
some of the more heavily, higher-speed servers? or do we want to keep a
setting where we serve fewer clients with the highest resolution of time
given specific setup and let the client queries grow from there? I
suppose this also takes into the smart dns load-balancing that goes on
in the background.

What do you mean by load-balancing? NTP cannot be load-balanced. NTP
does a lookup and gets a specific address and continues to use it every
poll interval. If the server is unavailable then it doesn't matter since
it also queries other servers and decides based on a number of factors
which is likely to give the most accurate and precise timestamp at that
moment. That changes as traffic, network congestion, availability
changes and NTP will dynamically choose a different source for time. If
the DNS has a number of addresses associated with a fully qualified
domain name then NTP can take advantage of that and use all of them if
you use the pool configuration option.

Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Time to fix reported driver bug.

[Danny Mayer]

On 3/16/2014 4:11 PM, Paul wrote:
> On Sun, Mar 16, 2014 at 2:22 PM, William Unruh  wrote:
> 
>> I only noticed when adding
>>> another device in the Trimble family but if there's active support I'd
>>> submit a patch for it.
>>
>> Why would you not submit a patch for it if you have one?
> 
> 
> I meant submit a patch for the new device.  I supplied a patch for bug 2557
> in the report.

A patch WAS submitted for this though it was done inline instead of as
an attachment. I recommend that you mark it as possibly blocking 4.2.8
so that it gets some attention. Your explanation in the report seems to
be adequate but someone needs to examine the code to see if the fix has
any side effects, especially for other devices.

Danny


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] CVE-2013-5211 and xntpd

[Danny Mayer]

On 2/6/2014 9:26 AM, Brian Utterback wrote:
> I recently received a question from a customer about CVE-201305211, the
> monlist amplification attack. Specifically they asked if the attack
> affected xntpd. They had another vendor that said no, that the attack
> only affects ntpd. This surprised me since as far as I know the monlist
> mechanism is the same in xntpd. I thought the vendor was merely
> incorrect. However, I then read the CERT and NIST versions of the CVE
> and there is no mention of xntpd. Indeed, a literal reading of the CVE
> does indeed imply that xntpd is not vulnerable.
> 
> I don't think I am wrong about xntpd being vulnerable. If I am, please
> correct me. But if I am not, we should probably see about getting the
> CVE amended.
> 

If this is about NTP v3 then that version hasn't been supported in
something like 15 years. I believe that it is very likely vulnerable but
noone is going to go into the code to look assuming that they can find
the source for something like that. I believe it was Dennis who wrote
the mode 7 code and tools, so NTP v2 is likely vulnerable as well but
that's not in the CERT either.

If someone wants support for such an old version then they need to be
willing to pay for support, something that could be arranged, but they
are better off upgrading to NTP V4. They advisory should remain as is.
If there needs to be one for NTP V3 then that should be done as a
separate advisory but it won't happen for free.

Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Pool returns IPv6 address to IPv4 query

[Danny Mayer]

On 11/19/2013 10:48 PM, Brian Utterback wrote:
> On 11/19/2013 3:40 PM, Danny Mayer wrote:
>> You should not be using literal IP addresses of either flavor without
>> also setting the AI_NUMERICHOST flag otherwise it tries to do a DNS
>> lookup. That's poorly written code otherwise.
>>
>> Danny
> 
> Not so. The getaddrinfo function will recognize literal addresses and
> merely convert them. The point is that for something like ssh or any
> other network utility, the user is supposed to give a hostname, but in
> virtually all cases you can give a literal address and the application
> does not have to treat it differently. If you read the ipng mailing
> list, you will see that they were trying to make the whole process of
> writing a network application simpler, with getaddrinfo doing the heavy
> lifting for all of the major cases. At the same time they were trying to
> allow applications to work on either IPv4 or IPv6 systems without
> changing them, or dual stack or any combination. But no matter what they
> did there were edge cases that needed to work differently.
> 
> Brian Utterback

That wasn't true the last time I had to read the source code for
getaddrinfo(). A number of years ago I was debugging a problem with ntpd
on a Unix box, I think it was FreeBSD, and it was doing a DNS Lookup.
The ntpd code checks the string and sees if it is an IP address and
takes the appropriate action before calling getaddrinfo(), at least it
used to.

Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Pool returns IPv6 address to IPv4 query

[Danny Mayer]

On 11/19/2013 2:47 PM, Rick Jones wrote:
> Brian Utterback  wrote:
>> On 11/19/2013 12:33 PM, Rick Jones wrote:
> 
>>> Later, when interfaces started getting auto-configured, local
>>> scope IPv6 addresses, there was a call to change that to be "don't
>>> return IPv6 addresses unless there is a better-than-local-scope
>>> IPv6 address assigned."  Started causing me all manner of pain in
>>> netperf :( Not sure where that stands now in the Linux world.
>>>
>>> rick jones
> 
>> Yes, that was the issue. Further complicating it was what do you
>> return if you have no IPv6 interfaces and you set AI_ADDRCONFIG and
>> you pass in a literal IPv6 address.  The problem is that getaddrinfo
>> replaces both gethostbyname and inet_aton, each of which you might
>> expect to have different results in that case. We had people citing
>> two RFC's and the ipng working group mailing list. Great fun.
> 
> That passing-in a literal IPv6 address is precisely where I first
> started noticing problems with netperf.  For ages (in Internet Time at
> least) it "just worked" even when all I had were local-scope
> (link-scope?) IPv6 addresses configured.  Then someone made a libc
> change and life became Quite Unpleasant (tm).

You should not be using literal IP addresses of either flavor without
also setting the AI_NUMERICHOST flag otherwise it tries to do a DNS
lookup. That's poorly written code otherwise.

Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Is there something with greater detail on "interface" besides the manpage?

[Danny Mayer]

On 11/19/2013 1:50 PM, Danny Mayer wrote:
> On 11/19/2013 11:36 AM, Rick Jones wrote:
>> Harlan Stenn  wrote:
>>> You might want:
>>
>>>  interface ignore all
>>>  interface listen 127.0.0.1 # if you want localhost ntpq to work
>>>  interface listen a.b.c.d   # enumerate the IPs you want to use
>>
>> Thanks.  I take it then that wildcard charaters in matching on
>> interface names aren't a go :) My further complication is these
>> systems get their IPs via DHCP (I should have listed that in the first
>> place, sorry) and some are bonded and some are not bonded, but the
>> component names of the interfaces in the bond(s) are the same
>> "namespace" as when they are not bonded.  For example I may have
>> systems with a bond0 using eth2 and eth3 and some systems just using
>> eth2.  I *may* though be able to split the config files between such
>> systems - that remains to be determined and if not is, arguably a
>> failing at my end.
>>
> 
> You can specify 14.15.16.0/24 for example to specify an address on a
> particular subnet. Does that help?

I didn't answer your original question. Try here:
https://support.ntp.org/bin/view/Dev/ListenOn

Danny


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Is there something with greater detail on "interface" besides the manpage?

[Danny Mayer]

On 11/19/2013 11:36 AM, Rick Jones wrote:
> Harlan Stenn  wrote:
>> You might want:
> 
>>  interface ignore all
>>  interface listen 127.0.0.1 # if you want localhost ntpq to work
>>  interface listen a.b.c.d   # enumerate the IPs you want to use
> 
> Thanks.  I take it then that wildcard charaters in matching on
> interface names aren't a go :) My further complication is these
> systems get their IPs via DHCP (I should have listed that in the first
> place, sorry) and some are bonded and some are not bonded, but the
> component names of the interfaces in the bond(s) are the same
> "namespace" as when they are not bonded.  For example I may have
> systems with a bond0 using eth2 and eth3 and some systems just using
> eth2.  I *may* though be able to split the config files between such
> systems - that remains to be determined and if not is, arguably a
> failing at my end.
> 

You can specify 14.15.16.0/24 for example to specify an address on a
particular subnet. Does that help?

> "Wildcard" - that is listening on INADDR_ANY basically?
> 

Yes. But it should be used with caution and only if necessary.

Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Pool returns IPv6 address to IPv4 query

[Danny Mayer]

On 11/19/2013 1:01 PM, Brian Utterback wrote:
> On 11/19/2013 12:33 PM, Rick Jones wrote:
>> Danny Mayer  wrote:
>>> That must have been a short discussion. getaddrinfo() has nothing to
>>> do with the IP stack. getaddrinfo()'s job is to get information from
>>> the nameservers you specify in resolv.conf or wherever else the OS
>>> has that information. Its job is NOT to make decisions about what it
>>> should ask for. That's the programmer's job when setting up the API
>>> call as to what addresses to ask for.
>> I suspect it all boils down to the behaviour when one sets
>> AI_ADDRCONFIG in the getaddrinfo() call.  When that is set, ostensibly
>> getaddrinfo() is supposed to filter-out any reponses that are of a
>> type that cannot be used by the application.  The decision made was if
>> there were no non-loopback-interface IPv6 addresses configured, 
>> records would not be returned from the getaddrinfo() call.  Similarly
>> for A recorecords if there were no IPv4 addresses configured on the
>> system.
>>
>> Later, when interfaces started getting auto-configured, local scope
>> IPv6 addresses, there was a call to change that to be "don't return
>> IPv6 addresses unless there is a better-than-local-scope IPv6 address
>> assigned."  Started causing me all manner of pain in netperf :( Not
>> sure where that stands now in the Linux world.
>>
>> rick jones
> Yes, that was the issue. Further complicating it was what do you return
> if you have no IPv6 interfaces and you set AI_ADDRCONFIG and you pass in
> a literal IPv6 address. The problem is that getaddrinfo replaces both
> gethostbyname and inet_aton, each of which you might expect to have
> different results in that case. We had people citing two RFC's and the
> ipng working group mailing list. Great fun.
> 

I think you mean inet_ntoa. As I already said you should be setting the
ai_family in the hints structure and you want to have it only a
particular type of address. If you want to pass an IP address you should
be setting AI_NUMERICHOST in ai_flags of the hint structure. Note that
inet_ntoa does not perform a lookup. It's just a formatter.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Pool returns IPv6 address to IPv4 query

[Danny Mayer]

On 11/19/2013 12:33 PM, Rick Jones wrote:
> Danny Mayer  wrote:
>> That must have been a short discussion. getaddrinfo() has nothing to
>> do with the IP stack. getaddrinfo()'s job is to get information from
>> the nameservers you specify in resolv.conf or wherever else the OS
>> has that information. Its job is NOT to make decisions about what it
>> should ask for. That's the programmer's job when setting up the API
>> call as to what addresses to ask for.
> 
> I suspect it all boils down to the behaviour when one sets
> AI_ADDRCONFIG in the getaddrinfo() call.  When that is set, ostensibly
> getaddrinfo() is supposed to filter-out any reponses that are of a
> type that cannot be used by the application.  The decision made was if
> there were no non-loopback-interface IPv6 addresses configured, 
> records would not be returned from the getaddrinfo() call.  Similarly
> for A recorecords if there were no IPv4 addresses configured on the
> system.

That's not the what you need to do if you only want IPv4. You need to
set ai_family to AF_INET in the hints structure before making the call.
IF you specify -4 on the ntpd command line, that's what we do when
fetching IP addresses from the name server. There's no magic here, it
just works.

Danny


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Pool returns IPv6 address to IPv4 query

[Danny Mayer]

That must have been a short discussion. getaddrinfo() has nothing to do
with the IP stack. getaddrinfo()'s job is to get information from the
nameservers you specify in resolv.conf or wherever else the OS has that
information. Its job is NOT to make decisions about what it should ask
for. That's the programmer's job when setting up the API call as to what
addresses to ask for.

Would you like dig, nslookup, host, etc. to not give you all the
information when you are analyzing a problem? (the BIND versions use
their own internal versions of getaddrinfo, I am using these as an example).

Applications and Servers can make their own decisions about what data to
fetch and use, not getaddrinfo's.

Danny

On 11/19/2013 9:02 AM, Brian Utterback wrote:
> Just as a point of interest, one of the most heated debates I have ever
> been involved in internally here at Oracle was concerning whether
> getaddrinfo (as defined by POSIX) should or should not return IPv6
> addresses if the system only has IPv4 interfaces and/or only the
> loopback IPv6 address. The getaddrinfo call was designed to work
> efficiently on both dual stack and single stack systems, but the wording
> in the standard is slightly ambiguous especially considering the case
> that the host you are looking up might actually belong to the system you
> are on.
> 
> On 11/18/13 16:01, Danny Mayer wrote:
>> On 11/18/2013 2:44 PM, A C wrote:
>>> On 11/18/2013 11:18, Majdi S. Abbas wrote:
>>>
>>>> The fact that it's even trying means you didn't start ntpd with
>>>> -4, and the host has at least one IPv6 interface (this might be as
>>>> simple as v6 enabled on the loopback.)
>>>>
>>>> So, either ensure that v6 is fully disabled on the host, or add
>>>> -4 to your ntpd startup parameters.
>>>>
>>> lo0 did indeed have a v6 address configured (hadn't noticed) though my
>>> eth0 does not.  I would not have expected ntpd to use v6 if any one
>>> interface did not have it.  Up until this point it never returned a v6
>>> address on lookup so that's probably why I never noticed that v6 had
>>> been enabled again (recent upgrade of OS).  I've disabled all v6 now and
>>> added -4 for good measure.
>> ntpd will use whatever addresses it gets back from DNS. If you don't
>> specify that you only want IPv4 addresses and it gets an IPv6 address it
>> will attempt to use it. This is a DNS and configuration issue not an ntp
>> issue. This is true of all applications (whether client or server) these
>> days.
>>
>> Danny
>>
>> ___
>> questions mailing list
>> questions@lists.ntp.org
>> http://lists.ntp.org/listinfo/questions
> 
> 

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Fw: Authenticated ntp server

[Danny Mayer]

On 11/18/2013 8:12 AM, Shreyas Ambokar wrote:
> Dear Team,
> 
> We are using pool.ntp.org as ntp server for environment.
> We would like to avail the authenticated ntp services to connect to the 
> ntp server.
> Kindly provide us the security key for ntp server.
> 

If you need authentication then you will need to go to someone who
provides such a service. I doubt that any of the pool servers are set up
to provide it. The pool servers are at no cost to you but if you want
authentication you will probably have to pay for it.

In any case this is the wrong mailing list for pool servers. It's the
right place to ask about authentication.

> Regards
> Shreyas Ambokar
> =-=-=
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain 
> confidential or privileged information. If you are 
> not the intended recipient, any dissemination, use, 
> review, distribution, printing or copying of the 
> information contained in this e-mail message 
> and/or attachments to it are strictly prohibited. If 
> you have received this communication in error, 
> please notify us by reply e-mail or telephone and 
> immediately and permanently delete the message 
> and any attachments. Thank you

Sorry but this is a public mailing list. It's already been copied,
archived and made publicly available through all of the search engines
available. You don't get to make such disclaimers or restrictions here
and in any case they have no effect. If you didn't send the message to
the correct recipients then it's your fault and you have no right to
impose any obligations on anyone who may receive it or otherwise see it.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Pool returns IPv6 address to IPv4 query

[Danny Mayer]

On 11/18/2013 2:44 PM, A C wrote:
> On 11/18/2013 11:18, Majdi S. Abbas wrote:
> 
>>
>>  The fact that it's even trying means you didn't start ntpd with
>> -4, and the host has at least one IPv6 interface (this might be as
>> simple as v6 enabled on the loopback.)
>>
>>  So, either ensure that v6 is fully disabled on the host, or add
>> -4 to your ntpd startup parameters.
>>
> 
> lo0 did indeed have a v6 address configured (hadn't noticed) though my
> eth0 does not.  I would not have expected ntpd to use v6 if any one
> interface did not have it.  Up until this point it never returned a v6
> address on lookup so that's probably why I never noticed that v6 had
> been enabled again (recent upgrade of OS).  I've disabled all v6 now and
> added -4 for good measure.

ntpd will use whatever addresses it gets back from DNS. If you don't
specify that you only want IPv4 addresses and it gets an IPv6 address it
will attempt to use it. This is a DNS and configuration issue not an ntp
issue. This is true of all applications (whether client or server) these
days.

Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Failure modes on Windows Server 2008 R2 64-bit

[Danny Mayer]

On 8/13/2013 5:07 PM, David Taylor wrote:
> On 13/08/2013 21:23, Danny Mayer wrote:
> []
>> All binaries need to be built together with the same versions. You
>> should not be mixing binaries.
>>
>> Danny
> 
> Thanks, Danny.  Perhaps,ideally, but in that case, why are the SSL
> sources not in the distributed NTP source files?

NTP doesn't own the OpenSSL sources so we don't distribute it. People
can get their own if they want it.

> When people may have different SSL DLLs, which may be shared with other
> software, a multi-use .EXE is a solution which works well.  I'm happy
> providing .EXE files, as are those who use them, I would be less happy
> providing potentially shared DLLs which could break other software if
> overwritten.

OpenSSL is not build correctly for proper versioning. It needs to use
fixed ordinals for each entry point in a .def file that gets updated as
new entry points are added but that's not being done. Microsoft does
this correctly but it's not generally done as it is a painful chore
setting it up and maintaining it correctly. VMS always did this right.

You don't need to share the DLL's. As long as the DLL's are in the same
directory as the .exe files and are in their own directory, the O/S will
look in the same directory first when the .exe needs the dll's. It's not
hard to do.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Failure modes on Windows Server 2008 R2 64-bit

[Danny Mayer]

On 8/13/2013 2:51 PM, David Taylor wrote:
> On 13/08/2013 17:51, Danny Mayer wrote:
> []
>> If you are building your own binaries then the runtime dll's are already
>> installed on your system and you don't need to do anything special.
>>
>> Danny
> 
> Danny,
> 
> When I replaced some binaries which required the 1.1 OpenSSL DLLs with
> ones I had compiled locally with 0.9.8, ntpd.exe failed to run because
> of a DLL versioning issue (it may have been ntpq.exe).
> 
> I needed to compile with OpenSSL 1.0.0c source so that the binaries I
> now produce will work both with earlier SSL DLLs as installed with
> earlier Meinberg installers, and with the later DLLs installed with the
> current Meinberg installer.  Having to cope with mixed versions of the
> DLLs originally by users installed over several years required special
> action to allow seamless upgrades.

All binaries need to be built together with the same versions. You
should not be mixing binaries.

Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Failure modes on Windows Server 2008 R2 64-bit

[Danny Mayer]

On 8/13/2013 9:10 AM, David Taylor wrote:
> On 13/08/2013 13:44, Martin Burnicki wrote:
> []
>> Take care if you have also installed some stuff from David Taylor. This
>> is perfectly fine but AFAIK David uses VS2010, so there may be
>> dependencies on the VS2010 runtime from David's binaries, and
>> dependencies on the VS2008 runtime from Meinberg's binaries.
>>
>> Martin
> ===
> 
> Martin, you raise a good point.  Yes, mune are compiled with VS2010, and
> I've never had to install extra runtime DLLs to get NTP working, but may
> of my PCs run other software as well which /may/ have installed them.  I
> seem to recall that on several out-of-the-box Windows-8 installs, your
> recent 4.2.6p5 "London" version installed without the need for any extra
> DLLs, and my locally-compiled 4.2.7p development versions could be
> written over the top of your install without issues (SSL dependency
> excepted).  Lots of others have used your install without issues, and
> many have used my updates as well.
> 

If you are building your own binaries then the runtime dll's are already
installed on your system and you don't need to do anything special.

Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Failure modes on Windows Server 2008 R2 64-bit

[Danny Mayer]

On 8/13/2013 1:51 AM, Olo Burrows wrote:
> By the way, I did download and install the Visual C++ runtime for
> 2010 and 2012, not knowing which would apply. My tests led me to
> believe that neither one helped, despite my expectations. But perhaps
> the reboot for the other updates and packages that I later installed
> allowed it to complete its installation even though it did not prompt
> me to do so at the time.

I cannot speak about the Meinberg installer but there is nothing about
the install that requires a restart and my installers never require
that. It would take some digging around your system to figure out what
happened. I might have an opportunity in a month or so to install ntpd
on a W2k8 box, but using my own installer and that would give me an idea
of what's going on.

Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Failure modes on Windows Server 2008 R2 64-bit

[Danny Mayer]

On 8/12/2013 6:47 AM, Olo Burrows wrote:
> Has anyone experienced a failure of the Meinberg ntp binaries to run
> on Windows Server 2008 R2?
> 
I don't know what the Meinberg installer does when installing the
binaries though I did provide some advice to them at the time. What you
do need need is to have the Change System Time privilege enabled for the
user account running the service. I believe that local service has that
or you set up an account that specifically includes that privilege. You
have to do that in the Local Security Policy MSC. Either that or have
administrator group. I advise not doing either of these but to establish
a separate account with that privilege and logon as service privilege
and remove it from the Users group.

Also make sure you disable Windows Time.

> I have my suspicions that "something" is odd about this refurbished
> Dell R610 server with brand new installation of 2008 R2 because
> another package was balky when its installation routine came to the
> point of installing it as a service.
> 
> I allowed it to take the many hours required to apply all the Windows
> Updates to bring it current, who knows if one of those munged
> something on which ntp depends.
> 
> Event Viewer was reporting a missing dependency of libeay.dll with
> VC90 (machine is at the shop and on an isolated network, so message
> is from memory). I uninstalled ntp and re-installed it without
> OpenSSL support, then it complained about the missing SSL support.
> Catch-22.
> 
If it was built with VC90 then you need to have the freely available
VC90 runtime installed. You need OpenSSL as the Windows binary is always
built with it.

> Regardless of the SSL issue the only consistent error message is that
> ntp refused to start in a timely manner, which is evidenced by its
> refusal to start period, but I can't pinpoint why. The firewall has
> exceptions, in fact I even disabled the firewall temporarily and that
> didn't change anything. I've given the ntp user ownership and full
> access permissions to that directory tree, no good. I've uninstalled
> and rebooted and tried a number of tweaks, all to no avail. I'm out
> of ideas and time at this point.

Is Windows Time running? If so you need to disable it.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Has anyone compiled the ntpd for wince (6.0)?

[Danny Mayer]

On 6/27/2013 5:13 AM, David Bru i Bru wrote:
> Hi Folks,
> 
> (This is my first time in this forum)
> 
> Has anyone compiled the ntpd for wince (6.0)?
> 
> I tried, but some CRT function are missing in WinCE, and I have problems
> compiling the OpenSSL source.
> 

While OpenSSL might compile I doubt that ntp will work as I seem to
recall that wince doesn't support completion ports which the windows
version uses.

Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntpd wedged again

[Danny Mayer]

On 2/26/2012 10:27 AM, unruh wrote:
> On 2012-02-26, Danny Mayer  wrote:
>> On 2/26/2012 12:17 AM, Dave Hart wrote:
>>> On Sun, Feb 26, 2012 at 03:37, Danny Mayer  wrote:
>>>> It could well be that rackety is sending KOD packets and this server is
>>>> not recognizing them as such. rackety has a heavy load under normal
>>>> circumstances so it may well do so. When it does so the ntp timestamps
>>>> are going to be totally wrong, deliberately, so they should have been
>>>> discarded immediately. I don't remember whether or not KOD had been
>>>> introduced back when 4.2.2 was shipped so it may not be ignoring it when
>>>> it should.
>>>>
>>>> I suggest you pick a different server with a more modern version of ntpd
>>>> and see if that stabilizes the situation.
>>>
>>> While I'm all in favor of running modern ntpd, it's not going to
>>> affect KoD handling in terms of timekeeping.  KoD responses only occur
>>> when a source IP exceeds relatively generous rate limits, and they
>>> carry timestamps that are totally useless, deliberately, which is a
>>> different beast than totally wrong.  KoD timestamps are set to match
>>> the sender's originate timestamps, so if they attempt to use them for
>>> time, they learn nothing their local oscillator wasn't already telling
>>> them.
>>
>> It's worse than that. I analyzed the KOD code at the time and in fact
>> what the reference code does it copy the originator starting timestamp
>> to the receiving and sending server timestamp and sends it back. Now if
>> you calculate the resulting offset you will get a nasty surprise. After
>> a short discussion with Dave Mills he agreed with me that it results in
>> the result shifting and increasing the resulting offset. Check the
>> results for yourself!
> 
> It sets the offset to half the round trip time.
> 

Exactly. Any client that uses that will find that if it uses the offset
if will push the client time further and further away from what it
should be. Even more interesting is that the longer the roundtrip time
the further it pushes it off.


Danny
>>
>> Danny
> 
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
> 

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntpd wedged again

[Danny Mayer]

On 2/26/2012 12:17 AM, Dave Hart wrote:
> On Sun, Feb 26, 2012 at 03:37, Danny Mayer  wrote:
>> It could well be that rackety is sending KOD packets and this server is
>> not recognizing them as such. rackety has a heavy load under normal
>> circumstances so it may well do so. When it does so the ntp timestamps
>> are going to be totally wrong, deliberately, so they should have been
>> discarded immediately. I don't remember whether or not KOD had been
>> introduced back when 4.2.2 was shipped so it may not be ignoring it when
>> it should.
>>
>> I suggest you pick a different server with a more modern version of ntpd
>> and see if that stabilizes the situation.
> 
> While I'm all in favor of running modern ntpd, it's not going to
> affect KoD handling in terms of timekeeping.  KoD responses only occur
> when a source IP exceeds relatively generous rate limits, and they
> carry timestamps that are totally useless, deliberately, which is a
> different beast than totally wrong.  KoD timestamps are set to match
> the sender's originate timestamps, so if they attempt to use them for
> time, they learn nothing their local oscillator wasn't already telling
> them.

It's worse than that. I analyzed the KOD code at the time and in fact
what the reference code does it copy the originator starting timestamp
to the receiving and sending server timestamp and sends it back. Now if
you calculate the resulting offset you will get a nasty surprise. After
a short discussion with Dave Mills he agreed with me that it results in
the result shifting and increasing the resulting offset. Check the
results for yourself!

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntpd wedged again

[Danny Mayer]

On 2/12/2012 4:55 PM, A C wrote:
> I'm not exactly sure what happened but I may have caught the system in
> the act of trying to run away.  Below is the last two lines from the
> peers log for one of the peers and below that is the output of ntpq
> showing what happened to that peer immediately after.  Note the offset.
>  This somewhat matches what I had been seeing previously where my system
> would be reporting sane numbers and then very suddenly go haywire.
> 
> 55969 77832.471 67.23.181.241 9324 0.006359155 0.081262776 0.001634487
> 0.008837966
> 55969 77897.557 67.23.181.241 9324 399326.864663492 0.000122070
> 0.001346708 399326.861631493
> 
> 
>  remote   refid  st t when poll reach   delay   offset jitter
> 
> ==
>67.23.181.241   128.4.1.12 u   53   64  3770.122  3993268 3993268

This shows that this server is contacting rackety. Out of curiosity I
looked at 67.23.181.241 and it turns out that it's running ntpd 4.2.2p1
which is rather ancient:
> version="ntpd 4.2.2p1@1.1570-o Fri Nov 18 13:21:21 UTC 2011 (1)"?,
> processor="x86_64", system="Linux/2.6.18-274.17.1.el5.centos.plus",

It could well be that rackety is sending KOD packets and this server is
not recognizing them as such. rackety has a heavy load under normal
circumstances so it may well do so. When it does so the ntp timestamps
are going to be totally wrong, deliberately, so they should have been
discarded immediately. I don't remember whether or not KOD had been
introduced back when 4.2.2 was shipped so it may not be ignoring it when
it should.

I suggest you pick a different server with a more modern version of ntpd
and see if that stabilizes the situation.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Leap second

[Danny Mayer]

On 1/5/2012 11:38 AM, Rob van der Putten wrote:
> Hi there
> 
> 
> There's a leap second coming up;
> http://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat

This is the first time that I remember a leap second being added in the
middle of the year instead of the end of December. Am I wrong?

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Accuracy of NTP - Advice Needed

[Danny Mayer]

On 12/29/2011 8:38 PM, Dennis Ferguson wrote:
> 
> On 29 Dec, 2011, at 23:26 , Terje Mathisen wrote:
> 
>> Danny Mayer wrote:
>>> No, they use synchronized Cesium atomic clocks for time accuracy. GPS is
>>> only used to get a fix on the location and I'm not sure that 10's of
>>> centimeters is good enough for what they are trying to prove. I'd have
>>> to look closely at the methods used and the data to even have a clue as
>>> to what is needed and I have touched that stuff in years.
>>
>> Danny, how do you think they keep those atomic clocks synchronized?
>>
>> How do they _verify_ that they actually stay in sync (to a single-digit ns 
>> level) over the entire length of the experiment(many months)?
>>
>> Even Hydrogen Masers won't give you that performance over a year or so, you 
>> have to have some way to sync them either to each other or to UTC.
> 
> Yes, they use GPS to compare the clocks to each other.
> 
> One of the articles I read even identified the GPS receiver they use.  I think
> it was a Septentrio PolaRx3eTR PRO (or maybe the older model which that one
> replaced).  Those receivers take a 10 MHz and 1 PPS reference in from the 
> atomic
> clock so that they can produce GPS carrier phase measurements with respect to
> the local clock's time.  Making these measurements simultaneously at both
> locations gives you data you can post-process to determine the time difference
> between the two clocks, independent of the GPS system time.  The GPS signals
> are used only as markers that can be measured at both locations.
> 

They used Septentrio PolaRx2e GPS receivers in both places along with a
Symmetricom Cs4000 Cs atomic clock. All of this raises additional
questions for which I'd have to dig into the references for answers. For
example, both ends are underground and they are likely to use heavy
shielding around the sites of the source and target so how are they even
getting a GPS signal through in the first place? Are they getting signal
or did they set up an external antenna in which case they would have to
also figure out the distance of the antenna from the receiver (which
part of the antenna?). This is not an easy physics experiment and the
errors involved can easily overwhelm the result.

It used to be that detecting neutrinos was very hard never mind
generating them in a reliable way.

Now if only we could send NTP packets via neutrino...

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Accuracy of NTP - Advice Needed

[Danny Mayer]

On 12/28/2011 12:17 AM, unruh wrote:
> On 2011-12-28, Danny Mayer  wrote:
>> On 12/24/2011 8:10 PM, j...@specsol.spam.sux.com wrote:
>>> John Hasler  wrote:
>>>>> The open sky nearest the OPERA detector is straight up through 1400m of
>>>>> rock.
>>>>
>>>> Jim Pennino writes:
>>>>> And the easiest open sky to get to is horizontally down the tunnel to
>>>>> the entrance which is next to a freeway.
>>>>
>>>> Yes, the entrance is next to a freeway.  The entrance to the LNGS
>>>> facility where the OPERA detector is located is near the middle of the
>>>> 10 km long Gran Sasso highway tunnel.
>>>
>>> The bottom line is that the only thing that is relevant is how easy it is
>>> to get to a GPS antenna with an open view of the sky.
>>>
>>> Everything else is bloviation.
>>
>> GPS is not used for this kind of thing, they are too inaccurate, so it
>> doesn't matter. They use atomic clocks.
> 
> No they do not. They use GPS. As has been discussed here gps can be made
> accurate to a few ns. GPS is used by radio astronomers to synchronize
> very long  baseline arrays. 
> (Yes, I also thought that gps was not accurate enough. I was wrong)

As a fellow astrophysicist you know that you don't just use GPS for this
like you would finding your way around the streets of Vancouver. This is
way beyond those kind of calculations. Of course in astrophysics even 1
km is below the noise level...

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Accuracy of NTP - Advice Needed

[Danny Mayer]

On 12/28/2011 12:09 AM, j...@specsol.spam.sux.com wrote:
> Danny Mayer  wrote:
>> On 12/27/2011 8:48 PM, j...@specsol.spam.sux.com wrote:
>>> Danny Mayer  wrote:
>>>> On 12/24/2011 8:10 PM, j...@specsol.spam.sux.com wrote:
>>>>> John Hasler  wrote:
>>>>>>> The open sky nearest the OPERA detector is straight up through 1400m of
>>>>>>> rock.
>>>>>>
>>>>>> Jim Pennino writes:
>>>>>>> And the easiest open sky to get to is horizontally down the tunnel to
>>>>>>> the entrance which is next to a freeway.
>>>>>>
>>>>>> Yes, the entrance is next to a freeway.  The entrance to the LNGS
>>>>>> facility where the OPERA detector is located is near the middle of the
>>>>>> 10 km long Gran Sasso highway tunnel.
>>>>>
>>>>> The bottom line is that the only thing that is relevant is how easy it is
>>>>> to get to a GPS antenna with an open view of the sky.
>>>>>
>>>>> Everything else is bloviation.
>>>>
>>>> GPS is not used for this kind of thing, they are too inaccurate, so it
>>>> doesn't matter. They use atomic clocks.
>>>>
>>>> Danny
>>>
>>> How do you measure distance with an atomic clock?
>>>
>>>
>>
>> That's a complex question. GPS (even the military version) is not
>> accurate enough.
>>
>> Danny
> 
> No, it is not complex; you can't measure distance with an atomic clock.
> 
> An atomic clock is used to measure time intervals.
> 
> As for GPS, it is pretty trivial these days to determine an absolute location
> to parts of a centimeter for a fixed location.
> 

There's no such thing as an absolute location. See Einstein.

Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Accuracy of NTP - Advice Needed

[Danny Mayer]

On 12/27/2011 11:45 PM, Greg Hennessy wrote:
> On 2011-12-28, Danny Mayer  wrote:
>> On 12/27/2011 9:08 PM, John Hasler wrote:
>>> Danny writes:
>>>> GPS is not used for this kind of thing, they are too inaccurate, so it
>>>> doesn't matter. They use atomic clocks.
>>>
>>> The requirement is for synchronization.  They use common view GPS.
>>
>> That's not good enough for experiments like this.
> 
> In what way is it not good enough? The neutrinos are apparently
> arriving about 60 nanoseconds early, the distance is known, through
> GPS to 10's of centimeters, and the time is synchronized, again
> through GPS (although a second method is used as a double check) to
> about 1 nanosecond. In what fashion is it 'not good enough'?

No, they use synchronized Cesium atomic clocks for time accuracy. GPS is
only used to get a fix on the location and I'm not sure that 10's of
centimeters is good enough for what they are trying to prove. I'd have
to look closely at the methods used and the data to even have a clue as
to what is needed and I have touched that stuff in years.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Accuracy of NTP - Advice Needed

[Danny Mayer]

On 12/27/2011 10:39 PM, Greg Hennessy wrote:
>>> The bottom line is that the only thing that is relevant is how easy it is
>>> to get to a GPS antenna with an open view of the sky.
>>>
>>> Everything else is bloviation.
>>
>> GPS is not used for this kind of thing, they are too inaccurate, so it
>> doesn't matter. They use atomic clocks.
> 
> GPS is indeed used for the measurement of the time of flight in the
> CERN and Fermilab experiments. You should read the papers. They use
> GPS to get time to the order of nanosecond accuracy.
> 

You can read some of this here:
http://www.wired.com/wiredscience/2011/09/scientists-question-neutrinos/

It's not too technical but describes the basic setup. Yes they did use
GPS to get accurate locations of the equipment but it's a rather complex
and hard to get right. They then used Cesium atomic clocks for timing
the events. The calculations you have to do for all this is
mind-boggling and there is a lot of work that has to go into ensuring
that they are accurate and nothing got missed. That's the principle
reason that it's hard to be sure that an FTL result was obtained. There
are lots of scientists pouring over calculations (there were something
like 150 authors listed on the paper published in arXiv. Hords of other
scientists are also analyzing the data.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Accuracy of NTP - Advice Needed

[Danny Mayer]

On 12/27/2011 9:08 PM, John Hasler wrote:
> Danny writes:
>> GPS is not used for this kind of thing, they are too inaccurate, so it
>> doesn't matter. They use atomic clocks.
> 
> The requirement is for synchronization.  They use common view GPS.

That's not good enough for experiments like this.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Accuracy of NTP - Advice Needed

[Danny Mayer]

On 12/27/2011 8:48 PM, j...@specsol.spam.sux.com wrote:
> Danny Mayer  wrote:
>> On 12/24/2011 8:10 PM, j...@specsol.spam.sux.com wrote:
>>> John Hasler  wrote:
>>>>> The open sky nearest the OPERA detector is straight up through 1400m of
>>>>> rock.
>>>>
>>>> Jim Pennino writes:
>>>>> And the easiest open sky to get to is horizontally down the tunnel to
>>>>> the entrance which is next to a freeway.
>>>>
>>>> Yes, the entrance is next to a freeway.  The entrance to the LNGS
>>>> facility where the OPERA detector is located is near the middle of the
>>>> 10 km long Gran Sasso highway tunnel.
>>>
>>> The bottom line is that the only thing that is relevant is how easy it is
>>> to get to a GPS antenna with an open view of the sky.
>>>
>>> Everything else is bloviation.
>>
>> GPS is not used for this kind of thing, they are too inaccurate, so it
>> doesn't matter. They use atomic clocks.
>>
>> Danny
> 
> How do you measure distance with an atomic clock?
> 
> 

That's a complex question. GPS (even the military version) is not
accurate enough.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps?

[Danny Mayer]

On 12/24/2011 8:11 PM, Dave Hart wrote:
> On Sat, Dec 24, 2011 at 18:18, unruh  wrote:
>> On 2011-12-24, David J Taylor  wrote:
>>> - one Netbook PC worked very well on a LAN connection (about 1 ms steady
>>> jitter).  However, when moving to a Wi-Fi connection after a power-down
>>> reboot, the reported jitter gradually built up over about a 30 minute
>>> period, ending up with a 5 ms peak, later decaying to a value between 1.3
>>> and 2.5 ms.  The offset also appeared to have spikes which because much
>>> worse after about 30 minutes.
>>
>> I would expect wifi to be much worse than a lan for jitter. The signal
>> has to be converted, broadcast, reconverted and then sent on down the
>> lan. That all takes time, and can have aproblem with dropped bits,
>> retransmission, etc.
> 
> Retransmission is the killer issue for NTP performance over 802.11.
> For practical interop with software developed on wired networks, WiFi
> equipment detects packet loss and triggers retransmission invisibly to
> higher layers.  I suspect NTP would do better if the 802.11 layer
> differentiated its handling of UDP 53 and 123 :)  Where dropping DNS
> queries has an awful impact on user experience, it would be preferable
> for NTP compared to introducing the extra delay and thereby jitter.
> I'd love to see more DNS over TCP, so that perhaps one day layer 2
> wireless networks will do better letting UDP drop rather than
> retransmit at layer 2. 

No you don't want to do DNS over TCP if you can avoid it. It would be a
major hit on the resolver servers and with the kind of high volume that
you get as mobile devices make increasing use of such networks. You want
WiFi to drop UDP packets if they are lost rather than attempting to
retransmit them.

Danny


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Accuracy of NTP - Advice Needed

[Danny Mayer]

On 12/24/2011 8:10 PM, j...@specsol.spam.sux.com wrote:
> John Hasler  wrote:
>>> The open sky nearest the OPERA detector is straight up through 1400m of
>>> rock.
>>
>> Jim Pennino writes:
>>> And the easiest open sky to get to is horizontally down the tunnel to
>>> the entrance which is next to a freeway.
>>
>> Yes, the entrance is next to a freeway.  The entrance to the LNGS
>> facility where the OPERA detector is located is near the middle of the
>> 10 km long Gran Sasso highway tunnel.
> 
> The bottom line is that the only thing that is relevant is how easy it is
> to get to a GPS antenna with an open view of the sky.
> 
> Everything else is bloviation.

GPS is not used for this kind of thing, they are too inaccurate, so it
doesn't matter. They use atomic clocks.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Accuracy of NTP - Advice Needed

[Danny Mayer]

On 12/24/2011 1:11 PM, unruh wrote:
> On 2011-12-24, John Hasler  wrote:
>> I wrote:
>>> An upcoming experiment at Fermilab will observe neutrinos at both ends
>>> (the far end will be in Minnesota).
>>
>> unruh writes:
>>> Well, no. At best the electrons or muons at one end.
>>
>> At best the electrical pulse produced by a photomultiplier when struck
>> by a photon generated when a muon or electron emitted as a result of a
>> neutrino collision interacts with the detector medium (there are a
>> variety of detector designs but photomultipliers are almost always
>> involved).
>>
>> However, the use of similar or identical neutrino detectors at both ends
>> means that systemic errors in delay estimation will tend to cancel.  I
>> assume that they will try to match up the timing equipment at both ends
>> as well.
> 
> Just saying, it is not the same neutrino that is being detected at both
> ends. The detection probability is just too small. Thus again there is
> the same inference that the timing at one end measures the same class of
> things as teh timing at the other. 
> 
> Yes, the timing equipment is a worry. They require ns accuracy in the
> timing and m accuracy in the distance. And the timing is not simply gps
> ( although they could have gotten that wrong) but then that timing has
> to be brought down into the mine a km or so below ground and
> horizontally and that also has to be surveyed for the distance.

You need a very good atomic clock at both ends that are synchronized to
each other. Chances are very good that they have a number of them at
each end. Nothing less than an atomic clock will do.

Now what has this to do with the original question?

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntp server pool advice

[Danny Mayer]

On 12/27/2011 1:16 PM, unruh wrote:
> On 2011-12-27, Danny Mayer  wrote:
>> On 12/26/2011 11:17 PM, ben slimup wrote:
>>> Thanks Danny for your reply,
>>>
>>> but is it a big problem, if the client round-trip packet comes from a
>>> different servers each time? why?
>>>
>>
>> Because NTP uses multiple packets to gain data on the round-trip delay,
>> jitter, etc. of each server it gets responses from. The round-trip delay
> 
> No it doesn't. It uses one outbound and one inbound packet to get the
> delay time. Ie, one packet arrives at the server, and one exits the
> server. Now if you are talking about statistics, that is different, and
> using many will increase the jitter. If the two machines are "good" then
> their times should agree within the jitter anyway.
> 
>> is different if it comes from different systems. In addition each system
>> has its own idea of what the correct time is and at the point that it
>> receives and sends out the reply packet. The resulting data points will
> 
> Not if they are all synchronised to UTC.
> 

What UTC is is not necessarily exactly identical. NIST has one idea of
it and NPL (UK) has a slightly different idea. However that is not what
I was referring to. Each server gets its information from different
sources whether it's a refclock, GPS, another server, etc.. As such
these sources differ somewhat from each other and while NTP tries to get
the best answer possible, each server will have a slight different
answer to the question. They may be only milliseconds apart but they
will be different.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntp server pool advice

[Danny Mayer]

On 12/26/2011 11:17 PM, ben slimup wrote:
> Thanks Danny for your reply,
> 
> but is it a big problem, if the client round-trip packet comes from a
> different servers each time? why?
> 

Because NTP uses multiple packets to gain data on the round-trip delay,
jitter, etc. of each server it gets responses from. The round-trip delay
is different if it comes from different systems. In addition each system
has its own idea of what the correct time is and at the point that it
receives and sends out the reply packet. The resulting data points will
be so uneven if it's coming from the different systems that it will
never select that system as accurate and will almost certainly remove it
from the list of possible candidates. The data for each specific IP
address is collected this way and compared to data from other IP
addresses. Load-balancing breaks that since it's really a different
system that it can get data from. Instead of load balancing you give
each system its own IP address and it can synchronize against those systems.

Danny
> thank you again
> 
>> Date: Mon, 26 Dec 2011 22:39:22 -0500
>> From: ma...@ntp.org
>> To: "terje.mathisen at tmsw.no"@ntp.org
>> CC: questions@lists.ntp.org
>> Subject: Re: [ntp:questions] ntp server pool advice
>>
>> On 12/22/2011 6:40 AM, Terje Mathisen wrote:
>> > ben slimup wrote:
>> >>
>> >> Dear all,
>> >>
>> >> Thank you very much for support,
>> >>
>> >> i do not have 1000,000 client, i need those ntp servers to serve a
>> >> load between 10 to 100 clients
>> >> over a public network with an accuracy of 100ms
>> >>
>> >> those clients will use dns round robin to resolve 4 external ip, 2 IPs
>> >> on each site.
>> >
>> > DO NOT USE ROUND ROBIN DNS for NTP!
>>
>> You can use round robin dns for NTP. There's nothing wrong with that.
>> It's load balancing that must NOT be used as you would get different
>> answers from different systems each time.
>>
>> Danny
>> ___
>> questions mailing list
>> questions@lists.ntp.org
>> http://lists.ntp.org/listinfo/questions

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntp server pool advice

[Danny Mayer]

On 12/22/2011 6:40 AM, Terje Mathisen wrote:
> ben slimup wrote:
>>
>> Dear all,
>>
>> Thank you very much for support,
>>
>> i do not have 1000,000 client, i need those ntp servers to serve a
>> load  between 10 to 100 clients
>> over a public network with an accuracy of 100ms
>>
>> those clients will use dns round robin to resolve 4 external ip, 2 IPs
>> on each site.
> 
> DO NOT USE ROUND ROBIN DNS for NTP!

You can use round robin dns for NTP. There's nothing wrong with that.
It's load balancing that must NOT be used as you would get different
answers from different systems each time.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntp server pool advice

[Danny Mayer]

On 12/21/2011 11:56 PM, ben slimup wrote:
> 
> Thank for prompt answer Chris,
> 
> Unfortunately, this ntp network should give time to specific clients devices 
> and not anyone on the public network.
> 
> according to your advice, better not using load balancer, thats good 
> how to load balance between ntp server if i do not use round robin?
> if
all client choosing the same server then the ntp server will be overload.
> is it a problem if for example client 1 poll or synch with server 1
> ,
and then with server 2 , etc...? or udp roundtrip comes each time from
different ntp server?
> how many ntp servers should be needed to handle that much request
knowing that each card handle 10,000 request per sec?

Do NOT under any circumstances use a load balancer. It will result in
unstable and unusable results because the data from different physical
servers will give different NTP timestamp data. The IP addresses need to
be the same for each request/response as previous ones. You additionally
need at least 4 different servers configured by the client and then NTP
will figure out the best data and discipline the clock.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntp-keygen not working

[Danny Mayer]

On 12/20/2011 11:59 AM, Arpan Gujarati wrote:
> Hi,
> 
> I am trying to generate keys for to enable autokey option with NTP. But I
> am getting a Floating point exception when I try it on Free-BSD machine.
> can anyone please point what may be the possible problem?
> 
> root@ns# ntp-keygen
> Using OpenSSL version OpenSSL 0.9.7e-p1 25 Oct 2004
> Using host ns group ns
> Generating RSA keys (512 bits)...
> Floating point exception: 8 (core dumped)
> 

Please upgrade to a recent version of OpenSSL. Older versions are not
guaranteed to work. If you still get errors after you upgrade then file
a bug report and include the version of ntp you are using.

Danny
> Thanks and Regards
> Arpan
> 

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntp broadcast not working with IPv6

[Danny Mayer]

On 12/19/2011 1:37 PM, E-Mail Sent to this address will be added to the
BlackLists wrote:
> Danny Mayer wrote:
>> rakesh v wrote:
>>> */RV: Iam not saying multicast does not work with IPv4.
>>>  I was saying for IPv6, we can give only multicast
>>>   addresses as part of broadcast command. /*
>>
>> That is correct. There is no such thing as broadcast in IPv6.
> 
> Can it use the all hosts on local links multicast address ff02::1 ?
>  {I haven't looked at the docs for this at all (yet).}

Any multicast address is valid for NTP usage but whether or not it
should be used is a separate question.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntpdate removal is coming

[Danny Mayer]

On 12/12/2011 5:22 PM, Joe Wulf wrote:
>>> On 11/29/2011 1:42 PM, Pete Ashdown wrote:
 Is there anything I can do to decrease the convergence time?
>>> 
>>> Little or nothing! NTPD can, and sometimes does, take ten hours
>>> to
reach "steady state". It needs about thirty minutes to find a
>>> reasonable facsimile of the correct time. For the next nine
>>> hours
and thirty minutes, it will refine that value until it's as good as it's
>>> going to get.
> 
> An IT tech in my world would be fired, probably on the spot, for
giving the above answer as justification for why getting a system
operational takes so long (and we don't have near enough people as it is).
> 

This is a mischaracterization of what's going on. ntpd is able to get a
relatively accurate time within seconds of starting up. Exactly how
quickly depends on a variety of factors. Everything after those few
seconds is to bring the clock frequency to a steady state where both
jitter and delay is as small as ntpd can make it. ntpd goes through a
nunmber of different stages:
1) get the time right;
2) adjust the frequency of the clock so that it stays on time;
3) make smaller adjustments as it refines the frequency even more;
4) a steady state where adjustments are infrequent and small;

Pete was wrong to claim that it takes 30 minutes to get through step 1.
Usually it in the order of 4-7 seconds as long as you use iburst on the
server or pool lines in the config file. If you don't do that it takes a
lot longer. Steve Kostecke has some numbers on how long this takes.
It is the last stage that can take a long time and it can get perturbed
by things like the CPU heating up because you are running backups, heavy
CPU load, the network drops, heavy network traffic etc.

I describe the time to reach stage 4 as the "settling time". It's how
long it takes to reach what is more or less the steady state. It's not
currently something that is currently directly measured though it could
be.The stages before that are geared toward bringing the clock to this
final stage but the clock is already pretty accurate at that point.
Think of it like a spring, move one end too far and it will bounced back
in the other direction rather quickly. Too little and it will take a
long time to get to where it needs to be. The real gory details are in
papers that you can find at http://www.ntp.org/.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntp broadcast not working with IPv6

[Danny Mayer]

On 12/6/2011 11:58 PM, rakesh v wrote:
> Hi Danny,
> Thanks for your valuable reply. Please see my comments/observations inlined
> 
> 
> On Wed, Dec 7, 2011 at 8:54 AM, Danny Mayer  <mailto:ma...@ntp.org>> wrote:
> 
> On 11/30/2011 3:50 AM, rakesh v wrote:
> > Hi,
> > Iam facing issues with ntp broadcast  in case of IPv6.
> > Iam using the latest ntp 4.26p3 package.
> > Can I have a use case scenario for ntp broadcast in IPv6?
> > As I see in the documentation, we can have only multicast
> addresses in IPv6.
> 
> Where did you see that? It's not true, multicast also works with IPv4.
> 
> 
> */RV: Iam not saying multicast does not work with IPv4. I was saying for
> IPv6, we can give only multicast addresses as part of broadcast command. /*

That is correct. There is no such thing as broadcast in IPv6.

> 
> >
> > Here are my configurations:
> > Client side:
> >
> > *# Created by IMI. /etc/ntp.conf*
> > *authenticate yes*
> > *
> 
> What is this? I don't recall such an option.
> 
> */RV: This is to enable authentication./* */However in my case, I was
> trying without authentication. /*
> 

You don't enable or disable authentication with such an option as it
doesn't exist. The corect option is "enable/disable auth"


> 
> > *
> > *# Broadcastclient mode. *
> > *disable auth *
> > *#broadcastclient*
> > *
> > *
> > *multicastclient ff02::101*
> > *
> > *
> > *# Drift file*
> > *driftfile /etc/ntp/drift*
> > *
> > *
> > *# Keys file. *
> > *keys /etc/ntp/keys*
> > *#trustedkey 100*
> >
> >
> > Server Side:
> >
> > *# Created by IMI. /etc/ntp.conf*
> > *server 127.127.1.0  #Local clock*
> > *fudge 127.127.1.0 stratum 2 #Not disciplined*
> > *
> > *
> > *broadcast ff02::101 iburst*
> 
> iburst is invalid.
> 
> */RV: Yes, It is invalid, because it doesn't send burst of packets in
> case of broadcast. It was a misconfiguration./*
> 
> 
> > *#authenticate yes*
> > *
> > *
> > *# Drift file*
> > *driftfile /etc/ntp/drift*
> > *
> > *
> > *# Keys file. *
> > *keys /etc/ntp/keys*
> > *#trustedkey 100*
> >
> > Iam able to see the broadcast packets being received in the client
> but time
> > synchronization does not happen in the client.
> > I have even enabled the authentication on both the sides also. But
> no use.
> > Can somebody help me out from this?
> 
> run ntpd -D2 and see what the output looks like.
> 
> 
> */RV: I couldn't run the ntpd with -D2 option as it is not available./* 
> */These are the options available for ntpd (alphabetically)/*
> 
> /-b no  bcastsync  Allow us to sync to broadcast servers/
> /-c Str configfile configuration file name/
> /-f Str driftfile  frequency drift file name/
> 

I don't know where you are getting these options. That's a very small
subset of the options. If you do not have debug enabled when compiling
you won't get the -D or -d options.

Danny

Danny
> */Are you mentioning about -b option here? How to give that option?/* 
> 
> 
> Danny
> ___
> questions mailing list
> questions@lists.ntp.org <mailto:questions@lists.ntp.org>
> http://lists.ntp.org/listinfo/questions
> 
> 
> 
> 
> -- 
> Regs,
> Rakesh Vanam
> +91 9900 024 002
> 

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntp broadcast not working with IPv6

[Danny Mayer]

On 12/8/2011 11:18 PM, rakesh v wrote:
> Hi Danny,
> Have you got a chance to go through the code for this?
> Here though the socket bind is failing the multicast registration is
> happening successfully (which are shown by the debug traces here.)
> Does that have anything to infer here?
> 

Sorry, no. I've been at a conference almost all week and I've only been
dealing with work related issues outside of the conference.

Danny

> 
> 
> 
>>
>> On Thu, Dec 8, 2011 at 9:58 AM, Danny Mayer  wrote:
>>>
>>> On 12/7/2011 11:15 PM, rakesh v wrote:
>>>> Thanks for your inputs Danny.
>>>>
>>>> Hi Dave,
>>>> Can you give your inputs on this below issue?
>>>> Is the socket bind failing due to the reuse of the udp port 123. But I
>>>> assume for ntp multicast client also we use the same port for listening.
>>>> Or Is it due to some other issue?
>>>>
>>>
>>> I think it is trying to bind to the incorrect address but I'd have to
>>> look carefully at the code to figure out exactly what is going on.
>>>
>>> Danny
>>>
>>>>
>>>>
>>>> On Wed, Dec 7, 2011 at 6:34 PM, Danny Mayer >>> <mailto:ma...@ntp.org>> wrote:
>>>>
>>>> On 12/7/2011 4:53 AM, rakesh v wrote:
>>>> > Hi Danny,
>>>> > Actually I ran the ntpd with Debug option before with a downloaded
>>>> > source code (ntp-4.26p4).
>>>> >
>>>> >
>>>> > These are the logs Iam seeing on the client side...
>>>> >
>>>> > /6 Dec 06:11:52 ntpd[2884]: set_process_priority: Leave priority
>>>> alone:
>>>> > priority_done is <2>/
>>>> > / 6 Dec 06:11:52 ntpd[2884]: proto: precision = 0.208 usec/
>>>> > / 6 Dec 06:11:52 ntpd[2884]: ntp_io: estimated max descriptors:
>>>> 1024,
>>>> > initial socket boundary: 16/
>>>> > / 6 Dec 06:11:52 ntpd[2884]: Listen and drop on 0 v4wildcard
>>>> 0.0.0.0 UDP
>>>> > 123/
>>>> > / 6 Dec 06:11:52 ntpd[2884]: Listen and drop on 1 v6wildcard ::
>>>> UDP 123/
>>>> > / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 2 lo 127.0.0.1 UDP
>>>> 123/
>>>> > / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 3 eth1 10.16.34.6
>>>> UDP 123/
>>>> > / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 4 lo ::1 UDP 123/
>>>> > / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 5 eth2 2000::2 UDP
>>>> 123/
>>>> > / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 6 eth1
>>>> > fe80::a00:27ff:fe68:7b4c UDP 123/
>>>> > / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 7 eth2
>>>> > fe80::a00:27ff:fe38:605 UDP 123/
>>>> > / 6 Dec 06:11:52 ntpd[2884]: peers refreshed/
>>>> > / 6 Dec 06:11:52 ntpd[2884]: Listening on routing socket on fd #24
>>>> for
>>>> > interface updates/
>>>> > / *6 Dec 06:11:52 ntpd[2884]: bind(25) AF_INET6 ff02::101#123
>>>> > (multicast) flags 0x0 failed: Invalid argument*/
>>>> > / 6 Dec 06:11:52 ntpd[2884]: multicast address ff02::101 using
>>>> wildcard
>>>> > interface #1 v6wildcard/
>>>> > / 6 Dec 06:11:52 ntpd[2884]: Joined :: socket to multicast group
>>>> ff02::101/
>>>> > /
>>>> > /
>>>> > Actually Iam able to see only one Broadcast packet being received
>>>> on
>>>> > client side in wireshark. Packets are not received.
>>>> > Here Iam not sure why the socket bind is failing for ntpd? Any
>>>> inputs on
>>>> > this?
>>>>
>>>> That sounds like a bug. I haven't looked at that area of the code
>>>> recently but being unable to bind to the socket would prevent it
>>>> receiving packets. Dave Hart has touched this area recently may will
>>>> likely know more. I do remember some issues with multicast but I
>>>> don't
>>>> remember this one.
>>>>
>>>> Danny
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Thanks & Regs,
>>>> Rakesh
>>>>
>>>>
>>>
>>
>>
>>
>> --
>>
>>
>>
>>
>> --
>> Regs,
>> Rakesh Vanam
>> +91 9900 024 002
>>
>>
>>
>>
>> --
>>
> 
> 
> 

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] offset bias in ntpd

[Danny Mayer]

On 12/8/2011 7:37 AM, Bruce Lilly wrote:
> Some code in ntpd applies a dither using ntp_random.  However,
> ntp_random (which is also used elsewhere, e.g. in getting an
> initial association ID) generates only positive integers,
> resulting in a one-sided offset bias.  The following patch
> compensates for this bias by offsetting the return value
> from ntp_random to produce approximately zero mean dither
> in both positive and negative offset directions in the
> functions which use ntp_random for dither.
> 

This belongs in bugzilla http://bugs.ntp.org/ rather than questions/cptn
newsgroup. Please also use diff -u and post that to bugzilla as an
attachment.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntp broadcast not working with IPv6

[Danny Mayer]

On 12/7/2011 11:15 PM, rakesh v wrote:
> Thanks for your inputs Danny.
> 
> Hi Dave,
> Can you give your inputs on this below issue?
> Is the socket bind failing due to the reuse of the udp port 123. But I
> assume for ntp multicast client also we use the same port for listening.
> Or Is it due to some other issue?
> 

I think it is trying to bind to the incorrect address but I'd have to
look carefully at the code to figure out exactly what is going on.

Danny

> 
> 
> On Wed, Dec 7, 2011 at 6:34 PM, Danny Mayer  <mailto:ma...@ntp.org>> wrote:
> 
> On 12/7/2011 4:53 AM, rakesh v wrote:
> > Hi Danny,
> > Actually I ran the ntpd with Debug option before with a downloaded
> > source code (ntp-4.26p4).
> >
> >
> > These are the logs Iam seeing on the client side...
> >
> > /6 Dec 06:11:52 ntpd[2884]: set_process_priority: Leave priority
> alone:
> > priority_done is <2>/
> > / 6 Dec 06:11:52 ntpd[2884]: proto: precision = 0.208 usec/
> > / 6 Dec 06:11:52 ntpd[2884]: ntp_io: estimated max descriptors: 1024,
> > initial socket boundary: 16/
> > / 6 Dec 06:11:52 ntpd[2884]: Listen and drop on 0 v4wildcard
> 0.0.0.0 UDP
> > 123/
> > / 6 Dec 06:11:52 ntpd[2884]: Listen and drop on 1 v6wildcard ::
> UDP 123/
> > / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 2 lo 127.0.0.1 UDP
> 123/
> > / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 3 eth1 10.16.34.6
> UDP 123/
> > / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 4 lo ::1 UDP 123/
> > / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 5 eth2 2000::2 UDP
> 123/
> > / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 6 eth1
> > fe80::a00:27ff:fe68:7b4c UDP 123/
> > / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 7 eth2
> > fe80::a00:27ff:fe38:605 UDP 123/
> > / 6 Dec 06:11:52 ntpd[2884]: peers refreshed/
> > / 6 Dec 06:11:52 ntpd[2884]: Listening on routing socket on fd #24 for
> > interface updates/
> > / *6 Dec 06:11:52 ntpd[2884]: bind(25) AF_INET6 ff02::101#123
> > (multicast) flags 0x0 failed: Invalid argument*/
> > / 6 Dec 06:11:52 ntpd[2884]: multicast address ff02::101 using
> wildcard
> > interface #1 v6wildcard/
> > / 6 Dec 06:11:52 ntpd[2884]: Joined :: socket to multicast group
> ff02::101/
> > /
> > /
> > Actually Iam able to see only one Broadcast packet being received on
> > client side in wireshark. Packets are not received.
> > Here Iam not sure why the socket bind is failing for ntpd? Any
> inputs on
> > this?
> 
> That sounds like a bug. I haven't looked at that area of the code
> recently but being unable to bind to the socket would prevent it
> receiving packets. Dave Hart has touched this area recently may will
> likely know more. I do remember some issues with multicast but I don't
> remember this one.
> 
> Danny
> 
> 
> 
> 
> -- 
> Thanks & Regs,
> Rakesh
> 
> 

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntp broadcast not working with IPv6

[Danny Mayer]

On 12/7/2011 4:53 AM, rakesh v wrote:
> Hi Danny,
> Actually I ran the ntpd with Debug option before with a downloaded
> source code (ntp-4.26p4).
> 
> 
> These are the logs Iam seeing on the client side...
> 
> /6 Dec 06:11:52 ntpd[2884]: set_process_priority: Leave priority alone:
> priority_done is <2>/
> / 6 Dec 06:11:52 ntpd[2884]: proto: precision = 0.208 usec/
> / 6 Dec 06:11:52 ntpd[2884]: ntp_io: estimated max descriptors: 1024,
> initial socket boundary: 16/
> / 6 Dec 06:11:52 ntpd[2884]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP
> 123/
> / 6 Dec 06:11:52 ntpd[2884]: Listen and drop on 1 v6wildcard :: UDP 123/
> / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 2 lo 127.0.0.1 UDP 123/
> / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 3 eth1 10.16.34.6 UDP 123/
> / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 4 lo ::1 UDP 123/
> / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 5 eth2 2000::2 UDP 123/
> / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 6 eth1
> fe80::a00:27ff:fe68:7b4c UDP 123/
> / 6 Dec 06:11:52 ntpd[2884]: Listen normally on 7 eth2
> fe80::a00:27ff:fe38:605 UDP 123/
> / 6 Dec 06:11:52 ntpd[2884]: peers refreshed/
> / 6 Dec 06:11:52 ntpd[2884]: Listening on routing socket on fd #24 for
> interface updates/
> / *6 Dec 06:11:52 ntpd[2884]: bind(25) AF_INET6 ff02::101#123
> (multicast) flags 0x0 failed: Invalid argument*/
> / 6 Dec 06:11:52 ntpd[2884]: multicast address ff02::101 using wildcard
> interface #1 v6wildcard/
> / 6 Dec 06:11:52 ntpd[2884]: Joined :: socket to multicast group ff02::101/
> /
> /
> Actually Iam able to see only one Broadcast packet being received on
> client side in wireshark. Packets are not received.
> Here Iam not sure why the socket bind is failing for ntpd? Any inputs on
> this?

That sounds like a bug. I haven't looked at that area of the code
recently but being unable to bind to the socket would prevent it
receiving packets. Dave Hart has touched this area recently may will
likely know more. I do remember some issues with multicast but I don't
remember this one.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntp broadcast not working with IPv6

[Danny Mayer]

On 11/30/2011 3:50 AM, rakesh v wrote:
> Hi,
> Iam facing issues with ntp broadcast  in case of IPv6.
> Iam using the latest ntp 4.26p3 package.
> Can I have a use case scenario for ntp broadcast in IPv6?
> As I see in the documentation, we can have only multicast addresses in IPv6.

Where did you see that? It's not true, multicast also works with IPv4.
> 
> Here are my configurations:
> Client side:
> 
> *# Created by IMI. /etc/ntp.conf*
> *authenticate yes*
> *

What is this? I don't recall such an option.

> *
> *# Broadcastclient mode. *
> *disable auth *
> *#broadcastclient*
> *
> *
> *multicastclient ff02::101*
> *
> *
> *# Drift file*
> *driftfile /etc/ntp/drift*
> *
> *
> *# Keys file. *
> *keys /etc/ntp/keys*
> *#trustedkey 100*
> 
> 
> Server Side:
> 
> *# Created by IMI. /etc/ntp.conf*
> *server 127.127.1.0  #Local clock*
> *fudge 127.127.1.0 stratum 2 #Not disciplined*
> *
> *
> *broadcast ff02::101 iburst*

iburst is invalid.

> *#authenticate yes*
> *
> *
> *# Drift file*
> *driftfile /etc/ntp/drift*
> *
> *
> *# Keys file. *
> *keys /etc/ntp/keys*
> *#trustedkey 100*
> 
> Iam able to see the broadcast packets being received in the client but time
> synchronization does not happen in the client.
> I have even enabled the authentication on both the sides also. But no use.
> Can somebody help me out from this?

run ntpd -D2 and see what the output looks like.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP Denial of Service attack 29 November 2011

[Danny Mayer]

On 11/30/2011 12:26 PM, Rob wrote:
> unruh  wrote:
>> On 2011-11-30, Rob  wrote:
>>> Danny Mayer  wrote:
>>>> On 11/29/2011 4:57 PM, Rich wrote:
>>>>>
>>>>>> Isn't that a bit wide a range to block for only 4 IPs?
>>>>>> What makes you think any further attacks will come from the same range?
>>>>>>
>>>>> Only my 17 years experience at the stratum 1 level.  I see little
>>>>> value in providing NTP to Asian Pacific networks from Washington, DC.
>>>>
>>>>
>>>> I agree. Not following the rules of engagement for stratum 1/2 servers
>>>> can mean you block all NTP traffic from those nodes or issuing
>>>> occasional KOD packets to those nodes.
>>>
>>> Yes, sure.   But blocking an entire region because of 4 abusers?
>>
>> Why not. As he says, he sees no reason to supply time to somewhere half
>> a world away. It would be lousy time anyway. And if providing it causes
>> trouble as well, that makes the decision easy. 
> 
> He does not only block entire /8 networks based on his own evaluation
> of the value of his service to people in those networks, he also advises
> others to do the same.
> 
> That means he is not really concerned that the time service of his server
> would be of no value to those people; he just wants to deprive the
> people of that network from all NTP service.
> 
> I think it is disgusting.  Hackers live everywhere, also in the USA.
> Cutting off a whole region from NTP service is not going to solve that.
> When they really are after his service, the hackers will quickly find
> a network from where they can DOS his server and which he cannot cut
> off so lightheartedly at /8 level.
> 
> But the worst is his recommendation to others to do the same.
> Everyone can decide what networks to block on his servers based on his
> own personal judgement and service criteria.  But recommending others
> to blindly follow that is well over the line of acceptable.

Rich works for the US Military and as such he can decide what's best for
the US Military. His recommendations to others are just that. As for
Hackers, if this was being sent from the different places in the US it
would have been a different decision and recommendation. The FBI would
also be out investigating. They still may be.

Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP Denial of Service attack 29 November 2011

[Danny Mayer]

On 11/30/2011 4:35 AM, Rob wrote:
> Danny Mayer  wrote:
>> On 11/29/2011 4:57 PM, Rich wrote:
>>>
>>>> Isn't that a bit wide a range to block for only 4 IPs?
>>>> What makes you think any further attacks will come from the same range?
>>>>
>>> Only my 17 years experience at the stratum 1 level.  I see little
>>> value in providing NTP to Asian Pacific networks from Washington, DC.
>>
>>
>> I agree. Not following the rules of engagement for stratum 1/2 servers
>> can mean you block all NTP traffic from those nodes or issuing
>> occasional KOD packets to those nodes.
> 
> Yes, sure.   But blocking an entire region because of 4 abusers?

Yes. In this case they are not following the rules of engagement.
Sending packets from another Continent doesn't make a lot of sense in
any case.

Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] NTP Denial of Service attack 29 November 2011

[Danny Mayer]

On 11/29/2011 4:57 PM, Rich wrote:
> 
>> Isn't that a bit wide a range to block for only 4 IPs?
>> What makes you think any further attacks will come from the same range?
>>
> Only my 17 years experience at the stratum 1 level.  I see little
> value in providing NTP to Asian Pacific networks from Washington, DC.


I agree. Not following the rules of engagement for stratum 1/2 servers
can mean you block all NTP traffic from those nodes or issuing
occasional KOD packets to those nodes. It is also possible a vendor
thought it would be a great idea to hardcode some NTP server addresses
in their routers and switches. We've also see that happen too.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Choice of local reference clock seems to affect synchronization on a leaf node

[Danny Mayer]

On 11/7/2011 5:41 PM, Dave Hart wrote:
> On Mon, Nov 7, 2011 at 21:58, unruh  wrote:
>> Actually, that is not the way that ntpd works. It has no concept of
>> "frequency error".
> 
> Sure does, the frequency error is the frequency= value reported by
> ntpq, internally in ntpd stored in drift_comp, and persisted between
> runs in the driftfile.  Perhaps you were thinking of short-term
> frequency error due to temperature changes?
> 

Technically I would describe it as a frequency correction rather than an
error. There are really two types of frequency changes in the system,
one is the steady-state frequency change and the other is the changes
necessary to have the clock catch up  or slow down to the reference
clock. What's in the drift file is the steady-state frequency correction.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Choice of local reference clock seems to affect synchronization on a leaf node

[Danny Mayer]

On 11/7/2011 4:58 PM, unruh wrote:
> On 2011-11-07, Nathan Kitchen  wrote:
>> On Sun, Nov 6, 2011 at 2:13 PM, Danny Mayer  wrote:
>>> On 11/4/2011 7:27 PM, Nathan Kitchen wrote:
>>>> I'm curious about some behavior that I'm observing on a host running
>>>> ntpd as a client. As I understand it, configuring a local reference
>>>> clock--either an undisciplined local clock or orphan mode--shouldn't
>>>> help me, but I see different behavior when I do have one. In
>>>> particular, when I'm synchronizing after correcting a very large
>>>> offset, I synchronize about 2x faster in orphan mode than with no
>>>> local clock, and with an undisciplined local clock I don't even fix
>>>> the offset.
>>>>
>>>> I'm curious about whether this difference should be expected.
>>>>
>>>> I'm using the following configuration in all cases:
>>>>
>>>> ? ?driftfile /persist/local/ntp.drift
>>>> ? ?server 172.22.22.50 iburst
>>>>
>>>> My three different configurations for local clocks are the following:
>>>>
>>>> 1. No additional commands
>>>>
>>>> 2. tos orphan 10
>>>>
>>>> 3. server 127.127.1.0
>>>> ? ? fudge 127.127.1.0 stratum 10
>>>>
>>>> In all three cases, my test has these steps:
>>>>
>>>> 1. Stop ntpd.
>>>> 2. Set the clock to 2000-1-1 00:00:00 (that is, more than 10 years ago).
>>>> 3. Run ntpd -g.
>>>> 4. Check that the 11-year offset is corrected.
>>>> 5. Wait for synchronization to the time server.
>>>>
>>>> With either configuration #1 (no local clock) or #2 (orphan mode), the
>>>> offset is corrected quickly: 4 and 13 seconds, respectively. With
>>>> configuration #3 (undisciplined local clock), it fails to be corrected
>>>> within 60 seconds.
>>>
>>> In case #3 that's expected if there are no servers to get the correct
>>> time. What else would you expect? Where would it get it's time from?
>>
>> In case #3, as in the other cases, the configuration includes the
>> server 172.22.22.50.
>>
>>>> After the offset is corrected, configuration #1 takes 921 seconds to
>>>> synchronize to the server. Configuration #2 takes 472.
>>>>
>>>
>>> First, correcting the offset is the major concern. After that figuring
>>> out the frequency changes need to be calculated with additional packets
>>> being received and that takes time. It needs to have enough of them to
>>> do the calculation.
> 
> Actually, that is not the way that ntpd works. It has no concept of
> "frequency error". All it knows is the offset. It then changes the
> frequency in order to correct the offset. It does not correct the offset
> directly. It never figures out what the frequency error is. All it does
> is "If offset is positive, speed up the clock, if negative slow it down"
> ( where I am defining the offset at "'true' time- system clock time").
>  (There is lots that goes into ntp's best estimate of the 'true' time,
> which is irrelevant to this discussion)

I never said anything about frequency error. Where did you read that? I
talked about frequency changes. The changes you mention that speed up or
slow down the clock to bring it into alignment with the reference
clocks. That has to be calculated and you need enough packet exchanges
to do that.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Choice of local reference clock seems to affect synchronization on a leaf node

[Danny Mayer]

On 11/4/2011 7:27 PM, Nathan Kitchen wrote:
> I'm curious about some behavior that I'm observing on a host running
> ntpd as a client. As I understand it, configuring a local reference
> clock--either an undisciplined local clock or orphan mode--shouldn't
> help me, but I see different behavior when I do have one. In
> particular, when I'm synchronizing after correcting a very large
> offset, I synchronize about 2x faster in orphan mode than with no
> local clock, and with an undisciplined local clock I don't even fix
> the offset.
> 
> I'm curious about whether this difference should be expected.
> 
> I'm using the following configuration in all cases:
> 
>driftfile /persist/local/ntp.drift
>server 172.22.22.50 iburst
> 
> My three different configurations for local clocks are the following:
> 
> 1. No additional commands
> 
> 2. tos orphan 10
> 
> 3. server 127.127.1.0
> fudge 127.127.1.0 stratum 10
> 
> In all three cases, my test has these steps:
> 
> 1. Stop ntpd.
> 2. Set the clock to 2000-1-1 00:00:00 (that is, more than 10 years ago).
> 3. Run ntpd -g.
> 4. Check that the 11-year offset is corrected.
> 5. Wait for synchronization to the time server.
> 
> With either configuration #1 (no local clock) or #2 (orphan mode), the
> offset is corrected quickly: 4 and 13 seconds, respectively. With
> configuration #3 (undisciplined local clock), it fails to be corrected
> within 60 seconds.

In case #3 that's expected if there are no servers to get the correct
time. What else would you expect? Where would it get it's time from?

> After the offset is corrected, configuration #1 takes 921 seconds to
> synchronize to the server. Configuration #2 takes 472.
> 

First, correcting the offset is the major concern. After that figuring
out the frequency changes need to be calculated with additional packets
being received and that takes time. It needs to have enough of them to
do the calculation.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] suit against timezone database

[Danny Mayer]

On 10/6/2011 3:31 PM, Yan Seiner wrote:
> Just came across this on /.
> 
> http://yro.slashdot.org/story/11/10/06/1743226/civil-suit-filed-involving-the-time-zone-database
> 
> ??
> 

ICANN has taken over responsibility for the timezone database and you
can get it here: http://www.iana.org/time-zones

See the story here:
http://abcnews.go.com/Technology/wireStory/time-zone-database-home-lawsuit-14748312

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] EXTERNAL: Re: Issue with peering and orphan mode

[Danny Mayer]

On 10/10/2011 8:01 AM, Conner, Matthew wrote:
> Danny,
> 
> Thank you for the response.
> 
> We specify minpoll/maxpoll because of specific time requirements on
our system. The system needs to stay within a 1ms offset and must poll
no less than every 32 seconds. The system is completely closed off with
the exception of the TFDS servers which are basically GPS modules. The
only servers that query the TFDSs are these "timehosts". Since peers are
only used in case of a stratum 1 failure, I may try removing
minpoll/maxpoll from the peers to see if it helps in resolving our issue.
> 

It's a common mistake to assume that using minpoll/maxpoll will improve
alignment of the clocks, it doesn't. It has to do with polling frequency
which you want to decrease as ntpd settles down to a stable state. Once
it settles down you want the clock changes to be more gradual  and react
to longer-term changes rather than shorter-term spikes that can occur at
any time.


> As for the prefer statement, it only comes into play when the
> Stratum
1 servers are available. Would that really still affect Orphan mode?
> 

If the tfds1 server is the only stratum 1 server it will automatically
be selected as a result. Even if it is only a stratum 2 it will be
automatically selected.

> Any idea why this issue wasn't seen in 4.2.4p7?
> 

No, there have been a lot of changes in this area.


Danny

> Thanks,
> 
> Matt Conner
> 
> 
> -Original Message-
> From: Danny Mayer [mailto:ma...@ntp.org] 
> Sent: Sunday, October 09, 2011 4:44 PM
> To: Conner, Matthew
> Cc: questions@lists.ntp.org
> Subject: EXTERNAL: Re: [ntp:questions] Issue with peering and orphan mode
> 
> On 10/6/2011 3:11 PM, Conner, Matthew wrote:
>> We are experiencing an issue using Orphan mode and peering in our ntpd 
>> 4.2.6p4 set-up. With the loss of our stratum 1 time hosts, the stratum 2 are 
>> not properly choosing a primary time provider. Below is our ntp.conf for all 
>> 4 of the stratum 2 servers:
>>
>> tinker step .010 stepout 60 panic 0
>> server tfds1 prefer minpoll 4 maxpoll 5 burst iburst
>> server tfds2 minpoll 4 maxpoll 5 burst iburst
>> server tfds3 minpoll 4 maxpoll 5 burst iburst
>>
>> peer timehost1 minpoll 4 maxpoll 5 burst iburst
>> peer timehost2 minpoll 4 maxpoll 5 burst iburst
>> peer timehost3 minpoll 4 maxpoll 5 burst iburst
>> peer timehost4 minpoll 4 maxpoll 5 burst iburst
>>
>> tos orphan 4
>>
>> driftfile /etc/ntp/drift
>>
> 
> Why did you think it was a good idea to set minpoll to 4 and maxpoll to
> 5? Unless you have a very good understanding of how NTP operates you
> should never be specifying minpoll and maxpoll. It's is rarely necessary
> and is usually detrimental to your NTP server. Also the prefer keyword
> is not beneficial to Orphan mode. The peer select from among each other.
> 
> Danny
> 
>> The stratum 2 (timehost[1-4]) attempt to peer with the loss of the stratum 1 
>> (tfds[1-3]}. However, instead of them all staying at stratum 4 as was seen 
>> when using ntpd 4.2.4p7 (have other issues with 4.2.4p7 and need to update), 
>> the peers are dropping down 1 stratum from the peer they are locking to. 
>> Since they are peering to one another, this results in the timehosts slowly 
>> dropping in stratum as they attempt to stay 1 stratum below the locked to 
>> host. They continue to drop in stratum until reaching a stratum 16. Once 
>> they hit stratum 16, all other hosts disconnect and the peers previously 
>> locking to the now stratum 16 host will unlock and jump back to a stratum 4. 
>> Once at least 1  peer jumps back to 4, the others will begin jumping to 
>> stratum 4-5. This process will repeat itself until the stratum 1 hosts are 
>> reconnected or the timehosts choose a primary. We have only once seen it 
>> stabilize with all 4 hosts and it took almost a full 24 hours to do so. With 
>> only 3 timehos
t
> s r
>>  unning, they will stabilize within minutes.
>>
>> >From what we are able to tell, a primary peer is chosen when 3 of the 4 
>> >timehosts lock to the same peer.  When the 4th peer sees that the others 
>> >are all connected to it, it syncs to its internal clock and remains a 
>> >stratum 4. Is this correct, or is something else going on here?
>>
>> Further questions:
>> Are the peers intentionally dropping below the orphan mode set stratum, or 
>> is that a bug?
>> Are we missing anything in ntp.conf to make orphan mode work properly?
>> Is this possibly just a limitation 

Re: [ntp:questions] Issue with peering and orphan mode

[Danny Mayer]

On 10/6/2011 3:11 PM, Conner, Matthew wrote:
> We are experiencing an issue using Orphan mode and peering in our ntpd 
> 4.2.6p4 set-up. With the loss of our stratum 1 time hosts, the stratum 2 are 
> not properly choosing a primary time provider. Below is our ntp.conf for all 
> 4 of the stratum 2 servers:
> 
> tinker step .010 stepout 60 panic 0
> server tfds1 prefer minpoll 4 maxpoll 5 burst iburst
> server tfds2 minpoll 4 maxpoll 5 burst iburst
> server tfds3 minpoll 4 maxpoll 5 burst iburst
> 
> peer timehost1 minpoll 4 maxpoll 5 burst iburst
> peer timehost2 minpoll 4 maxpoll 5 burst iburst
> peer timehost3 minpoll 4 maxpoll 5 burst iburst
> peer timehost4 minpoll 4 maxpoll 5 burst iburst
> 
> tos orphan 4
> 
> driftfile /etc/ntp/drift
> 

Why did you think it was a good idea to set minpoll to 4 and maxpoll to
5? Unless you have a very good understanding of how NTP operates you
should never be specifying minpoll and maxpoll. It's is rarely necessary
and is usually detrimental to your NTP server. Also the prefer keyword
is not beneficial to Orphan mode. The peer select from among each other.

Danny

> The stratum 2 (timehost[1-4]) attempt to peer with the loss of the stratum 1 
> (tfds[1-3]}. However, instead of them all staying at stratum 4 as was seen 
> when using ntpd 4.2.4p7 (have other issues with 4.2.4p7 and need to update), 
> the peers are dropping down 1 stratum from the peer they are locking to. 
> Since they are peering to one another, this results in the timehosts slowly 
> dropping in stratum as they attempt to stay 1 stratum below the locked to 
> host. They continue to drop in stratum until reaching a stratum 16. Once they 
> hit stratum 16, all other hosts disconnect and the peers previously locking 
> to the now stratum 16 host will unlock and jump back to a stratum 4. Once at 
> least 1  peer jumps back to 4, the others will begin jumping to stratum 4-5. 
> This process will repeat itself until the stratum 1 hosts are reconnected or 
> the timehosts choose a primary. We have only once seen it stabilize with all 
> 4 hosts and it took almost a full 24 hours to do so. With only 3 timehost
s r
>  unning, they will stabilize within minutes.
> 
>>From what we are able to tell, a primary peer is chosen when 3 of the 4 
>>timehosts lock to the same peer.  When the 4th peer sees that the others are 
>>all connected to it, it syncs to its internal clock and remains a stratum 4. 
>>Is this correct, or is something else going on here?
> 
> Further questions:
> Are the peers intentionally dropping below the orphan mode set stratum, or is 
> that a bug?
> Are we missing anything in ntp.conf to make orphan mode work properly?
> Is this possibly just a limitation on the number of peers?
> If working as intended, is there a way to force a primary peer quicker?
> 
> Note: We have tested without burst/iburst on the peer declarations as well as 
> the removal of the timehost declaration of the host itself. None of these 
> modifications had an impact.
> 
> Thanks,
> 
> 
> Matt
> 
> ___
> questions mailing list
> questions@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
> 

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] RFC section 7.4 b. wording seems off for the desired action.

[Danny Mayer]

On 9/29/2011 5:32 PM, jni...@brocade.com wrote:
>>From the RFC 5905 (Jun 2010)
> 7.4. The Kiss-o’-Death Packet
> If the Stratum field is 0, which implies unspecified or invalid, the
> Reference Identifier field can be used to convey messages useful for
> status reporting and access control. These are called Kiss-o’-Death
> (KoD) packets and the ASCII messages they convey are called kiss
> codes. The KoD packets got their name because an early use was to
> tell clients to stop sending packets that violate server access
> controls. The kiss codes can provide useful information for an
> intelligent client, either NTPv4 or SNTPv4. Kiss codes are encoded
> in four-character ASCII strings that are left justified and zero
> filled. The strings are designed for character displays and log
> files. A list of the currently defined kiss codes is given in
> Figure 13. Recipients of kiss codes MUST inspect them and, in the
> following cases, take these actions:
> a. For kiss codes DENY and RSTR, the client MUST demobilize any
> associations to that server and stop sending packets to that
> server;
> b. For kiss code RATE, the client MUST immediately reduce its
> polling interval to that server and continue to reduce it each
> time it receives a RATE kiss code.
> c. Kiss codes beginning with the ASCII character "X" are for
> unregistered experimentation and development and MUST be ignored
> if not recognized.
> d. Other than the above conditions, KoD packets have no protocol
> significance and are discarded after inspection.
> 
> For list item  b.  (RATE code) action the way I understand it, if the
> client is at a poll of 2^6 (64 seconds ) upon receiving a RATE code
> from the server and reduce it to polling interval of the server
> (something less or equal to then 2^5 or 40 seconds), and continue
> reducing it for each subsequent RATE message till the minimum poll
> interval of 2^4 (16 seconds) is reached. This would result in the
> client polling the server more often, and continuing to exceed the
> rate would it not?
> 
> Should list item b. instead read "For the kiss code RATE, the client
> MUST immediately increase its polling interval to that of the server,
> and continue to increase it each time it  receives a RATE kiss code."?

You are correct. That's an error. it should be increase rather than
reduce, or put it another way reduce the frequency. Thanks for spotting
that.

I'm copying the Working Group on this. We'll need to get an errata
issued on RFC 5905.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Magice Server Numbers: 4,5,7,9

[Danny Mayer]

Dave,

What I said about marauding gangs of clock cliques still holds. Also the
last time I looked at the code the number 10 applied when you specified
pool and would only take the number of servers already specified plus
the number of pool servers needs to get to 10 if there were that many.

Danny

On 9/16/2011 10:12 AM, David L. Mills wrote:
> Danny,
> 
> We would not be having this discussion if folks read "how NTP works" in
> the online documentation. The maximum number of selectable candidates is
> not limited to ten. Ten is the high water mark for the number of
> preemptable candidates mobilized by the manycast and pool modes.
> 
> Dave
> 
> Danny Mayer wrote:
>> On 9/16/2011 2:24 AM, unruh wrote:
>>
>>   
>>>> 6.  Seven clocks allow for the failure of three.
>>>> Etc, etc. . . .
>>>>   
>>> The only answer is to have at least 11 clocks although that
>>> is also not foolproof:-) 
>>> 
>>
>> Actually no. If you get too many reference clocks they will start to
>> gang up against each other and it becomes impossibly complex to try and
>> decide which set to use. As the number of clocks increase the number of
>> gangs will likely increase. That's why the reference implementation
>> limits the number of reference clocks to 10.
>>
>> Danny
>> ___
>> questions mailing list
>> questions@lists.ntp.org
>> http://lists.ntp.org/listinfo/questions
>>   
> 

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Magice Server Numbers: 4,5,7,9

[Danny Mayer]

On 9/16/2011 2:24 AM, unruh wrote:

>> 6.  Seven clocks allow for the failure of three.
>> Etc, etc. . . .
> 
> The only answer is to have at least 11 clocks although that
> is also not foolproof:-) 

Actually no. If you get too many reference clocks they will start to
gang up against each other and it becomes impossibly complex to try and
decide which set to use. As the number of clocks increase the number of
gangs will likely increase. That's why the reference implementation
limits the number of reference clocks to 10.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

[ntp:questions] Fwd: [dnsext] sands of time

[Danny Mayer]

Sigh! Didn't we just go through this? Or is it the same one?

 Original Message 
Subject: [dnsext] sands of time
Date: Tue, 30 Aug 2011 16:11:18 +
From: bmann...@vacation.karoshi.com
To: dns...@ietf.org
CC: bmann...@vacation.karoshi.com

There is a plan to fundamentally change the calulations of UTC.

Stephan posted this a few days back, I'll note that comments are due by
31aug2011
(thats tomorrow for me)


http://hpiers.obspm.fr/eop-pc/index.php?index=questionnaire

Its worth a look.

/bill
___
dnsext mailing list
dns...@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Receiving a message with imsg type - 15

[Danny Mayer]

On 8/25/2011 9:33 AM, adline.dsi...@wipro.com wrote:
> Hi all,
> 
>  
> 
>I'm new to NTP. Currently I'm facing an issue where, during
> shutdown my client application is receiving a message from ntp demon
> with message type 15. Since this is an unexpected message type, my
> application crashes. Not always ntpd sends this message. Chances of
> getting a message are once or twice out of 20-25 trys. Can anyone help
> why I'm receiving a ntp message with message type 15? 
> 

What client are you using? What ntp server are you using? What O/S's?
There is no such thing as a imsg type 15 in the NTP protocol. See RFC
5905. NTP protocol does not use imsg types at all. The NTP packet types
are defined in the RFC and that is the only type of packet an NTP server
will use.

> expected message types are:
> 
> enum imsg_type {
> 
> IMSG_NONE,
> 
> IMSG_ADJTIME,
> 
> IMSG_ADJFREQ,
> 
> IMSG_SETTIME,
> 
> IMSG_HOST_DNS
> 
> };
> 
An NTP server has no way of telling you what to do since it is up to the
client to make that decision based on the timestamps it receives. It
certainly cannot say anything about DNS since that's up to the client to
decide what to query. Whatever you are doing has nothing to do with NTP
no matter what the implementation.

> 
> Thanks & Regards,
> 
> Adline.
> 
> The information contained in this electronic message and any
> attachments to this message are intended for the exclusive use of the
> addressee(s) and may contain proprietary, confidential or privileged
> information. If you are not the intended recipient, you should not
> disseminate, distribute or copy this e-mail. Please notify the sender
> immediately and destroy all copies of this message and any
> attachments.

I don't think so. This is a public forum and anything you transmit here
is not only public but also indexed by the various search engines. Keep
this kind of signatures for confidential messages, not that they have
any value anyway.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntpd

[Danny Mayer]

On 8/2/2011 12:11 PM, Valera wrote:
> 
> 
> 02.08.2011 19:26, Danny Mayer пишет:
>> On 7/29/2011 9:47 AM, Valera wrote:
>>> Hello.
>>>
>>> I have some issues with ntp-4.2.6p3 package which was downloaded from
>>> www.ntp.org
>>> I did all build stages such as: ./configure and make. After that I tried
>>> to execute obtained ntpd binary file with arguments "-p
>>> /var/run/ntpd.pid -g". Full execution string is: sudo
>>> ~/ntp-4.2.6p3/ntpd/ntpd -p /var/run/ntpd.pid -g
>>> The ntpd binary file related to my ubuntu 11.04 reliase works and
>>> syncronizes time with default ubuntu time servers fine. But ntpd from
>>> ntp-4.2.6p3 works without any visible issues but didn't syncronize local
>>> time with time servers.
>>> Both servers were executed with the same argument strings and the same
>>> configureation files. I think that this issue may be related to
>>> configuration(in config.h for example) but can't find the place.
>>>
>>> Best wishes.
>> I installed a prebuilt ntp package on ubuntu last week using apt-get. It
>> gave me 4.2.6p2. Do you know what you got?
>>
> I got the same version.
>> I did have to fix the ntp.conf file because they did not use any iburst
>> lines and I did change it to use the pool option rather than server
>> option to fetch a number of addresses to use. Are you using the ubuntu
>> configuration unchanged?
>>
> Yes I'm using ntp.conf without any changes.What I should change in my's
> configuration file?
>> Did you run ntpq -p to see what if anything you are getting for servers?
>> Can you post it here?
>>

pool 0.ubuntu.pool.ntp.org iburst
pool 1.ubuntu.pool.ntp.org iburst
#server 2.ubuntu.pool.ntp.org
#server 3.ubuntu.pool.ntp.org
# Use Ubuntu's ntp server as a fallback.
server ntp.ubuntu.com iburst

for the servers
> 
> vvs@sigaev:~$ ~/work/ntp-4.2.6p3/ntpq/ntpq -p
>  remote   refid  st t when poll reach   delay  
> offset  jitter
> 
> ==
> -c53n253.polustr 131.188.3.2202 u3   64  3774.825 
> 273.376   1.615
> +mail.bisel.ru   62.149.0.30  2 u   65   64  3779.834 
> 315.948   1.293
> -webhost.mitht.r 81.95.131.1303 u3   64  377   12.084 
> 302.347   0.312
> *194.190.16.51   62.117.76.1382 u   66   64  377   12.631 
> 315.785   0.446
> +europium.canoni 193.79.237.142 u   11   64  377   47.618 
> 309.748   5.935
> vvs@sigaev:~$
> vvs@sigaev:~$ ~/work/ntp-4.2.6p3/sntp/sntp 194.190.16.51
>  2 Aug 19:59:25 sntp[18295]: Started sntp
> 2011-08-02 19:59:25.052161 (-0300) +0.315752 +/- 0.018951 secs
> 

This looks fine. You are synchronizing fine.

> 
> Btw: After that I downloaded development version 4.2.7... and this
> version also synchronizes pc fine.

So does 4.2.6p3 by your own evidence.

Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntpd

[Danny Mayer]

On 7/29/2011 9:47 AM, Valera wrote:
> Hello.
> 
> I have some issues with ntp-4.2.6p3 package which was downloaded from
> www.ntp.org
> I did all build stages such as: ./configure and make. After that I tried
> to execute obtained ntpd binary file with arguments "-p
> /var/run/ntpd.pid -g". Full execution string is: sudo
> ~/ntp-4.2.6p3/ntpd/ntpd -p /var/run/ntpd.pid -g
> The ntpd binary file related to my ubuntu 11.04 reliase works and
> syncronizes time with default ubuntu time servers fine. But ntpd from
> ntp-4.2.6p3 works without any visible issues but didn't syncronize local
> time with time servers.
> Both servers were executed with the same argument strings and the same
> configureation files. I think that this issue may be related to
> configuration(in config.h for example) but can't find the place.
> 
> Best wishes.

I installed a prebuilt ntp package on ubuntu last week using apt-get. It
gave me 4.2.6p2. Do you know what you got?

I did have to fix the ntp.conf file because they did not use any iburst
lines and I did change it to use the pool option rather than server
option to fetch a number of addresses to use. Are you using the ubuntu
configuration unchanged?

Did you run ntpq -p to see what if anything you are getting for servers?
Can you post it here?

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ipv6 multicast not working in ntp-4.2.6p3

[Danny Mayer]

On 6/20/2011 5:03 PM, Atul Gupta wrote:
> Hi Danny,
> I am able to receive the multicast packets from ntp server, but in log
> client displays something as "ignore" :-
> *ignore on (10) fd=17 from fe80::20e:2eff:fe91:9ebc
> ignore on (10) fd=17 from fe80::20e:2eff:fe91:9ebc*
> 
> where fe80::20e:2eff:fe91:9ebc is the server's address.*
> 
> *And, client doesn't start unicast communication with server, and hence
> doesn't sync. Is the "ignore" word is also harmless or it has some meaning.
> Please take a look at my ntp configuration as well.
> 
> *driftfile /var/lib/ntp/drift
> log /var/log/apps.log
> 
> restrict default kod nomodify notrap nopeer noquery
> restrict -6 default kod nomodify notrap nopeer noquery
> 
> 
> restrict 127.0.0.1
> restrict -6 ::1
> 
> multicastclient ff02::101# multicast client
> disable auth
> 
> keys /etc/ntp/keys*

Remove all restrict statements first and then test. If it works, read up
on how and why to use restrict statements before you start using them.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ipv6 multicast not working in ntp-4.2.6p3

[Danny Mayer]

On 6/20/2011 3:18 PM, Atul Gupta wrote:
> Hi Steve,
> I have upgraded my system with new version of ntpd i.e. ntp-4.2.6p3
> Now i am getting some different error, ntp is not able to receive the
> multicast packets sent by server and continuously throwing message :-
> *"select():
> nfound=-1, error: Interrupted system call"*
> I am ruuning on kernel version
> Linux (none) 2.6.28.10.mips-malta #1 PREEMPT Tue Jun 14 16:07:28 EDT 2011
> mips unknown
> 

That's not an error. You just have debug set too high. If you MUST run
debug, set it to -D2. In rare instances set it to -D4 if you want to see
a log of debug. You see this message whenever debug > 5.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] better explanation of jitter or phase noise

[Danny Mayer]

On 6/18/2011 7:50 PM, chipper wrote:
> Could somebody give a better defintion of jitter or phase noise, and how
> it affects clock accuracy?

Better than what?

These terms are defined in RFC 5905.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntp client ipv6 support

[Danny Mayer]

On 6/17/2011 9:45 PM, John Hasler wrote:
> Rick Jones wrote:
>> I may be parsing your sentence incorrectly...
> 
> You are.
> 
>> ...but my reading of the manpage is that one may set AI_NUMERICHOST,
>> in which case node must be an IP address, but that is not the same
>> thing as saying that if node is an IP address that AI_NUMERICHOST must
>> be set.
> 
> If you set the flag node must be an IP number.  If you don't set it
> getaddrinfo() will figure out for itself what node is (which, IMHO,
> makes getaddrinfo() too clever by half).  Note that there seems to be no
> flag to assert that node is a hostname.

The fact that this issue came up at all indicates that getaddrinfo() is
not doing this on at least some platforms. The rest of the discussion is
just that. We fixed the problem to avoid the issue.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntp client ipv6 support

[Danny Mayer]

On 6/17/2011 7:44 PM, Rick Jones wrote:
> John Hasler  wrote:
>> Rick Jones wrote:
>>> Netperf has been passing IPs to getaddrinfo() without setting any
>>> special flags.
> 
>> Chuck Swiger writes:
>>> Maybe there are broken implementations of getaddrinfo() floating
>>> around?
> 
>> On Linux you must set a flag to tell it not to consider the possibility
>> that what you are passing it is not a numeric address:
> 
>>node specifies either a numerical network address (for IPv4,
>>numbers-and-dots notation as supported by inet_aton(3); for IPv6,
>>hexadecimal string format as supported by inet_pton(3)), or a
>>network hostname, whose network addresses are looked up and
>>resolved.  If hints.ai_flags contains the AI_NUMERICHOST flag
>>then node must be a numerical network address.  The
>>AI_NUMERICHOST flag suppresses any potentially lengthy network
>>host address lookups.
> 
>>CONFORMING TO
>>POSIX.1-2001.  The getaddrinfo() function is documented in RFC 2553.
> 
> I may be parsing your sentence incorrectly, but my reading of the
> manpage is that one may set AI_NUMERICHOST, in which case node must be
> an IP address, but that is not the same thing as saying that if node
> is an IP address that AI_NUMERICHOST must be set.

I think you are misreading it. As I recall, if you don't provide it with
hints, it defaults and does a lookup on the string provided. You have to
set the AI_NUMERICHOST to prevent that.

Can you look at HP's source code for getaddrinfo() on various platforms
and see what it does? I did look at this in considerable detail at the
time that I was working on this one. I don't however remember a lot of
the details.

Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntp client ipv6 support

[Danny Mayer]

On 6/17/2011 4:42 PM, Rick Jones wrote:
> Danny Mayer  wrote:
>> You need to know that it's a numeric address before you call
>> getaddrinfo(). 
> 
> Really? Is that for IPv6 specifically, or IP generally? 
> 
> Netperf has been passing IPs to getaddrinfo() without setting any
> special flags.

I seem to recall that there was an issue with IP addresses and
getaddrinfo() on some platforms when you don't specify anything in
hints. I'd have to search bugzilla to find that.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntp client ipv6 support

[Danny Mayer]

On 6/17/2011 7:48 PM, E-Mail Sent to this address will be added to the
BlackLists wrote:
> BlackLists wrote:
>> Rick Jones wrote:
>>> Danny Mayer  wrote:
>>>> You need to know that it's a numeric address before you
>>>>  call getaddrinfo().
>>>
>>> Really? Is that for IPv6 specifically, or IP generally?
>>>
>>> Netperf has been passing IPs to getaddrinfo() without
>>>  setting any special flags.
>>
>> <http://www.rfc-editor.org/rfc/rfc3493.txt>
>>  {in the page 22 -25 range}
> 
> I'm guessing this is it?
> <http://ntp.bkbits.net:8080/ntp-dev/?PAGE=patch&REV=433e1854taAmL8-VD-LqZE0jPYNKyw>
> 

No, that's an emulation piece. It's elsewhere. ntpd/ntp_config.c from
the look of it.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntp client ipv6 support

[Danny Mayer]

On 6/17/2011 12:24 PM, Rick Jones wrote:
> Danny Mayer  wrote:
>> I misread the original question. The error you are seeing in the log
>> is the result of attempting to lookup the IP address as if it was a
>> name. I fixed that issue a long time ago so it you use an IP address
>> instead of a FQDN it won't try to get the address. So the short
>> answer is: upgrade.
> 
> getaddrinfo() is *supposed* to be able to be given an IP address as
> the "host" and deal with it accordingly.  For example, from the
> getaddrinfo manpage on my Linux system:
> 
>node specifies either a numerical network address (for IPv4,
>numbers-and-dots notation as supported by inet_aton(3); for IPv6,
>hexadecimal string format as supported by inet_pton(3)), or a
>network hostname, whose network addresses are looked up and
>resolved.  If hints.ai_flags contains the AI_NUMERICHOST flag then
>node must be a numerical network address.  The AI_NUMERICHOST flag
>suppresses any potentially lengthy network host address lookups.
> 
> So, while it may have been expedient to change the ntp code to not
> call getaddrinfo() with an IP address, the bug was probably not in
> ntp, but in getaddrinfo.  Ostensibly then, if an upgrade of ntp code
> is precluded, the upgrade the OP might make would be to the platform's
> getaddrinfo() call :)

You need to know that it's a numeric address before you call
getaddrinfo(). Previously we were not checking and it was actually doing
the lookup. That was the bug. For the purpose of the code in question it
was not necessary to make the call at all so we now skip the call
altogether.

Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntp client ipv6 support

[Danny Mayer]

On 6/16/2011 8:25 AM, Danny Mayer wrote:
> On 6/15/2011 10:16 PM, Atul Gupta wrote:
>> Hi Steve,
>> Thanks for your response.
>> Its difficult for me to move to ntp-4.2.6p3.
>> Does ntp-4.2.4 doesn't support ipv6 ? I have seen the release notes and it
>> says that it does  support.
>> Do i need to configure with some option to enable ipv6 multicast support?

I misread the original question. The error you are seeing in the log is
the result of attempting to lookup the IP address as if it was a name. I
fixed that issue a long time ago so it you use an IP address instead of
a FQDN it won't try to get the address. So the short answer is: upgrade.

Danny


___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] ntp client ipv6 support

[Danny Mayer]

On 6/15/2011 10:16 PM, Atul Gupta wrote:
> Hi Steve,
> Thanks for your response.
> Its difficult for me to move to ntp-4.2.6p3.
> Does ntp-4.2.4 doesn't support ipv6 ? I have seen the release notes and it
> says that it does  support.
> Do i need to configure with some option to enable ipv6 multicast support?
> 

NTP needs nothing to support IPv6, it's done so for many years. Your O/S
may. What O/S and version are you using?

What's your difficulty with upgrading NTP?

There was at one point a problem in NTP with multicast on some O/S's but
that was fixed a long time ago. We regularly use multicastclient
FF05::101 on the servers at UDel and elsewhere so it's not the current
version of NTP that's the problem. Move to the latest released version
to test that.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] SSL time request

[Danny Mayer]

On 5/21/2011 9:04 PM, Chris Albertson wrote:
> On Sat, May 21, 2011 at 3:18 PM, Danny Mayer  wrote:
>> On 5/19/2011 12:06 PM, Kevin Coulombe wrote:
>>> Hi,
>>>
>>> I'm looking into producing a 15 days demonstration version of an application
>>> for a client. I'm considering the use of an internet clock to validate this
>>> demo's duration, but a simple http request would be too easy to hack.
>>>
>>> Is there any way to request time in a secure manner such as an SSL
>>> connection. What I need is to validate that we are actually communicating
>>> with the "real" time server and that the message isn't tampered with.
>>>
>>
>> The proper way to do this with NTP is to use the autokey protocol which
>> will authenticate the servers. Note that the basic way that NTP works is
>> to use 3 or more NTP servers which allows it to select only consistent
>> truechimers and that are close enough to each other timewise that it can
>> choose one of them to synch to. It is actually quite hard to tamper with
>> an NTP packet and have it not be noticed, mainly because it does not
>> rely on a single NTP server. Add autokey for each of the servers and
>> just about nothing can be tampered with.
>>
>> Note that SSL is *not* secure when it comes to time since the SSL
>> certificate is in turn dependent on time. The autokey protocol deals
>> with that issue.
> 
> Let me add one more thing.  It should be obvious.  You need to do the
> NTP protocol from within your program.  Letting NTP sync the system
> time then using that is to easy to work around.
> 
That does not make a lot of sense. Putting an NTP server into your own
code would be an extremely difficult thing to do. If you cannot rely on
NTP setting and disciplining your system clock and using the system time
then you have much bigger problems that accurate time.

> But a simpler method is to use SSL to "tunnel" to your server and use
> something very simple like the "time" protocol.  NTP will give time to
> the milisecond level but the time protocol is faster and good enough
> for a second or so, more than you need.
> 

As I said before SSL depends on accurate time in the first place so you
cannot use it for verifying time. In addition what you would need to do
requires TCP and adds a lot of variable delay which you not be able to
measure. The only thing you can do with a time protocol is to set the
clock. It cannot discipline the clock and ignore bad time.

> None of this will work if the person trying to break it knows about
> software, he'd just binary patch your software with an unconditional
> jump.
> 

Having access to the source code is unlikely unless it is publicly
available which is rather unlikely and if the attacker can get in to
patch the software then you have bigger problems than the software or
time. This all sounds like a solution looking for a problem.

Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] SSL time request

[Danny Mayer]

On 5/19/2011 12:06 PM, Kevin Coulombe wrote:
> Hi,
> 
> I'm looking into producing a 15 days demonstration version of an application
> for a client. I'm considering the use of an internet clock to validate this
> demo's duration, but a simple http request would be too easy to hack.
> 
> Is there any way to request time in a secure manner such as an SSL
> connection. What I need is to validate that we are actually communicating
> with the "real" time server and that the message isn't tampered with.
> 

The proper way to do this with NTP is to use the autokey protocol which
will authenticate the servers. Note that the basic way that NTP works is
to use 3 or more NTP servers which allows it to select only consistent
truechimers and that are close enough to each other timewise that it can
choose one of them to synch to. It is actually quite hard to tamper with
an NTP packet and have it not be noticed, mainly because it does not
rely on a single NTP server. Add autokey for each of the servers and
just about nothing can be tampered with.

Note that SSL is *not* secure when it comes to time since the SSL
certificate is in turn dependent on time. The autokey protocol deals
with that issue.

Danny

___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Linux : ntp-dev-4.2.7p84 : Local clock not getting synced.

[Danny Mayer]

On 1/3/2011 11:46 AM, Martin Burnicki wrote:
>>
>> It's not quite clear what Arul was trying to achieve, but it looks like
>> he was trying to define a local refclock using both IPv4 and IPv6
>> terminology. It's easy to see how he may have come up with the ::1
>> address, since NTP is using what look like loopback addresses. All IPv4
>> 127.0.0.0/8 addresses map to IPv6 ::1.
>>
>> I don't know if ::127.127.1.0 (or ::7f7f:100) would work (I suppose it
>> should, if NTP has full IPv6 support).
> 
> Those "special" 127.127.x.y addresses are somewhat sorted out when parsing
> the configuration options and treated in a special way. I'm not sure it
> would work, and I'm not even sure if it would be expected to work. Dave
> Mills, Dave Hart, and Danny, what's your opinion on using IPv6-style
> addresses to specify refclocks?

I know that this is a really late response, but my intention is to
replace the server line for refclocks with a refclock line with a number
or a name (like NMEA) as the first argument. Then we can get rid of
these IPv4-like addresses. They are not really addresses but it does
seem to confuse a lot of people.

Having a refclock line could also then be used to specify additional
things like fudge. etc. on the same line and make it clear what it's
referring to.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions

Re: [ntp:questions] Detecting bufferbloat via ntp?

[Danny Mayer]

On 2/16/2011 7:01 AM, David Malone wrote:
> Terje Mathisen <"terje.mathisen at tmsw.no"> writes:
> 
>> The end points needs at least bandwidth*latency buffers simply to keep 
>> the flow going, while routers in between should have very little buffer 
>> space, simply because that will allow the end points to discover the 
>> real channel capacity much sooner.
> 
> For traditional TCP (single flow), you need bandwidth*latency as
> sockbuf at both ends plus the same at the bottleneck router. Some
> of the new TCP congestion control systems can do with less, and
> still fill the link if they are the only flow.

Since NTP only uses UDP the packet handling will be different. I'm not
sure why you are talking about TCP here.
> 
>> You might claim that a little intermediate buffer space is a good thing, 
>> in that it can allow a short-term burst of packets to get through 
>> without having to discard other useful stuff, but only as long as most 
>> links have spare capacity most of the time.
> 
> There was some work a few years ago that suggested that you needed
> about bandwidth*latency/sqrt(n) buffering at a link with n bottlenecked
> TCP flows, in order to make sure that the flows could actually use
> the link. There was also a suggestion that you could get away with
> less, but that neemed to require a quite large n in practice.

It would be more useful to discuss what happens with UDP flows since
that is what NTP uses.

Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions