> -----Original Message----- > From: Robert Carter [mailto:[email protected]] > Sent: Monday, March 18, 2019 6:24 AM > To: Richard Cochran <[email protected]> > Cc: Keller, Jacob E <[email protected]>; > [email protected] > Subject: Re: [Linuxptp-devel] mcast_bind patch > > >> PTP needs to "work" over a local 169.254.0.0/16 network. This isn't > >> unreasonable. > > > > Maybe, but the kernel avoids it for some reason. I'd like to > > understand the root cause. > > Last night I downloaded the kernel.org 4.19.29 tarball and looked over > the bind code and setsockopt IP_MULTICAST_IF. I'm not seeing any > problems with the kernel implementation. I'm not finding anywhere that > the kernel forces dropping multicast sent over a link local address > interface. If I've missed something, then I'd welcome someone pointing > it out. Grep is our friend :-) > > My organization isn't using avahi. These are statically assigned link > local addresses used to create a unique management network. I'd agree > their usage is certainly "weird" and predate me. But, I'm not finding > anything in the kernel that prohibits their usage. We're running a stock > Ubuntu kernel. > > > Since the PTP multicast destination addresses are global in scope, > > combining a link-local SA with a PTP DA appears to be prohibited. > > > > Anyhow, maybe that is how the kernel sees it. > > I've firmly convinced myself that the problem here is an application > level issue. With the mcast_bind patch we bind to the correct interface > and there is no issue with multicast being sourced from the link local > address interface. If there was kernel level code to force these packets > to be dropped, the packets would never make it onto the wire.
Except that mcast_bind already takes an index number which should force binding to the correct interface. In your case, without passing the address, it doesn't bind to the correct interface specified by the index. My question is to understand why, in your case, the index is not sufficient. The fix to specify the address works for your case, but it doesn't make sense to me, because we should already be bound to the correct interface. Thanks, Jake _______________________________________________ Linuxptp-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
