[ntp:questions] Re: Oncore driver in 4.2.0

Wolfgang S. Rupprecht wolfgang+gnus20031112T065956 at dailyplanet.dontspam.wsrcc.com
Wed Nov 12 15:20:10 UTC 2003


"Chris Stenton" <jacs at gnome.co.uk> writes:
> Having recently installed an Oncore GPS unit under FreeBSD 5.1 I have a few
> notes on some "features" in 4.2.0.
>
> Putting
>
> pps /dev/oncore.pps.0 clear hardpps
>
> in ntp.conf no longer works.  I assume the pps command has been depreciated.

This isn't needed any more.

> If a fudge line is present it is acted upon AFTER  ntp.oncore. If values for
> flag2 and flag3 are not present the defaults are used even though the values
> may have been set in ntp.oncore ... giving unexpected results!

It is worse than that.  Even with no fudge line you can reset to
defaults by *reading* the variables from across the net.  Can you say
security bug?

> In the driver,  oncore_start and a few other  procedures do not  produce any
> output to the clocks stat file. For what ever reason
> record_clock_stats(&(instance->peer->srcadr), cp) does not do anything.
>
> Other than that it works a charm!

Is your oncore showing a 'reach/offset/jitter'?  I couldn't get my m12
oncore to do anything until I added the LAT/LON/HT and requested "Mode
1".

To avoid the fatal fudge/ntp.oncore interaction do not put the CLEAR
(or HARDPPS) command in the ntp.oncore file; use the fudge version of
the command in the conf file instead.

ntp.conf:
    server 127.127.30.0 prefer	# Oncore GPS driver
    fudge 127.127.30.0 flag2 1 

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*GPS_ONCORE(0)   .GPS.            0 l    5   16  377    0.000   -0.004   0.001

-wolfgang
-- 
Wolfgang S. Rupprecht 		     http://www.wsrcc.com/wolfgang/
           The From: address is valid.  Don't mess with it.

The following patch prevents little urchins from re-writing the kernel
setting every time they read your variables.  Right now the oncore
refclock re-writes the settings even when it reads the values.
Unfortunately when CLEAR or HARDPPS is set in the /etc/ntp.oncore file
it never gets copied into the sloppyclock bits.  When the next write
takes place the default sloppyclock bits mash whatever hardpps/clear
settings were in effect.
 
These patches are still a bit incomplete.  I need to make fix things
so that the CLEAR HARDPPS in ntp.oncore set the appropriate bit in the
pp->sloppyclockflag.  I also should fix it so that the 2 kernel calls
aren't done unless in->haveflags says that flags need setting.  Right
now they are set unconditionally.

--- refclock_oncore.c.orig	2003-07-17 03:27:29.000000000 -0700
+++ refclock_oncore.c	2003-11-07 16:16:54.000000000 -0800
@@ -705,24 +705,51 @@
 	struct refclockproc *pp;
 	struct instance *instance;
 
-	pp = peer->procptr;
-	instance = (struct instance *) pp->unitptr;
-
-	instance->assert  = !(pp->sloppyclockflag & CLK_FLAG2);
-	instance->hardpps =   pp->sloppyclockflag & CLK_FLAG3;
+	if (in){
+		pp = peer->procptr;
+		instance = (struct instance *) pp->unitptr;
 
-	if (instance->assert)
-		cp = "Resetting timing to Assert.";
-	else
-		cp = "Resetting timing to Clear.";
-	record_clock_stats(&(instance->peer->srcadr), cp);
+		instance->assert  = !(pp->sloppyclockflag & CLK_FLAG2);
+		instance->hardpps =   pp->sloppyclockflag & CLK_FLAG3;
 
-	if (instance->hardpps) {
-		cp = "HARDPPS Set.";
+		/*
+		 * We should be looking at (in->haveflags &
+		 CLK_HAVEFLAG2) to see * if we have a request to frob
+		 the kernel assert/clear. -wsr
+		 */
+		if (instance->assert)
+			cp = "Resetting timing to Assert.";
+		else
+			cp = "Resetting timing to Clear.";
 		record_clock_stats(&(instance->peer->srcadr), cp);
-	}
 
-	(void) oncore_ppsapi(instance);
+		/*
+		 * We should be looking at (in->haveflags &
+		 CLK_HAVEFLAG3) to see * if we have a request to frob
+		 the kernel HARDPS. -wsr
+		 */
+
+		if (instance->hardpps) {
+			cp = "HARDPPS Set.";
+			record_clock_stats(&(instance->peer->srcadr), cp);
+		}
+
+		/*
+		 * This routine needs to be passed the CLK_HAVEFLAG{2,3}
+		 * values so it can set the hardpps and the
+		 * assert/clear separately (or not at all if these two
+		 * variables didn't get set').  XXX_control() can be
+		 * called for setting any number of variables that we
+		 * have no interest over. -wsr 2003/11/4
+		 */
+		(void) oncore_ppsapi(instance
+				     /*
+				       ,
+				       in->haveflags & CLK_HAVEFLAG2,
+				       in->haveflags & CLK_HAVEFLAG3
+				     */
+				     );
+	}
 }
 
 



More information about the questions mailing list