Date: Wed, 1 Mar 2023 17:24:13 -0800 (PST) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: "Scheffenegger, Richard" <rscheff@FreeBSD.org> Cc: freebsd-net@FreeBSD.org Subject: Re: BPF to filter/mod ARP Message-ID: <202303020124.3221ODrn060000@gndrsh.dnsmgr.net> In-Reply-To: <b076d803-bc77-f3e2-8452-e85e3ac296b6@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202303020124.3221ODrn060000>