[ntp:hackers] Weekend

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:
>> Guys,
>> 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.
> Danny
>> Dave

More information about the hackers mailing list