David L. Mills
mills at udel.edu
Sun Oct 10 19:38:16 PDT 2004
Yes, I know the problem is with the client, but yes, the contraption did
really work up until recently. There was a little darling routine in
ntp_io.c I used to pry the address from the interface's cold dead arms.
Yes, pogo is the only other public server here, but it is restricted
only for Autokey access. I suppose I could back out the ntp_io.c routine
and put back the old one from /backroom/ntp-sim, which was known to
work, but that of course would complicate your testing. If this is
something you think might work in a couple of days, I will wait the
The problem with the ntpdc utility, at least, is that I and the USNO and
NIST keepers have a paper due in November and it uses data gathered with
monlist. However, that should be low on your priority list if on the
list at all.
Danny Mayer wrote:
> At 06:30 PM 10/9/2004, David L. Mills wrote:
>> Turns out the failures in broadcast mode with IPv4 and IPv6 were
>> because of autokey, not the underlying I/O and protocol processing.
>> In symmetric key IPv4 broadcast and multicast and IPv6 broadcast all
>> works well. The problem with autokey is confirmed because the sender
>> sees only zeros instead of the expected address.
> That is because wildcard addresses are enabled. My new I/O gets rid of
> this. I haven't had a chance to test this yet and I still have a number
> of design issues to be resolved with my code.
>> Since this situation denies service to pogo customers using autokey,
>> either this should be fixed soon or we should back out to an I/O
>> version that works with autokey.
> My question is if this every really worked properly. My fix on Friday
> should have
> fixed the server side of things. The real issue is on the client side.
>> I don't mind so much if the test machines don't work, but rackety is
>> down and the only public server we have is accesable only with autokey.
> I assume you mean pogo.
>> There are two problems with the utilities. The ntpq run on howland
>> with target hepzibah (FreeBSD) hangs in the pe command; same program
>> and targe on deacon (Solaris) runs fine. The packets are on the wire,
>> just howland doesn't see them.
> It will take time to look into this.
>> The ntpdc with monlist command apparently loses the last packet and
>> times out. It works for a short list (10 entries), but times out on a
>> large list (600 entries). The packets apparently are on the wire, but
>> ntpdc doesn't believe them. This is odd; once upon a time if a packet
>> got lost the list was displayed anyway less whatever was lost.
> We know there is an issue with ntpdc and monlist but we haven't had
> the time
> to track this down.
More information about the hackers