Re: [ntp:questions] ntp pool servers disappear - more data
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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: http://archive.ntp.org/ntp4/ntp-4.2/. 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
On 7/6/2014 2:42 AM, Rob wrote: Harlan Stenn st...@ntp.org 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] Thoughts on KOD
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
On 7/6/2014 7:22 AM, Jan Ceuleers wrote: On 07/06/2014 11:23 AM, Rob wrote: Jan Ceuleers jan.ceule...@computer.org 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
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] Why DNS servers should not be NTP servers
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
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
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
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 terje.mathi...@tmsw.nowrote: 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 -- - Terje.Mathisen at tmsw.no 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
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.
On 3/16/2014 4:11 PM, Paul wrote: On Sun, Mar 16, 2014 at 2:22 PM, William Unruh un...@invalid.ca 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
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
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
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] Pool returns IPv6 address to IPv4 query
On 11/19/2013 12:33 PM, Rick Jones wrote: Danny Mayer ma...@ntp.org 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
On 11/19/2013 1:01 PM, Brian Utterback wrote: On 11/19/2013 12:33 PM, Rick Jones wrote: Danny Mayer ma...@ntp.org 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] Is there something with greater detail on interface besides the manpage?
On 11/19/2013 11:36 AM, Rick Jones wrote: Harlan Stenn st...@ntp.org 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] Is there something with greater detail on interface besides the manpage?
On 11/19/2013 1:50 PM, Danny Mayer wrote: On 11/19/2013 11:36 AM, Rick Jones wrote: Harlan Stenn st...@ntp.org 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] Pool returns IPv6 address to IPv4 query
On 11/19/2013 2:47 PM, Rick Jones wrote: Brian Utterback brian.utterb...@oracle.com 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] Pool returns IPv6 address to IPv4 query
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] Fw: Authenticated ntp server
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] Failure modes on Windows Server 2008 R2 64-bit
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
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
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
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)?
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
On 2/26/2012 12:17 AM, Dave Hart wrote: On Sun, Feb 26, 2012 at 03:37, Danny Mayer ma...@ntp.org 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
On 2/26/2012 10:27 AM, unruh wrote: On 2012-02-26, Danny Mayer ma...@ntp.org wrote: On 2/26/2012 12:17 AM, Dave Hart wrote: On Sun, Feb 26, 2012 at 03:37, Danny Mayer ma...@ntp.org 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
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
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
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
On 12/27/2011 11:45 PM, Greg Hennessy wrote: On 2011-12-28, Danny Mayer ma...@ntp.org 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
On 12/28/2011 12:09 AM, j...@specsol.spam.sux.com wrote: Danny Mayer ma...@ntp.org wrote: On 12/27/2011 8:48 PM, j...@specsol.spam.sux.com wrote: Danny Mayer ma...@ntp.org wrote: On 12/24/2011 8:10 PM, j...@specsol.spam.sux.com wrote: John Hasler jhas...@newsguy.com 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
On 12/28/2011 12:17 AM, unruh wrote: On 2011-12-28, Danny Mayer ma...@ntp.org wrote: On 12/24/2011 8:10 PM, j...@specsol.spam.sux.com wrote: John Hasler jhas...@newsguy.com 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] ntp server pool advice
On 12/27/2011 1:16 PM, unruh wrote: On 2011-12-27, Danny Mayer ma...@ntp.org 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] Accuracy of NTP - Advice Needed
On 12/24/2011 1:11 PM, unruh wrote: On 2011-12-24, John Hasler jhas...@newsguy.com 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] Accuracy of NTP - Advice Needed
On 12/24/2011 8:10 PM, j...@specsol.spam.sux.com wrote: John Hasler jhas...@newsguy.com 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] Windows and Wi-Fi - starts well, frequency steps?
On 12/24/2011 8:11 PM, Dave Hart wrote: On Sat, Dec 24, 2011 at 18:18, unruh un...@invalid.ca wrote: On 2011-12-24, David J Taylor david-tay...@blueyonder.co.uk.invalid 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
On 12/27/2011 8:48 PM, j...@specsol.spam.sux.com wrote: Danny Mayer ma...@ntp.org wrote: On 12/24/2011 8:10 PM, j...@specsol.spam.sux.com wrote: John Hasler jhas...@newsguy.com 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] Accuracy of NTP - Advice Needed
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
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] ntp-keygen not working
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 server pool advice
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 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
Re: [ntp:questions] ntpdate removal is coming
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
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 ma...@ntp.org mailto:ma...@ntp.org wrote: On 11/30/2011 3:50 AM, rakesh v wrote: Hi, Iam facing issues with ntp broadcast ip address 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
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 ma...@ntp.org 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 ma...@ntp.org 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
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
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
On 11/30/2011 3:50 AM, rakesh v wrote: Hi, Iam facing issues with ntp broadcast ip address 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
On 11/30/2011 4:35 AM, Rob wrote: Danny Mayer ma...@ntp.org 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
On 11/30/2011 12:26 PM, Rob wrote: unruh un...@invalid.ca wrote: On 2011-11-30, Rob nom...@example.com wrote: Danny Mayer ma...@ntp.org 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
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
On 11/7/2011 4:58 PM, unruh wrote: On 2011-11-07, Nathan Kitchen nkitc...@aristanetworks.com wrote: On Sun, Nov 6, 2011 at 2:13 PM, Danny Mayer ma...@ntp.org 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
On 11/7/2011 5:41 PM, Dave Hart wrote: On Mon, Nov 7, 2011 at 21:58, unruh un...@invalid.ca 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
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
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] 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 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] EXTERNAL: Re: Issue with peering and orphan mode
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 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
Re: [ntp:questions] RFC section 7.4 b. wording seems off for the desired action.
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
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
Re: [ntp:questions] Magice Server Numbers: 4,5,7,9
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
[ntp:questions] Fwd: [dnsext] sands of time
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
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
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] ntpd
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] ipv6 multicast not working in ntp-4.2.6p3
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] ipv6 multicast not working in ntp-4.2.6p3
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] ntp client ipv6 support
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
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
On 6/17/2011 12:24 PM, Rick Jones wrote: Danny Mayer ma...@ntp.org 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
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 ma...@ntp.org 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=patchREV=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
On 6/17/2011 4:42 PM, Rick Jones wrote: Danny Mayer ma...@ntp.org 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
On 6/17/2011 7:44 PM, Rick Jones wrote: John Hasler jhas...@newsguy.com 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
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
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] SSL time request
On 5/21/2011 9:04 PM, Chris Albertson wrote: On Sat, May 21, 2011 at 3:18 PM, Danny Mayer ma...@ntp.org 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] Linux : ntp-dev-4.2.7p84 : Local clock not getting synced.
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?
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
Re: [ntp:questions] help needed for ntpd multicast mode
On 11/30/2010 2:20 PM, Dave Hart wrote: On Tue, Nov 30, 2010 at 18:50 UTC, Atul Gupta atul14.ku...@gmail.com wrote: I used broadcastdelay in my client's config, but client is still trying to send unicast messages to server after receiving multicast messages from server. You mentioned using ntp 4.2.0. You can find your version's broadcastdelay documented at: http://doc.ntp.org/4.2.0/miscopt.html It reads to me like the behavior has changed in newer versions. For ntpd 4.2.0 (circa 2003), it appears the unicast delay calibration is always attempted, and the broadcastdelay value is only used if the attempt fails. If you upgrade to a recent version, using specifying broadcastdelay short-circuits the attempt. I know this is rather late but unless the code has changed recently broadcastdelay didn't used to be usable for multicast and novolley does not have any affect on multicast. It was meant for broadcast only. In fact novolley does not exist for a multicastclient configuration. Danny ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] ntp multicast mode
On 12/2/2010 8:16 AM, Richard B. Gilbert wrote: On 12/1/2010 10:49 PM, Atul Gupta wrote: Hi all, My ntp client is taking some time before syncing up with the server in multicast mode, generally its waiting for 4 packets from server before syncing its time, is it normal , and if so , what is the reason for this. NTPD is measuring the rate at which your clock ticks. It does not *just* set the clock, it also attempts to make the clock tick at a rate of exactly one tick per second! You can speed things up a *little* by using the iburst keyword in NTP.CONF. NTPD can take as long as ten hours to achieve the accuracy of which it is capable. I'd be interested in how you imagine it could do that since it is a multicast client and only receives packets rather than sending them! In read-only mode you have to wait until you have received enough packets to fill enough of the pipeline so that an analysis of the data can be done and an estimate of the clock calculated. A multicast server sends at the rate of 1 NTP packet per minute so it takes 4 minutes to get to that point. Danny ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] I-D Action:draft-lear-iana-timezone-database-01.txt (fwd)
On 12/18/2010 4:22 PM, Mr. James W. Laferriere wrote: Hello ntp-team , Am hopeful that all of you are aware of this item of news . Hth , JimL Discussion of IETF documents really belong in the working group but in this case timezone stuff is not something that NTP cares about since it only deals with UTC. It is of course of interest to admins. It is not clear what working group would discuss this and this is a personal submission so it is hard to tell. Danny ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Will AutoKey setup work on a NAT host behind a firewall?
On 11/13/2010 9:47 PM, Dave Hart wrote:
On Sun, Nov 14, 2010 at 00:32 UTC, Harlan Stenn st...@ntp.org wrote:
Somebody wrote:
pool in.pool.ntp.org iburst  # will likely get 2 national servers
# pool 0.in.pool.ntp.org iburst
# pool 1.in.pool.ntp.org iburst
# pool 2.in.pool.ntp.org iburst
# pool 3.in.pool.ntp.org iburst
One should not need to use the {0,1,2,3}. names when using the 'pool'
directive.
A single pool FOO.pool.ntp.org iburst line should be enough.
... assuming you're using 4.2.7. With 4.2.6 or earlier, pool spins
up only one association, and uses DNS only at startup.
That didn't used to be true, at least in the original code that was in
4.2.5 which would create up to 10 associations depending on the number
of IP addresses returned by the DNS resolver and how many previous
associations had been set up. Did something change in 4.2.6 to break that?
Danny
___
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Will AutoKey setup work on a NAT host behind a firewall?
On 11/10/2010 6:11 AM, Harry wrote: On Nov 10, 2:59 am, David L. Mills mi...@udel.edu wrote: Harry, Autokey is not designed to work behind NAT boxes. The Autokey server and client must have the same (reversed) IP addresses. The intended model is using two interfaces, one for the Internet side running Autokey, the other for the inside net on the other side of the NAT box. Dave Harry wrote: Hello, I want to employ the AutoKey method of securing NTP. Basically, I want one host that would act as an NTP client of an external NTP server, talking AutoKey. This NTP client is to become the NTP server for other hosts on the intranet. All these hosts are behind a corporate firewall and are very likely using NAT / IP masquerading as well. (I can tell NAT / IP masquerading is in use in our environment because all hosts report the same IP address at http://www.whatismyipaddress.com.) I ask this question because I ran into a circa 2004 link (http:// www.ecsirt.net/tools/crypto-ntp.html) that says, Be Aware! Before we start building ntpd, one important notice: NTP with Autokey does not work from a host that is behind a masquerading or NAT host! Is this a conceptual / fundamental limitation, or something related to NTP version? If latter, I'm hoping that it would probably have been fixed by now. If AutoKey and NAT don't go together conceptually, what would be my next best option of securing NTP? Though MD5 method is there but it is symmetric cryptography and prone to man-in-the-middle attacks... which is why btw I was hoping to be able to employ AutoKey. Many thanks, /HS ___ questions mailing list questi...@lists.ntp.org http://lists.ntp.org/listinfo/questions Dave, I really appreciate your response to my newbie question. May I ask (you or other users of this forum)... 1. What, then, would be the next best way (MD5-based symmetric key mode?) to syncing up a behind-NAT NTP client from an external NTP server in a tamper-proof manner? I'm not competent/powerful enough to advise the powers what be in my organization to have an Autokey NTP client outside our NAT/Firewall; most likely, I'll be told to continue to operate from behind the NAT/Firewall. 2. What physical/network setup should Autokey-desiring NTP clients follow? Is it OK, e.g., to have a Autokey client host (AkH) outside one's NAT network and have all the hosts inside the NAT network use AkH as a NTP server? I also skimmed thru your (excellent) book on NTP. I was hoping to find a mention of NAT in Chapter 9, but didnt. Not complaining, just humbly/ respectfully bringing it up. So, please do elaborate here if you can on this issue. Many thanks in advance, /HS The problem that you are running into is that NAT boxes rewrite addresses in the packet. Autokey depends on the addresses of both sender and receiver for the autokey authentication mechanism but because the addresses get changed the protocol will fail validation. NAT's are evil and not just for this reason. Danny ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
