[ntp:hackers] Re: multicast and ntp-dev

David L. Mills mills at udel.edu
Sat Nov 13 09:15:25 PST 2004


John,

Well, it used to work just fantastic, both on Solaris, FreeBSD and 
Alpha. The issue is rally simple. Whatever the IP addresses are as 
apparent to the server, the server must be the same addresses at the 
client. So, if the server uses a destination multicast address, the 
receiver must see the same address. Once upon a time the code used the 
broadcast address in the socket in that case and it worked peachy. I 
have no idea what is going on now.

Dave

John Hay wrote:

>Hi Guys,
>
>I think I have figured out why multicasting doesn't work in ntp-dev.
>(When it does work it is purely by accedent because of races.) Maybe
>I should just clarify, that is the type where you use multicastclient
>and use autokey with it. And this is on FreeBSD, so YMMV. I don't have
>a fix for it, but will try to describe what is happening.
>
>The short version of the problem is that the client try to use the
>socket that is bound to the multicast address to transmit packets.
>This fails because you can't use a multicast address as the source
>address of a packet. (Actually FreeBSD behaves differently for IPv4
>and IPv6 addresses. On IPv4 it actually sends the packet with the
>multicast address as the source and on IPv6 you get the EOPNOTSUPP
>error back.)
>
>Maybe a short description on a high level of how ntpd with
>multicastclient(s) configured should behave.
>
>1. The multicastclient line(s) in the ntp.conf file cause ntpd to
>   listen for those multicast packets.
>
>2. When a multicast packet from a new source arrives, it will create
>   a new association using newpeer(). This association is at first
>   not a multicast association but a "normal" client association,
>   using a normal unicast address for both sides.
>
>3  This association is then used to dance the crypto dance and also
>   to find out what the delay is.
>
>4  Once ntpd is happy with the association, it will switch it to
>   a multicast one and the client will only receive. If something
>   cause the multicast association to break, it will be dismantled
>   and a next multicast packet will cause the whole thing to start
>   over.
>
>Our current problems happen in stage 2 and stage 3. This is because
>the ntp_io.c part has split out the multicast stuff into seperate
>filedescriptors and the rest of the code hasn't kept up with it.
>This cause the new association to have the multicast address as
>the local address and trying to use that filedescriptor to send
>the packets.
>
>John
>  
>




More information about the hackers mailing list