Re: BPF to filter/mod ARP
- Reply: Michael Tuexen : "Re: BPF to filter/mod ARP"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
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