rarpd — answer RARP REQUESTs
rarpd  [
        -AadevV
      ] [
        -b
        
      ] {interface}bootdir
Listens for RARP requests broadcasted by clients. If the MAC address
    of the client is found in /etc/ethers and the obtained
    hostname is resolvable to a valid IP address from the attached network,
    rarpd answers to the client with a RARPD reply
    and provides an IP address.
To allow multiple boot servers on the network
    rarpd optionally checks if a Sun-like
    bootable image in the TFTP directory is present. It should be formatted like
    Hexadecimal_IP.ARCH. For example: To
    load sparc 193.233.7.98,
    C1E90762.SUN4M is linked to an
    image appropriate for SUN4M in the directory
    /etc/tftpboot.
This facility is deeply obsoleted by BOOTP and later DHCP protocols. However, some clients actually still need this to boot.
-a
        Listen on all available interfaces. Currently it is an internal option, its function is overwritten with the interface argument. It should not be used.
-A
        Listen not only to RARP but also ARP messages. Some rare clients use ARP for some unknown reason.
-v
        Be verbose.
-d
        Debug mode. Do not go to background.
-e
        Do not check for the presence of a boot image. Reply if
          MAC address resolves to a valid IP address using
          /etc/ethers database and DNS.
-b
          bootdir
        TFTP boot directory. Default is
          /etc/tftpboot
-V
        Print version and exit.
rarpd requires CAP_NET_RAW capability to listen and send RARP and ARP packets. It also needs CAP_NET_ADMIN to assist the kernel with ARP resolution; this is not strictly required, but some (to be more exact: most) of the clients are so badly broken that they are not able to answer to ARP before they are fully booted. This is no surprise, taking into account that clients using RARPD in 2002 are all unsupported relic creatures of the 90's and even earlier.