From owner-freebsd-current@FreeBSD.ORG Mon Jun 18 18:05:32 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 7232416A468; Mon, 18 Jun 2007 18:05:32 +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 483D113C455; Mon, 18 Jun 2007 18:05: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 1E3D61A23; Mon, 18 Jun 2007 14:05:17 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Mon, 18 Jun 2007 14:05:22 -0400 X-Sasl-enc: T8b2m5/QmF8+CuZKZ3GtwJp1rYNEfkwbPANXjWv4NEpg 1182189916 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 E9DCB111FA; Mon, 18 Jun 2007 14:05:15 -0400 (EDT) Message-ID: <4676C952.5000607@incunabulum.net> Date: Mon, 18 Jun 2007 19:05:06 +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> <4676C30E.7040300@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 18:05:32 -0000 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