RARPD(8) FreeBSD System Manager's Manual RARPD(8)


rarpdreverse ARP daemon


rarpd -a [ -dfsv][ -t directory][ -P pidfile]

rarpd [ -dfsv][ -t directory][ -P pidfile] interface


The rarpd utility 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 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).

The following options are available:

Listen on all the Ethernets attached to the system. If -a is omitted, an interface must be specified.
If -f is also specified, rarpd logs messages to stdout and stderr instead of via syslog(3).
Run in the foreground.
Specify the pathname of the PID file. If not specified, /var/run/rarpd.pid or /var/run/rarpd.ifname.pid will be used depending on the -a flag or the specified interface name.
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*.
Supply an alternate tftp root directory to /tftpboot, similar to the -s option of tftpd(8). This permits rarpd to selectively respond to RARP requests, but use an alternate directory for IP checking.
Enable verbose syslogging.





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


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


The rarpd utility 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 recommended to configure nsswitch.conf(5) to read /etc/hosts first.
July 9, 2012 FreeBSD