From owner-freebsd-net@FreeBSD.ORG Mon Nov 15 20:15:20 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C72416A4CE; Mon, 15 Nov 2004 20:15:20 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 358FA43D1D; Mon, 15 Nov 2004 20:15:20 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.13.1/8.13.1) with ESMTP id iAFKDrnf028211; Mon, 15 Nov 2004 15:13:53 -0500 (EST) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)iAFKDrVu028208; Mon, 15 Nov 2004 20:13:53 GMT (envelope-from robert@fledge.watson.org) Date: Mon, 15 Nov 2004 20:13:53 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Archie Cobbs In-Reply-To: <200411151417.iAFEHfhN015171@arch20m.dellroad.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: maxim@freebsd.org cc: net@freebsd.org Subject: Re: divert(4) socket isn't connection oriented X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Nov 2004 20:15:20 -0000 On Mon, 15 Nov 2004, Archie Cobbs wrote: > Gleb Smirnoff wrote: > > Since it is working, it was not noticed quickly. Real problems occur when > > a multicast packet comes on interface: it is diverted to ng_ksocket, returned > > and div_output() sends it to ip_output(). In ip_output() it is ip_mloopback()ed > > and if_simloop()ed. A copy of packet enters divert socket, duplicated... a > > forever loop and total freeze. > > Your fix makes sense, but is it more of a workaround than a proper fix? > It seems like the real bug is that divert is promising to write the > packet as "outgoing" yet the packet loops back as "incoming". Maybe it > would make more sense to attach a tag to the packet that divert would > recognize and know to ignore the extra incoming packet. > > Also, does the same thing happen with broadcast packets? I'm not sure I'm so worried about the loopback case -- it strikes me that in a world with lots of layering, processing, tunneling, you need to be able to support the packet "coming back" based on topology (i.e., perhap a source routed packet) if it matches the criteria for diversion. The current behavior appears to be an implementation quirk associated with divert sockets permitting connection without quite having the more common datagram socket semantics for connection... I.e., what if I want the same packet to be diverted again after it's been reinjected? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research