Re: BPF to filter/mod ARP
- In reply to: Rodney W. Grimes: "Re: BPF to filter/mod ARP"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 02 Mar 2023 10:06:53 UTC
> 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 >