Re: [ntp:questions] Running two ntpd systems in parallel

2009-11-01 Thread Dave Hart
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


Re: [ntp:questions] Running two ntpd systems in parallel

2009-10-30 Thread Paul Fleischer
2009/10/17 Dave Hart daveh...@gmail.com:
 On Mon, Sep 14, 2009 at 11:23 AM, Paul Fleischer p...@xpg.dk 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

2009-10-17 Thread Dave Hart
On Mon, Sep 14, 2009 at 11:23 AM, Paul Fleischer p...@xpg.dk 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

[ntp:questions] Running two ntpd systems in parallel

2009-10-09 Thread Paul Fleischer
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 config.h
-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 config.h
-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
 *