ISIBOOTD(8) BSD System Manager's Manual ISIBOOTD(8)NAME
isibootd -- TRFS based network boot server
isibootd [-d tracelevel] [-i interface] [-s directory]
The isibootd command is a server which supports OMRON LUNA's network boot protocol based on the Transparent Remote File System (TRFS) proto-
col. The TRFS protocol uses special Ethernet type packets and works within a local network.
isibootd is a simple TRFS server that only supports client reads for booting and exports files in a specified directory. isibootd accepts
requests only from clients listed in the /etc/ethers and have valid hostnames.
The options are as follows:
Run isibootd in debug mode with specified tracelevel. The tracelevel can be value 1, 2, or 3, and greater tracelevel provides
more detailed trace output. The server will not fork in the debug mode.
Specify a network interface to service network boot. If not specified isibootd searches available network interfaces (excluding
loopback) and use the first configured ``up'' one.
Specify a directory containing boot files to be served by isibootd. If not specified isibootd uses /tftpboot by default.
SEE ALSO ethers(5), hosts(5), tftpd(8)
isibootd is based on isiboot utility which was originally written by Tohru Nishimura for NetBSD/luna68k development, and first appeared in
BSD December 15, 2011 BSD
Check Out this Related Man Page
RARPD(8) BSD System Manager's Manual RARPD(8)NAME
rarpd -- reverse 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
126.96.36.199 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:
-a Listen on all the Ethernets attached to the system. If -a is omitted, an interface must be specified.
-d If -f is also specified, rarpd logs messages to stdout and stderr instead of via syslog(3).
-f Run in the foreground.
-P 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.
-s Supply a response to any RARP request for which an ethernet to IP address mapping exists; do not depend on the existence of
-t 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.
-v Enable verbose syslogging.
SEE ALSO bpf(4)
Finlayson, R., Mann, T., Mogul, J.C., and Theimer, M., RFC 903: Reverse Address Resolution Protocol, June 1984, 4 p.
Craig Leres <email@example.com> and Steven McCanne <firstname.lastname@example.org>. Lawrence Berkeley Laboratory, University of California, Berkeley,
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
BSD July 9, 2012 BSD