From owner-freebsd-current@FreeBSD.ORG Mon Jun 18 17:38:33 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 36F4016A41F for ; Mon, 18 Jun 2007 17:38:33 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 0734A13C458 for ; Mon, 18 Jun 2007 17:38:32 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id A0FB519A4; Mon, 18 Jun 2007 13:38:32 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 18 Jun 2007 13:38:32 -0400 X-Sasl-enc: 0O1O31ez+5qoJfu+tAeUKtjFOOjZqkrNgmToeS+Uoboq 1182188312 Received: from [192.168.123.18] (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTP id C85D415255; Mon, 18 Jun 2007 13:38:31 -0400 (EDT) Message-ID: <4676C30E.7040300@incunabulum.net> Date: Mon, 18 Jun 2007 18:38:22 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: Daniel Eischen References: <46765CB9.9020105@incunabulum.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ian FREISLICH , current@freebsd.org Subject: Re: Multicast problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list 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:38:33 -0000 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