Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Jun 2007 13:48:20 -0400 (EDT)
From:      Daniel Eischen <deischen@freebsd.org>
To:        "Bruce M. Simpson" <bms@incunabulum.net>
Cc:        Ian FREISLICH <ianf@clue.co.za>, current@freebsd.org
Subject:   Re: Multicast problems
Message-ID:  <Pine.GSO.4.64.0706181344060.24865@sea.ntplx.net>
In-Reply-To: <4676C30E.7040300@incunabulum.net>
References:  <E1I0E3b-0000kk-Ky@clue.co.za> <46765CB9.9020105@incunabulum.net> <Pine.GSO.4.64.0706180833080.23884@sea.ntplx.net> <4676C30E.7040300@incunabulum.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 18 Jun 2007, Bruce M. Simpson wrote:

> 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.

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.

-- 
DE



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.0706181344060.24865>