Date: Thu, 2 Mar 2023 09:20:00 -0800 (PST) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: Michael Tuexen <michael.tuexen@lurchi.franken.de> Cc: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net>, "Scheffenegger, Richard" <rscheff@FreeBSD.org>, "freebsd-net@freebsd.org" <freebsd-net@FreeBSD.org> Subject: Re: BPF to filter/mod ARP Message-ID: <202303021720.322HK0FY062742@gndrsh.dnsmgr.net> In-Reply-To: <E7DA9CFF-D4D0-4291-A0DC-32602AEE1ADE@lurchi.franken.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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? That is unclear to me, technically it should just be a binary blob and the kernel and userland just have to agree as to what it is. Understand that ipfw originally only had IP layer functionality. The ability to muck with layer2 was added later, so I suspect the documentation about what is sent over the divert socket may be out of date. Simple enough to test though, just setup as I show above only change to: ipfw add 111 divert 4444 all from any to any layer2 mac-type arp and write a program to dump what you get on the divert socket. I suspect you get an ethernet frame. And finally divert(4) says: NAME: divert kernel packet diversion mechanism That says packet, so again, IMHO, it should be arbitrary to what layer. It also later says "Divert sockets are similar to raw IP sockets", I think similar is the key aspect here, they are not identical. > > 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 > > > > > -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202303021720.322HK0FY062742>