From owner-freebsd-current@FreeBSD.ORG Tue Aug 28 14:39:45 2007 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6DAAC16A418; Tue, 28 Aug 2007 14:39:45 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: from sub.vaned.net (sub.vaned.net [205.200.235.40]) by mx1.freebsd.org (Postfix) with ESMTP id 9FEC613C474; Tue, 28 Aug 2007 14:39:43 +0000 (UTC) (envelope-from csjp@sub.vaned.net) Received: by sub.vaned.net (Postfix, from userid 1001) id 8FAE61738A; Tue, 28 Aug 2007 08:59:29 -0500 (CDT) Date: Tue, 28 Aug 2007 08:59:29 -0500 From: "Christian S.J. Peron" To: "Bruce M. Simpson" Message-ID: <20070828135929.GA2305@sub.vaned.net> References: <20070828040026.GB42201@heff.fud.org.nz> <46D3C9F3.2010802@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <46D3C9F3.2010802@FreeBSD.org> User-Agent: Mutt/1.5.16 (2007-06-09) Cc: FreeBSD Current , Andrew Thompson Subject: Re: multicast packets from bpf 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: Tue, 28 Aug 2007 14:39:45 -0000 On Tue, Aug 28, 2007 at 08:08:35AM +0100, Bruce M. Simpson wrote: [..] > > I favour the first approach, however, it may make more sense to put the > logic into bpf_movein() as it already builds a sockaddr based on the header > data provided to bpf during a write. > > For the first patch: I previously fixed tapwrite() to check injected frames > in the same way, as this was causing a problem with my own use of > if_bridge. There is no way that I see for bpf to be able to tell if a frame > is link-layer multicast or not, and checking at that layer does introduce a > little pollution. Ethernet is the most common case so it could be argued > that's OK, as we have ethernet-specific fields in struct mbuf now. Your > change is the parallel change in the bpfwrite path to what I have in the > tapwrite path. > I think that tap(4) is a bit different since the only kind of frames it handles are Ethernet. This is not the case for bpf(4). I wonder if it makes sense to add this check into ether_output()? IIRC bpf will call the network interface's output routine, in the Ethernet/bridge case it should be ether_output(). Thoughts? -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer