[ntp:questions] Re: Oncore driver in 4.2.0

Chris Stenton jacs at gnome.co.uk
Wed Nov 12 16:53:29 UTC 2003


"Wolfgang S. Rupprecht"
<wolfgang+gnus20031112T065956 at dailyplanet.dontspam.wsrcc.com> wrote in
message news:x74qx962c5.fsf at capsicum.wsrcc.com...
>
> "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?
>

Nasty!

> > 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".

I've also been using it in mode 1. I did the site survey using winoncore
and it took many hours to get the 10 000 valid position fixes needed.
So I presume in mode 4 it will not do anything until it gets the 10 000
fixes.

>
> 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