rarpd − answer RARP REQUESTs

rarpd [−AadevV] [−b bootdir] {interface}

     Listens RARP requests from clients. Provided MAC
address of client is found in /etc/ethers database and
obtained host name is resolvable to an IP address
appropriate for attached network, rarpd answers to client
with RARPD reply carrying an IP address.

     To allow multiple boot servers on the network rarpd
optionally checks for presence Sun−like bootable image in
TFTP directory. It should have form Hexadecimal_IP.ARCH,
f.e. to load sparc C1E90762.SUN4M is linked to
an image appropriate for SUM4M in directory /etc/tftpboot.

     This facility is deeply obsoleted by BOOTP and later
DHCP protocols. However, some clients really still need this
to boot.

     Listen on all the interfaces. Currently it is an
     internal option, its function is overridden with
     interface argument. It should not be used.

     Listen not only RARP but also ARP messages, some rare
     clients use ARP by some unknown reason.

     Be verbose.

     Debug mode. Do not go to background.

     Do not check for 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

     Print version and exit.


     arping(8), tftpd(8).

     rarpd was written by Alexey Kuznetsov

     rarpd requires CAP_NET_RAW capability to listen and
send RARP and ARP packets. It also needs CAP_NET_ADMIN to
give to kernel hint for ARP resolution; this is not strictly
required, but some (most of, to be more exact) clients are
so badly broken that are not able to answer ARP before they
are finally booted. This is not wonderful taking into
account that clients using RARPD in 2002 are all unsupported
relic creatures of 90's and even earlier.

     rarpd is part of iputils package.