Re: Multicast problems

From: Bruce M. Simpson <bms_at_incunabulum.net>
Date: Mon, 18 Jun 2007 18:38:22 +0100
Daniel Eischen wrote:
> On Mon, 18 Jun 2007, Bruce M. Simpson wrote:
>>
>> Other folks reported issues with the new code. As you're probably 
>> aware, ipv4 multicast group memberships must be bound to an 
>> interface. When they are not, the interface selected as the source 
>> for the IGMP join uses a routing table lookup on the group.
>> The newer code changed to perform this lookup by interface index as 
>> well as by address, as interfaces used for ipv4 multicast traffic are 
>> generally assumed to have a protocol-level address.
>
> What happens when you join a group without an interface (INADDR_ANY)?
> Assume there is no route for the multicast group.  Does the new code
> select the interface that the default route is on?
Yes.

The new code is written in terms of the RFC 3678 API. The old IPv4 ASM 
API is a shell around it.

If no interface address is provided, either via an interface index or 
interface protocol address, it will perform a route lookup on the 
multicast group address to determine which interface to use when the 
group is being joined. Obviously a default route will satisfy this 
lookup; the BSD route lookup matches most specific match first.

I believe that the problems which folks have been seeing is that some 
old behaviour hasn't been captured in the new code.
This behaviour is that if the route lookup fails, the code would select 
the first interface in the system with IFF_MULTICAST set on it (usually 
the loopback address). This used to be contained in the 
ip_multicast_if() function which was phased out.

Joining a multicast group on INADDR_ANY is non-specific. It's a bit like 
sending a datagram to 255.255.255.255 -- the group address alone is not 
a sufficient key without additional information from the routing table.

It seems reasonable that the code should use the interface of the 
default route if no interface address is provided. However this doesn't 
cover the case where no default route exists during system bringup.

So a possible interim fix is to restore the 'choose first multicast 
interface' behaviour. As time goes on however this code will need to be 
changed to support scoped addresses, and to only look at interfaces to 
which PF_INET is bound.

BMS
Received on Mon Jun 18 2007 - 15:38:33 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:12 UTC