From nobody Thu Mar 2 10:06:53 2023 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4PS6GF5txXz3vd7Y for ; Thu, 2 Mar 2023 10:07:01 +0000 (UTC) (envelope-from michael.tuexen@lurchi.franken.de) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "Sectigo RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4PS6GF27Xpz3v7w; Thu, 2 Mar 2023 10:07:01 +0000 (UTC) (envelope-from michael.tuexen@lurchi.franken.de) Authentication-Results: mx1.freebsd.org; none Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:c64:cf31:7eab:fd78]) (Authenticated sender: lurchi) by drew.franken.de (Postfix) with ESMTPSA id F3B1E7213B547; Thu, 2 Mar 2023 11:06:53 +0100 (CET) Content-Type: text/plain; charset=us-ascii List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: BPF to filter/mod ARP From: Michael Tuexen In-Reply-To: <202303020124.3221ODrn060000@gndrsh.dnsmgr.net> Date: Thu, 2 Mar 2023 11:06:53 +0100 Cc: "Scheffenegger, Richard" , "freebsd-net@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <202303020124.3221ODrn060000@gndrsh.dnsmgr.net> To: "Rodney W. Grimes" X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-Rspamd-Queue-Id: 4PS6GF27Xpz3v7w X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:680, ipnet:2001:638::/32, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N > On 2. Mar 2023, at 02:24, Rodney W. Grimes = 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