Re: [Linuxptp-devel] mcast_bind patch

[Robert C. <rob...@oc...>]

Richard --

Thanks for the summary. I missed this in the kernel.

Let me read through this.

Bob Carter

On 3/19/19 4:28 AM, Richard Cochran wrote:
> On Mon, Mar 18, 2019 at 10:55:27PM +0000, Keller, Jacob E wrote:
>> 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.
> 
> So I read through the kernel transmit path, and the problem is that
> the interface (ie the configured IP address) is a link-local address.
> The kernel will only select such a SA when the multicast DA is a
> *local* MC DA.  This behavior agrees with the RFC.
> 
> ip_route_output_key_hash_rcu(...)
> {
> 	...
> 	if (fl4->flowi4_oif) {
> 		dev_out = dev_get_by_index_rcu(net, fl4->flowi4_oif);
> 		...
> 		if (ipv4_is_local_multicast(fl4->daddr) ||
> 		    ipv4_is_lbcast(fl4->daddr) ||
> 		    fl4->flowi4_proto == IPPROTO_IGMP) {
> 			if (!fl4->saddr)
> 				fl4->saddr = inet_select_addr(dev_out, 0,
> 							      RT_SCOPE_LINK);
> 			goto make_route;
> 		}
> 		if (!fl4->saddr) {
> 			if (ipv4_is_multicast(fl4->daddr))
> 				fl4->saddr = inet_select_addr(dev_out, 0,
> 							      fl4->flowi4_scope);
> 			else if (!fl4->daddr)
> 				fl4->saddr = inet_select_addr(dev_out, 0,
> 							      RT_SCOPE_HOST);
> 		}
> 	}
> }
> 
> Here flowi4_oif is the bound index.
> 
> Notice the test for ipv4_is_local_multicast().  It passes
> RT_SCOPE_LINK to inet_select_addr().
> 
> In contrast, in the ipv4_is_multicast() case, the passed
> fl4->flowi4_scope is RT_SCOPE_UNIVERSE.  That causes the link-local
> interfaces to be passed over.
> 
> So, it isn't correct to join a global MC group on a link-local
> interface, and I don't see any reason to support that case.  I
> especially do not want the program to bind to a specific address.
> After all, the interface's address may change at run time.
> 
> What *is* a problem is the fact that the program transmits on some
> other interface than the one specified.  Unfortunately the kernel
> doesn't flag this to the application as an error condition.  We should
> find a way to detect this situation and throw a fault.
> 
> Thanks,
> Richard
>