Date: Tue, 11 Jan 2005 12:07:55 -0800 (PST) From: Kelly Yancey <kbyanc@posi.net> To: =?ISO-8859-2?Q?=A3ukasz_Bromirski?= <lbromirski@mr0vka.eu.org> Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw/verrevpath and source MAC logging - reloaded Message-ID: <20050111115411.V40364@gateway.posi.net> In-Reply-To: <41E04D6B.3020801@mr0vka.eu.org> References: <41E04D6B.3020801@mr0vka.eu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 8 Jan 2005, [ISO-8859-2] =A3ukasz Bromirski wrote:
> Hi,
>
> I've asked few days ago (two weeks actually), about implementing
> something like `log-input' keyword just like on Cisco IOS routers,
> when the ACE with this argument is hit it logs also the source MAC
> address, which is very valuable on multiaccess networks, like
> Ethernet. As nobody responded, I've digged the sources for a moment,
> and with my limited knowledge about mbuf's I'm stuck at the following
> comment:
>
> ip_fw2.c:
>
> * args->eh The MAC header. It is non-null for a layer2
> * packet, it is NULL for a layer-3 packet.
>
> ...so, is there some good soul on the list that will point me
> where to look for MAC source address when we're dealing with
> `layer 3 packet' in ipfw nomenclature?
>
args->eh->ether_shost iff args->eh !=3D NULL.
What is confusing is that when the comments in ipfw say "layer 3
packet" they mean a packet being filtered from a layer 3 hook. When
net.inet.ip.fw.enable=3D1, that doesn't *really* mean enable ipfw, but it
actually means enable ipfw hooks from the IP layer (layer 3). In this
case, args->eh is always NULL.
When net.link.ether.ipfw=3D1 and net.inet.ip.fw.enable=3D0, that says
enable ipfw hooks from the ethernet layer (layer 2). In this case
args->eh is always non-NULL, so you can get the source MAC address.
However, the packet itself may still be an IP packet, in which case any
of the normal "layer 3" rules may still match the packet.
Finally, when net.link.ether.ipfw=3D1 and net.inet.ip.fw.enable=3D1, that
says enable ipfw hooks from both layer 2 and layer 3. I can't think of
a good reason to ever do this offhand. Enabling hooks from both layers
causes all of your firewall rules to be evaluated once at layer 2, then
if the packet is an IP packet, all of the rules are checked again at
layer 3. Repeat for the output path in the opposite order (layer 3 then
layer 2).
In any event, since you can't know which sysctls the user may enable,
you just need to check whether args->eh is NULL first. If it is NULL,
you don't have access to the MAC information so your new ipfw
instruction won't match (will be a no-op). For your testing, you will
want to set net.link.ether.ipfw=3D1 and net.inet.ip.fw.enable=3D0.
Simiarly, any users who would want to use your new instruction, would
also have to have net.link.ether.ipfw=3D1.
Good luck,
Kelly
--
Kelly Yancey - kbyanc@{posi.net,FreeBSD.org} - kelly@nttmcl.com
Join distributed.net Team FreeBSD: http://www.posi.net/freebsd/Team-FreeBSD=
/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050111115411.V40364>