mayer at gis.net
Sun Oct 10 15:22:24 PDT 2004
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
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