David L. Mills
mills at udel.edu
Mon Feb 28 20:17:55 PST 2005
Danny Mayer wrote:
> At 02:17 PM 2/28/2005, David L. Mills wrote:
>> I updated all machines on campus and backroom with latest ntp-dev and
>> rebuilt all. The good news is that all combinations of modes work in
>> plain and authenticated symmetric key. A minor bug was found and
>> fixed with broadcast client where the association took several
>> minutes to set up rather than less than a minute as designed. Note
>> the initial delay before doing anything is randomized over 16 s in
>> order to reduce the implosion hazard when the server has been down
>> for a long time (hours). After that the delay to synchronize is the
>> same as with iburst.
>> The problems I know about remaining:
>> 1. ntpdate doesn't work on snavely. Something about a broken socket.
> That's a new one on me. I never use it. what's your commandline string
> and I'll try and check it out.
Stop ntpd and mumble "ntpdate pogo".
>> 2. IPv6 client/server does not work from hepzibah to pogo.
> What do you see as symptoms?
Howland sends client IPv6 to pogo-ipv6 on the wire and server pogo-ipv6
does not respond. It does respond with IPv4.
>> 3. multicast and manycast doesn't work, authenticated or not.
> We'll have to work on that. All that I am certain of is that TEST10
> and TEST11 are failing.
No; the tests normally do show that condition until the certificate and
identity key are retrieved. Please read my earlier message again. I took
some care to lay out the symptoms in detail. Note the broadcast does
work, so the differences should be easy to fix.
>> 4. Autokey doesn't multicast or manycast. It apparently doesn't work
>> in broadcast, but the problem appears to be a protocol bug, as the
>> client certifidate is not signed by the server. I'm on that.
> Okay, is that why authentication is failing?
>> 5. Something wicked is going on with refclocks on rackety. Similar
>> configuration works fine on rackety clone mort and on Solaris.
> You must have a hardware problem on rackety. In the meantime I have fixed
> the input_handler() code and it seems to be working, just not on rackety.
> I have asked Harlan to pull it tonight if he can. You can get it from
I'm not getting through. Have you tried my experiment with debug trace
and two -d's? No change; it loops forever, returning a zero-length line
each time. Do a cat /dev/cuaa1 and presto, there's the clock. I'm not
dismissing the cause as a hardware blip, but it sure seems wierd that
cat works and ntpd doesn't. Same kernel driver. By the way, this problem
has happened on barnstable in the past before your changes, so it might
be something more basic. I don't want to say simply it must be the
hardware, because the problem is surely to happen again.
As I said in a previous message, there are some conditions where the
kernel driver can return a zero length chunk, like when the raw timer
goes off when no data have been received. I suggested some messages back
that condition be ignored and the ntpd code simply go back looking for
> There are a number of debug printfs in ntp_io.c that are not enclosed
> in #ifdefs. I assume these are temporary.
> I don't see any un#ifdef'd printf's in ntp_io.c. My copy may be
> from yours. If when you pull the new copy you still see some please
> let me know.
More information about the hackers