mbuf question

[Hooman Fazaeli]

On 3/17/2014 6:09 AM, Rui Paulo wrote:
> On 16 Mar 2014, at 14:21, John-Mark Gurney <jmg at 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 Paulo
>
My goal is to add src/dst  MAC address constraint to pf filter/nat/rdr/binat/anchor rules to be used in combination with other constraints (protocol, IP address, ...).
When done,  we can write rules like the following:

table <macs> { 00.11.22.33.44.55 00.4d.54.f1.43.33  }
table <ips> { 192.168.1.2 192.168.1.3}
gateway1 = "00.23.45.99.d3.e4"

# Restrict 10.20.30/24 subnet's web traffic to come from gateway1
block in quick on em1 proto tcp from mac ! $gateway1 10.20.30/24 to any port http

# sort of IP/MAC binding
block  in on em0 from mac <macs> ! <ips> to any
block in on em0 from mac ! <macs> <ips> to any


-- 

Best regards.
Hooman Fazaeli