Re: BPF to filter/mod ARP

From: Rodney W. Grimes <freebsd-rwg_at_gndrsh.dnsmgr.net>
Date: Thu, 02 Mar 2023 01:24:13 UTC
> Hi group,
> 
> Maybe someone can help me with this question - as I am usually only 
> looking at L4 and the top side of L3 ;)
> 
> In order to validate a peculiar switches behavior, I want to adjust some 
> fields in gracious arps sent out by an interface, after a new IP is 
> assigned or changed.

Gracious or Gratuitous?

> 
> I believe BPF can effectively filter on arbitrary bit patterns and 
> modify packets on the fly.

It can.

> 
> However, as ARP doesn't seem to be accessible in the ipfw 
> infrastructure, I was wondering how to go about setting up an BPF to 
> tweak (temporarily) some of these ARPs to validate how the switch will 
> behave.

ipfw is IP firewall, a layer 3 function.  Arp is a layer 2 protocol,
so very hard to do much with it in ipfw, but perhaps the layer2
keyword, and some use of mac-type can get it to match an arp
packet.  Arp is ethernet type 0x806.

ipfw add 111 count log all from any to any layer2 mac-type arp
That does seem to work
ipfw -a list 111
00111    4       0 count log ip from any to any layer2 mac-type 0x0806

Also normally ipfw does NOT pick packets up early enough to see
them, to get the layer2 option to work you need:
sysctl net.link.ether.ipfw=1 so that the filters at ether_demux
get turned on.

So perhaps use a divert rule and send them to a socket where
a program can mangle them, and then return them to ipfw
and hopefully the kernel does what you want after that...

> (I need to validate, if there is some difference when the target 
> hardware address doesn't conform to RFC5227 - which states it SHOULD be 
> zero and is ignored on the receiving side; i have reasons to believe 
> that the switch needs either a target hardware address of 
> ff:ff:ff:ff:ff:ff or the local interface MAC, to properly update it's 
> entries.)
> 
> Thanks a lot!
> 
> Richard
> 

-- 
Rod Grimes                                                 rgrimes@freebsd.org