Re: Multicast problems

Daniel Eischen wrote:
>
> I think in that case, the first non-loopback interface with IFF_MULTICAST
> should be chosen.  I think the loopback interface should be chosen in the
> absence of any other interface with IFF_MULTICAST set.  Our code does 
> rely
> on this as well.
>

That seems correct. The code to do this would belong in the conditional 
for INADDR_ANY in both the ASM and SSM join paths, if the route lookup 
fails. If we get a bad interface address from userland we still need to 
return an error as code should not be relying on the presence of the RFC 
1724 hack.

I see that the pre-4.x rc scripts added a 224/4 route before this code 
was introduced. The new multicast API shouldn't try to second-guess 
userland code in this way as it allows an interface index to be 
specified explicitly.

The nature of IGMP is such that it requires application joins to bind to 
an IPv4 interface. There are tweaks in IGMPv2 to workaround the possible 
lack of a protocol address e.g. during system bringup, however binding 
to an interface is still necessary.

IPv6 (MLDv1 and MLDv2) utterly side-steps this issue by making it 
mandatory for interfaces to have a protocol address, even if that is a 
link-local address, for multicast joins to work.

The condition we've seen is a side-effect of ip_multicast_if() being 
removed. Support for scoped addresses in the IPv4 stack will mean this 
code has to change again.

BMS