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: >=20 >> Hi group, >>=20 >> Maybe someone can help me with this question - as I am usually only=20= >> looking at L4 and the top side of L3 ;) >>=20 >> In order to validate a peculiar switches behavior, I want to adjust = some=20 >> fields in gracious arps sent out by an interface, after a new IP is=20= >> assigned or changed. >=20 > Gracious or Gratuitous? >=20 >>=20 >> I believe BPF can effectively filter on arbitrary bit patterns and=20 >> modify packets on the fly. >=20 > It can. >=20 >>=20 >> However, as ARP doesn't seem to be accessible in the ipfw=20 >> infrastructure, I was wondering how to go about setting up an BPF to=20= >> tweak (temporarily) some of these ARPs to validate how the switch = will=20 >> behave. >=20 > 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. >=20 > 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 >=20 > 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=3D1 so that the filters at ether_demux > get turned on. >=20 > 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 >=20 >> (I need to validate, if there is some difference when the target=20 >> hardware address doesn't conform to RFC5227 - which states it SHOULD = be=20 >> zero and is ignored on the receiving side; i have reasons to believe=20= >> that the switch needs either a target hardware address of=20 >> ff:ff:ff:ff:ff:ff or the local interface MAC, to properly update it's=20= >> entries.) >>=20 >> Thanks a lot! >>=20 >> Richard >>=20 >=20 > --=20 > Rod Grimes = rgrimes@freebsd.org >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E7DA9CFF-D4D0-4291-A0DC-32602AEE1ADE>