Manpages - rarpd.8

rarpd - answer RARP REQUESTs

rarpd [*-AadevV*] [*-b */bootdir/] {interface}

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.

*arping*(8), *tftpd*(8).

rarpd was written by Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>.

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 90s and even earlier.

rarpd is part of the iputils package.