Re: BPF to filter/mod ARP

From: Michael Tuexen <michael.tuexen_at_lurchi.franken.de>
Date: Thu, 02 Mar 2023 10:06:53 UTC
> On 2. Mar 2023, at 02:24, Rodney W. Grimes <freebsd-rwg@gndrsh.dnsmgr.net> wrote:
> 
>> 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 thought that you receive/send an IP packet on a divert socket, not
an ethernet frame. Am I wrong?

Best regards
Michael
> 
>> (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
>