Date: Sun, 16 Mar 2014 18:39:38 -0700 From: Rui Paulo <rpaulo@FreeBSD.org> To: John-Mark Gurney <jmg@funkthat.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, Ian Lepore <ian@freebsd.org>, Hooman Fazaeli <hoomanfazaeli@gmail.com> Subject: Re: mbuf question Message-ID: <7FA2AB99-EE03-4E84-A67D-F3FCD734B66B@FreeBSD.org> In-Reply-To: <20140316212106.GF32089@funkthat.com> References: <53230214.7010501@gmail.com> <BBAFAB2A-F496-46A2-8FE0-224BE562EAA7@FreeBSD.org> <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> <BEA4D691-6405-4D5B-B437-DAEB655D45EF@FreeBSD.org> <5325BC99.2060703@gmail.com> <20140316212106.GF32089@funkthat.com>
index | next in thread | previous in thread | raw e-mail
On 16 Mar 2014, at 14:21, John-Mark Gurney <jmg@funkthat.com> 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 Paulohelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7FA2AB99-EE03-4E84-A67D-F3FCD734B66B>