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.