1.\" Copyright (c) 1990, 1991 The Regents of the University of California. 2.\" All rights reserved. 3.\" 4.\" This code is derived from software contributed to Berkeley by 5.\" the Systems Programming Group of the University of Utah Computer 6.\" Science Department. 7.\" Redistribution and use in source and binary forms, with or without 8.\" modification, are permitted provided that the following conditions 9.\" are met: 10.\" 1. Redistributions of source code must retain the above copyright 11.\" notice, this list of conditions and the following disclaimer. 12.\" 2. Redistributions in binary form must reproduce the above copyright 13.\" notice, this list of conditions and the following disclaimer in the 14.\" documentation and/or other materials provided with the distribution. 15.\" 3. All advertising materials mentioning features or use of this software 16.\" must display the following acknowledgement: 17.\" This product includes software developed by the University of 18.\" California, Berkeley and its contributors. 19.\" 4. Neither the name of the University nor the names of its contributors 20.\" may be used to endorse or promote products derived from this software 21.\" without specific prior written permission. 22.\" 23.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND 24.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 25.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 26.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE 27.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL 28.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS 29.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) 30.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 31.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY 32.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF 33.\" SUCH DAMAGE. 34.\" 35.\" from: @(#)rmp.4 5.2 (Berkeley) 3/27/91 36.\" $NetBSD: rmp.4,v 1.9 2003/05/15 10:20:48 wiz Exp $ 37.\" 38.Dd May 15, 2003 39.Dt RMP 4 hp300 40.Os 41.Sh NAME 42.Nm rmp 43.Nd 44.Tn HP 45Remote Maintenance Protocol Family 46.Sh SYNOPSIS 47.Cd "options RMP" 48.In sys/types.h 49.In sys/socket.h 50.In netrmp/rmp.h 51.In netrmp/rmp_var.h 52.Ft int 53.Fn socket AF_RMP SOCK_RAW proto 54.Sh DESCRIPTION 55Hewlett-Packard's Remote Maintenance Protocol family is a collection 56of protocols layered atop 57.Tn IEEE 802.3 . 58The current implementation of the RMP family provides protocol support only 59for the 60.Dv SOCK_RAW 61socket type. 62As a result, 63.Xr sendto 2 64and 65.Xr recvfrom 2 66must be used to send and 67receive 68.Tn RMP 69packets. 70.Pp 71The format of an 72.Tn RMP 73packet is defined in the include file 74.Aq Pa netrmp/rmp_var.h . 75The 76.Tn RMP 77packet arrives encapsulated in an 78.Pf ( Tn HP 79extended) 80.Tn IEEE 802.2 81packet. 82The 83.Tn IEEE 802.2 84packet 85is preceded by the kernel address of an 86.Ar ifnet struct 87which is used to `route' a packet out the same interface it 88arrived on. 89Outgoing packets are encapsulated in a standard 90.Tn IEEE 802.3 91packet, while incoming packets have this information stripped away. 92.Sh ADDRESSING 93.Tn RMP 94.Pf ( Tn IEEE 95802.3) addresses are 6 octets in length (48 bytes). 96Sockets in the Remote Maintenance Protocol family use the following 97addressing structure: 98.Bd -literal -offset indent 99struct sockaddr_rmp { 100 short srmp_family; 101 u_char srmp_dhost[6]; 102}; 103.Ed 104.Sh PROTOCOLS 105The 106.Tn RMP 107protocol family supported by the operating system 108currently consists of the Boot Protocol 109.Pq Em proto= Ns Dv RMPPROTO_BOOT . 110Unfortunately, we have no documentation on the Remote Maintenance 111Protocol and only sketchy information about the Boot Protocol. 112.Sh SEE ALSO 113.Xr bind 2 , 114.Xr recvfrom 2 , 115.Xr sendto 2 , 116.Xr socket 2 , 117.Xr intro 4 , 118.Xr rbootd 8 119.Rs 120.%T "An Introductory 4.4BSD Interprocess Communication Tutorial" 121.%A Stuart Sechrest 122.Re 123.Pq see Pa /usr/share/doc/psd/20.ipctut 124.Rs 125.%T "Advanced 4.4BSD IPC Tutorial" 126.%A Samuel J. Leffler 127.%A Robert S. Fabry 128.%A William N. Joy 129.%A Phil Lapsley 130.%A Steve Miller 131.%A Chris Torek 132.Re 133.Pq see Pa /usr/share/doc/psd/21.ipc 134.Sh HISTORY 135The 136.Nm 137protocol interface 138.Ud 139.Sh BUGS 140.Bl -bullet 141.It 142The 143.Tn HP ROM 144uses 145.Tn IEEE 146802.3 (as opposed to Ethernet) packets. While the 147kernel heuristically recognizes these packets, a more general mechanism 148for doing so should be provided. 149.It 150The 151.Tn HP ROM 152uses a multicast address when first trying to locate boot 153servers. While the Ethernet [sic] board is programmed to recognize 154this particular multicast address (9:0:9:0:0:4), a more general 155mechanism for doing so should be provided. 156.It 157The kernel supports only 158.Tn RAW 159sockets for the 160.Tn RMP 161protocol. 162This is either a bug or a feature, since the kernel is smaller at the 163price of greater complexity in the server. 164.It 165There is no support for 166.Xr bind 2 Ns 'ing 167an address in the 168.Tn RMP 169domain. 170Something like an 171.Dv RMPADDR_ANY 172should be provided to prevent more than one 173.Xr rbootd 8 174server from running at the same time. 175.El 176