isibootd(8) [netbsd man page]

ISIBOOTD(8)						    BSD System Manager's Manual 					       ISIBOOTD(8)

NAME

     isibootd -- TRFS based network boot server

SYNOPSIS

     isibootd [-d tracelevel] [-i interface] [-s directory]

DESCRIPTION

     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:

     -d tracelevel
		 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.

     -i interface
		 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.

     -s directory
		 Specify a directory containing boot files to be served by isibootd.  If not specified isibootd uses /tftpboot by default.

FILES

     /etc/ethers
     /etc/hosts
     /tftpboot
     /var/run/isibootd.pid

SEE ALSO

     ethers(5), hosts(5), tftpd(8)

     http://www.NetBSD.org/ports/luna68k/install.html

HISTORY

     isibootd is based on isiboot utility which was originally written by Tohru Nishimura for NetBSD/luna68k development, and first appeared in
     NetBSD 6.0.

BSD
								 December 15, 2011							       BSD

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

NAME

     rarpd -- reverse ARP daemon

SYNOPSIS

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

DESCRIPTION

     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
     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).

     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
	     /tftpboot/ipaddr*.

     -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.

FILES

     /etc/ethers
     /etc/hosts
     /tftpboot
     /var/run/rarpd.pid

SEE ALSO

     bpf(4)

     Finlayson, R., Mann, T., Mogul, J.C., and Theimer, M., RFC 903: Reverse Address Resolution Protocol, June 1984, 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

     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.

BSD
								   July 9, 2012 							       BSD