[ntp:hackers] Joy of ACTS, but some sorrow otherwise

[David L. Mills]

Danny,

I confirmed with multicast/anycast server malarky that client bridgeport 
behaves as I described previously. The association starts out with the 
expected unicast address of malarky, then switches to its multicast 
address, which wrecks Autokey. The newpeer() routine does the 
initialization, which is correct. Nowhere else in the peer or protocol 
code is dstadr modified. I conclude it has to be in the ntp_io.c, but I 
can't find it.

Note as I said previously, the multicast and broadcast code behaves 
differently. In that case the dstadr turns up zeros.

Dave

Danny Mayer wrote:

> At 09:06 PM 2/26/2005, David L. Mills wrote:
>
>> Danny,
>>
>> Host rackety has used some 192 minutes of CPU cycles in less than a 
>> day. Before I axed out the error comment in ntp_io.c, an attempt to 
>> read the clock resulted in a continuous scroll of error messaged. The 
>> WWVB driver on rackety is identical to the one on pogo, which runs as 
>> expected.
>>
>> To see the evidence, start the daemon with -d -d and watch the trace.
>
>
> So why don't I see the dial string on rackety when I do this? I have a 
> very large
> log file from this afternoon on rackety. There is no evidence that beyond
> opening a file decriptor that it knew what to do. That's why I wondered
> about broken hardware. Isn't it identical to mort's config?
>
>> The problem is not just a multicast client, it's an Autokey 
>> multicast/broadcast client. I've described the problem in detail a 
>> number of times recently. If you wish, I will describe it again.
>
>
> That's what bridgeport is using. It works fine as a multicast IPv4 
> client.
>
> Danny