From owner-freebsd-net@FreeBSD.ORG Wed Aug 1 14:34:41 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 678E216A478; Wed, 1 Aug 2007 14:34:41 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.freebsd.org (Postfix) with ESMTP id 3E42813C45D; Wed, 1 Aug 2007 14:34:41 +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 C1A6BB7AF; Wed, 1 Aug 2007 10:34:40 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 01 Aug 2007 10:34:40 -0400 X-Sasl-enc: KCW249kwnW2XPlpzq9ggNBIZDrWfchDl1q+NGE5SCQv1 1185978880 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 0D31BEB; Wed, 1 Aug 2007 10:34:39 -0400 (EDT) Message-ID: <46B099F8.5040301@incunabulum.net> Date: Wed, 01 Aug 2007 15:34:32 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 1.5.0.12 (Windows/20070509) MIME-Version: 1.0 To: "Christian S.J. Peron" References: <20070731162515.GA3684@sub> <46AF7E57.5020209@incunabulum.net> <20070731204156.GA7614@sub> <46AFB6C9.20401@incunabulum.net> <46AFC441.2070502@elischer.org> <20070801001908.GA8822@sub> In-Reply-To: <20070801001908.GA8822@sub> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, rwatson@freebsd.org, Julian Elischer Subject: Re: divert and deadlock issues X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2007 14:34:41 -0000 Christian S.J. Peron wrote: > Well, it's still the intent to keep the ability to divert and re-inject > multicast packets. This change would basically say: "You cant specify > multicast options via the divert socket". Which in practice doesn't > happen anyway (where I looked). > > I dont think we should be specifying multicast options on divert sockets. > It's not the right place to be manipulating multicast parameters. Multicast > parameters should be set on the sockets that originally transmitted or > received the packets. I dont think divert falls into this category. > Correct. The definition of what a divert socket is and does, falls outside the definition of what a multicast socket endpoint is. Divert sockets exist to munge packets as they flow up or down the stack. If the additional complexity of treating divert sockets as multicast endpoints causes locking issues in the stack, common sense suggests we should deprecate that behaviour. BMS