From owner-freebsd-current@FreeBSD.ORG Mon Jun 18 17:48:25 2007 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 33F7116A41F for ; Mon, 18 Jun 2007 17:48:25 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.freebsd.org (Postfix) with ESMTP id D33CA13C46E for ; Mon, 18 Jun 2007 17:48:24 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.14.1/8.14.1/NETPLEX) with ESMTP id l5IHmK0e001468; Mon, 18 Jun 2007 13:48:21 -0400 (EDT) X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-3.0 (mail.ntplx.net [204.213.176.10]); Mon, 18 Jun 2007 13:48:21 -0400 (EDT) Date: Mon, 18 Jun 2007 13:48:20 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "Bruce M. Simpson" In-Reply-To: <4676C30E.7040300@incunabulum.net> Message-ID: References: <46765CB9.9020105@incunabulum.net> <4676C30E.7040300@incunabulum.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Ian FREISLICH , current@freebsd.org Subject: Re: Multicast problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2007 17:48:25 -0000 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