Andreas Kahari [EMAIL PROTECTED] wrote:
> Is there a firewall blocking the requests in either direction? Does
> networki routing etc. work apart from this?
Yes, networking works as it should. The problem was that ntpd did not
get synced because I had hacked it to settimeofday() every time the sensor
reports a new offset. This put the internal magical calculators out of
sync and ntpd put the alert flag up in responses which were then rejected
by other ntpd's and ntpdate.
So I approached the problem from another angle and thought about
adjtime()'ing the offsets. It produced this very simple patch:
Index: ntp.c
===================================================================
RCS file: /storage/1/mirror/openbsd/src/usr.sbin/ntpd/ntp.c,v
retrieving revision 1.91
diff -u -r1.91 ntp.c
--- ntp.c 1 Jul 2006 18:52:46 -0000 1.91
+++ ntp.c 15 Jul 2006 07:50:05 -0000
@@ -1,4 +1,4 @@
-/* $OpenBSD: ntp.c,v 1.91 2006-07-01 18:52:46 otto Exp $ */
+/* $OpenBSD: ntp.c,v 1.91 2006/07/01 18:52:46 otto Exp $ */
/*
* Copyright (c) 2003, 2004 Henning Brauer <[EMAIL PROTECTED]>
@@ -315,8 +315,10 @@
for (s = TAILQ_FIRST(&conf->ntp_sensors); s != NULL;
s = next_s) {
next_s = TAILQ_NEXT(s, entry);
- if (s->next <= time(NULL))
+ if (s->next <= time(NULL)) {
sensor_query(s);
+ priv_adjtime();
+ }
}
}
Now priv_adjtime() takes into account the offset set by a nmea
sensor and adjusts the time correctly, and voila, ntpd's internal magic
calculators also agreed and started working as they should. So now
I have a working (sync'ed) ntpd that uses a usb gps receiver as its
time source.
Without that priv_adjtime() the offset reported by the sensor never
got updated, I don't know why yet.
best regards,
Bo Granlund
