Date: Thu, 2 Mar 2023 11:06:53 +0100 From: Michael Tuexen <michael.tuexen@lurchi.franken.de> To: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> Cc: "Scheffenegger, Richard" <rscheff@FreeBSD.org>, "freebsd-net@freebsd.org" <freebsd-net@FreeBSD.org> Subject: Re: BPF to filter/mod ARP Message-ID: <E7DA9CFF-D4D0-4291-A0DC-32602AEE1ADE@lurchi.franken.de> In-Reply-To: <202303020124.3221ODrn060000@gndrsh.dnsmgr.net> References: <202303020124.3221ODrn060000@gndrsh.dnsmgr.net>
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? 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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E7DA9CFF-D4D0-4291-A0DC-32602AEE1ADE>