[ntp:questions] Running two ntpd systems in parallel
Hello, I have a project where I need to run two NTP systems in parallel on a Linux system. The reason for this is that I need two time domains: One using the real time obtained from an external NTP server, and one to control a local time. The first NTP system, obtaining the time from an external NTP server will be an unmodified version of the NTP source code, while the second is changed in two aspects: First, the network communication will be moved to another port that 123. Let's assume it's 1234 for now. Second, rather than using clock_gettime() and adjtime() it will use calls that modify a second clock which is implemented in the Linux kernel. I have tried doing the first by creating a new entry in my /etc/services called "ntp2" which maps to 1234/tcp and 1234/udp. The source of NTP has also been changed to use 1234 rather than 123 where it is hard-coded. Right now I am running this modified NTP system alone, i.e. no ordinary NTP server is running on either of my test machines. There are two machines: PC1 (ip: 10.0.0.1) and PC2 (10.0.0.2), with the following configuration files for ntpd: PC1: ntp.conf === driftfile /tmp/ntp.drift peer 10.0.0.2 PC2: ntp.conf === driftfile /tmp/ntp.drift peer 10.0.0.1 server 127.127.1.1 fudge 127.127.1.1 stratum 5 If I run the modified ntpd with the above configurations, it seems that the communicate with each other. However, ntpq behaves strange. Running "ntpq -c peers" on PC2 gives: remote refid st t when poll reach delay offset jitter == Running "ntpq -c lassociations" on PC2 gives: ind assID status conf reach auth condition last_event cnt === 1 10139 8000 yes yes nonereject 2 10140 9614 yes yes none sys.peer reachable 1 The output on PC1 is the same: The peer does not show up in "peers" but does so in "lassociations". If I use an unmodified version of NTP the output is more logical (run on PC2): > ntpq -c peers remote refid st t when poll reach delay offset jitter == PC1 .INIT. 16 u 43 6400.000 0.000 0.000 *LOCAL(1).LOCL. 5 l4 6430.0000.000 0.001 > ntpq -c lassociations ind assID status conf reach auth condition last_event cnt === 1 47207 8000 yes yes nonereject 2 47208 9614 yes yes none sys.peer reachable 1 So it seems that changing the network port used somehow destroys functionality. I am using ntp-dev-4.2.5p82, and apply the patch attached listed below to change the network port. Can anyone help me solve this problem? Cheers, Paul diff -urN unmod/ntp-dev-4.2.5p82/include/ntp.h ntp-dev-4.2.5p82/include/ntp.h --- unmod/ntp-dev-4.2.5p82/include/ntp.h2007-10-04 13:03:26.0 +0200 +++ ntp-dev-4.2.5p82/include/ntp.h 2009-09-11 14:03:39.0 +0200 @@ -98,7 +98,7 @@ */ #defineNTP_VERSION ((u_char)4) /* current version number */ #defineNTP_OLDVERSION ((u_char)1) /* oldest credible version */ -#defineNTP_PORT123 /* included for non-unix machines */ +#defineNTP_PORT1234/* included for non-unix machines */ /* * Poll interval parameters diff -urN unmod/ntp-dev-4.2.5p82/ntpd/version.c ntp-dev-4.2.5p82/ntpd/version.c --- unmod/ntp-dev-4.2.5p82/ntpd/version.c 2009-09-14 13:05:38.0 +0200 +++ ntp-dev-4.2.5p82/ntpd/version.c 2009-09-14 09:45:23.0 +0200 @@ -2,4 +2,4 @@ * version file for ntpd */ #include -const char * Version = "ntpd 4.2.5...@1.1618-o Mon Sep 14 11:05:38 UTC 2009 (1)"; +const char * Version = "ntpd 4.2.5...@1.1618-o Mon Sep 14 07:45:23 UTC 2009 (5)"; diff -urN unmod/ntp-dev-4.2.5p82/ntpdate/version.c ntp-dev-4.2.5p82/ntpdate/version.c --- unmod/ntp-dev-4.2.5p82/ntpdate/version.c2009-09-14 13:05:39.0 +0200 +++ ntp-dev-4.2.5p82/ntpdate/version.c 2009-09-14 09:45:28.0 +0200 @@ -2,4 +2,4 @@ * version file for ntpdate */ #include -const char * Version = "ntpdate 4.2.5...@1.1618-o Mon Sep 14 11:05:39 UTC 2009 (1)"; +const char * Version = "ntpdate 4.2.5...@1.1618-o Mon Sep 14 07:45:28 UTC 2009 (5)"; diff -urN unmod/ntp-dev-4.2.5p82/ntpdc/ntpdc.c ntp-dev-4.2.5p82/ntpdc/ntpdc.c --- unmod/ntp-dev-4.2.5p82/ntpdc/ntpdc.c2007-10-14 13:04:17.0 +0200 +++ ntp-dev-4.2.5p82/ntpdc/ntpdc.c 2009-09-14 10:29:09.0 +0200 @@ -489,7 +489,7 @@ struct addrinfo hints, *ai = NULL; register const char *cp; char name[LENHOSTNAME]; - char service[5]; + char service[9]; /* * We need to get by the [] if they were entered @@ -516,7 +516,7 @@ * will return an "IPv4-mapped IPv6 address" address if you
Re: [ntp:questions] Running two ntpd systems in parallel
On Mon, Sep 14, 2009 at 11:23 AM, Paul Fleischer wrote: > First, the network communication will be moved to another port that > 123. Let's assume it's 1234 for now. I would like to see ntpd support unprivileged operation for testing purposes, including using a local port > 1024. The approach I have been considering is adding a "port" option to the association commands like server and peer in ntp.conf, with the secondary or unprivileged ntpd still defaulting to remote port 123. > Second, rather than using clock_gettime() and adjtime() it will use > calls that modify a second clock which is implemented in the Linux > kernel. For my purposes, a test unprivileged ntpd would modify a fictional system clock composed within ntpd using the real system clock modified by frequency and offset changes which normally would be applied to the system clock. This is a trickier bit of code to get right than the UDP port change. I'm curious how your second clock would be used, and what mechanism might be used to let you cleanly intercept the clock-affecting calls without requiring local patches to the NTP code. > If I run the modified ntpd with the above configurations, it seems > that the communicate with each other. However, ntpq behaves strange. > > Running "ntpq -c peers" on PC2 gives: > remote refid st t when poll reach delay offset jitter > == > > Running "ntpq -c lassociations" on PC2 gives: > ind assID status conf reach auth condition last_event cnt > === > 1 10139 8000 yes yes none reject > 2 10140 9614 yes yes none sys.peer reachable 1 Your patch missed a questionable bit of code I coincidentally am likely to remove from ntpq-subs.c do_printpeers() line 1571: /* * Check to see if the srcport is NTP's port. If not this probably * isn't a valid peer association. */ if (havevar[HAVE_SRCPORT] && srcport != NTP_PORT) return (1); Remove that code and your ntpq should be much happier. It appears to have been added as a sanity check, but it's not a very good one. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Running two ntpd systems in parallel
2009/10/17 Dave Hart : > On Mon, Sep 14, 2009 at 11:23 AM, Paul Fleischer wrote: > I would like to see ntpd support unprivileged operation for testing > purposes, including using a local port > 1024. The approach I have > been considering is adding a "port" option to the association commands > like server and peer in ntp.conf, with the secondary or unprivileged > ntpd still defaulting to remote port 123. That would be a very usefull change, IMHO. >> Second, rather than using clock_gettime() and adjtime() it will use >> calls that modify a second clock which is implemented in the Linux >> kernel. > > For my purposes, a test unprivileged ntpd would modify a fictional > system clock composed within ntpd using the real system clock modified > by frequency and offset changes which normally would be applied to the > system clock. This is a trickier bit of code to get right than the > UDP port change. Ugh, that does indeed sound a bit hairy. But if it is only for test purposes a naive approach might be enough? > I'm curious how your second clock would be used, and what mechanism > might be used to let you cleanly intercept the clock-affecting calls > without requiring local patches to the NTP code. I will apply local patches to use a custom system call. As far as I can see I just need to replace clock_gettime() and adjtime() with my custom versions. The idea is to have have the clock tick in the kernel controlling two clocks, each with their own value and frequency. Exactly how this is implemented, I do not yet know. A college of mine seems to know what he will be doing, and I'll just give that a spin :-) > Your patch missed a questionable bit of code I coincidentally am > likely to remove from ntpq-subs.c do_printpeers() line 1571: > > /* > * Check to see if the srcport is NTP's port. If not this probably > * isn't a valid peer association. > */ > if (havevar[HAVE_SRCPORT] && srcport != NTP_PORT) > return (1); > > Remove that code and your ntpq should be much happier. It appears to > have been added as a sanity check, but it's not a very good one. Ahh, yeah, I missed that one. Removed it, and now it seems to work. Thank you very much for the help. Cheers, Paul ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Running two ntpd systems in parallel
Please see my message to hackers@ today pointing to a prototype ntpd that disciplines a synthetic clock and does not require root privileges: http://lists.ntp.org/pipermail/hackers/2009-November/004633.html Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
