RARPD(8)

NAME
rarpd - reverse ARP daemon

SYNOPSIS
rarpd [-afsv] [interface]

DESCRIPTION
Rarpd services Reverse ARP requests on the Ethernet connected to interface. Upon receiving a request, rarpd maps the target hardware address to an IP address via its name, which must be present in both the ethers(5) and hosts(5) databases. If a host does not exist in both databases, the translation cannot proceed and a reply will not be sent. By default, a request is honored only if the server (i.e., the host that rarpd is running on) can "boot" the target; that is, a file or directory matching the glob /tftpboot/ipaddr* exists, where ipaddr is the target IP address in hex. For example, the IP address 204.216.27.18 will be replied to if any of /tftpboot/CCD81B12, /tftpboot/CCD81B12.SUN3, or /tftpboot/CCD81B12-boot exist. This requirement can be overridden with the -s flag (see below). In normal operation, rarpd forks a copy of itself and runs in the background. Anomalies and errors are reported via syslog(3).

OPTIONS
The following options are available:

-a  Listen on all the Ethernets attached to the system. If -a is omitted, an interface must be specified.

-f  Run in the foreground.

-s  Supply a response to any RARP request for which an ethernet to IP address mapping exists; do not depend on the existence of /tftpboot/ipaddr*.

-v  Enable verbose sysloging.

FILES
/etc/ethers
/etc/hosts
/tftpboot

SEE ALSO
bpf(4)

RFC 903: Finlayson, R.; Mann, T.; Mogul, J.C.; Theimer, M. Reverse Address Resolution Protocol. 1984 June; 4 p.

AUTHORS
Craig Leres <leres@ee.lbl.gov> and Steven McCanne <mccanne@ee.lbl.gov>. Lawrence Berkeley Laboratory, University of California, Berkeley, CA.

BUGS
Rarpd can depend on the DNS to resolve the name discovered from /etc/ethers. If this name is not in the DNS but is in /etc/hosts, the DNS lookup can cause a delayed RARP response, so in this situation it is reccommended to configure /etc/host.conf to read /etc/hosts first.