From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 17 01:39:39 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 25C87F42; Mon, 17 Mar 2014 01:39:39 +0000 (UTC) Received: from felyko.com (felyko.com [IPv6:2607:f2f8:a528::3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id 0B409C4C; Mon, 17 Mar 2014 01:39:39 +0000 (UTC) Received: from [10.0.1.3] (c-24-6-115-18.hsd1.ca.comcast.net [24.6.115.18]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 4844539841; Sun, 16 Mar 2014 18:39:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: mbuf question From: Rui Paulo In-Reply-To: <20140316212106.GF32089@funkthat.com> Date: Sun, 16 Mar 2014 18:39:38 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7FA2AB99-EE03-4E84-A67D-F3FCD734B66B@FreeBSD.org> References: <53230214.7010501@gmail.com> <532405B7.2020007@gmail.com> <96659837-1FDC-421D-A339-87104A0075C7@FreeBSD.org> <5324D669.804@gmail.com> <5324DAC0.9020508@gmail.com> <1394925228.1149.558.camel@revolution.hippie.lan> <5325BC99.2060703@gmail.com> <20140316212106.GF32089@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1874) Cc: FreeBSD Hackers , Ian Lepore , Hooman Fazaeli X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 01:39:39 -0000 On 16 Mar 2014, at 14:21, John-Mark Gurney wrote: > Why do we need this info in another location? Isn't this already in > the packet? How else did we get it then? Or are you dealing w/ the > fact that the L2 information was stripped by an upper layer, and if > that is the case, shouldn't you be getting the packet soon then? It's mostly because the netpfil hooks are in layer 3. The layer 2 = headers are stripped by layer 2 code before it passes the mbuf to layer = 3. I don't know what the goals are, so it's hard to suggest alternatives... = Do we want to filter IP packets based on L2 information or do we want to = filter L2 packets like ARP? It's possible that the best alternative is = to extend netpfil to layer 2 and then validate the mbuf there. -- Rui Paulo