.\" Copyright (c) 1983 Regents of the University of California. .\" All rights reserved. The Berkeley software License Agreement .\" specifies the terms and conditions for redistribution. .\" .\" @(#)imp.4 6.2 (Berkeley) 5/16/86 .\" .TH IMP 4 "May 16, 1986" .UC 5 .SH NAME imp \- 1822 network interface .SH SYNOPSIS .B pseudo-device imp [ count ] .SH DESCRIPTION The .I imp interface, as described in BBN Report 1822, provides access to an intelligent message processor normally used when participating in the Department of Defense ARPA network. The network interface communicates through a device controller, usually an ACC LH/DH or HDH or a DEC IMP-11A, with the IMP. The interface is \*(lqreliable\*(rq and \*(lqflow-controlled\*(rq by the host-IMP protocol. .PP To configure IMP support, at least one of .IR acc (4), .IR css (4) or .IR hdh (4) must be included. The optional .I count specifies the total number of IMP connections. The network number on which the interface resides is specified at boot time using the SIOCSIFADDR ioctl. The host number is discovered through receipt of NOOP messages from the IMP. .PP The network interface is always in one of four states: up, down, initializing, or going down. When the system is booted, the interface is marked down. If the hardware controller is successfully probed, the interface enters the initializing state and transmits three NOOP messages to the IMP. It then waits for the IMP to respond with two or more NOOP messages in reply. When it receives these messages it enters the up state. The ``going down'' state is entered only when notified by the IMP of an impending shutdown. Packets may be sent through the interface only while it is in the up state. Outgoing packets are dropped with the error ENETDOWN returned to the caller if the interface is in any other state. .SH DIAGNOSTICS \fBimp%d: not configured\fP. A hardware interface could not be attached during autoconfiguration because too few IMP pseudo-devices were configured. .PP \fBimp%d: leader error\fP. The IMP reported an error in a leader (1822 message header). This causes the interface to be reset and any packets queued up for transmission to be purged. .PP \fBimp%d: going down in 30 seconds\fP. .br \fBimp%d: going down for hardware PM\fP. .br \fBimp%d: going down for reload software\fP. .br \fBimp%d: going down for emergency reset\fP. The Network Control Center (NCC) is manipulating the IMP. By convention these messages are reported to all hosts on an IMP. .PP \fBimp?: host %x, lost %d rfnms\fP. The IMP had messages outstanding to the host listed, but no RFNM (Request for Next Message) messages were received from the IMP in 127 seconds. The software state for that host is reinitialized. .PP \fBimp%d: interface reset\fP. The host has received an interface reset message from the IMP. .PP \fBimp%d: address reset to x%x (%d/%d)\fP. The host has received a NOOP message which caused it to reset its notion of its current address. The Internet address is printed in hexadecimal, with the host and IMP numbers following. This indicates that the address originally set by .IR ifconfig (8) was incorrect, that the IMP has undergone an identity crisis, or that communication between the IMP and the host is being garbled. .PP \fBimp%d: data error\fP. The IMP noted an error in data transmitted. The host-IMP interface is reset and the host enters the init state (awaiting NOOP messages). .PP \fBimp%d: interface reset\fP. The reset process has been completed. .PP \fBimp%d: marked down\fP. After receiving a \*(lqgoing down in 30 seconds\*(rq message, and waiting 30 seconds, the host has marked the IMP unavailable. Before packets may be sent to the IMP again, the IMP must notify the host, through a series of NOOP messages, that it is back up. .PP \fBimp%d: can't handle af%d\fP. The interface was handed a message with addresses formatting in an unsuitable address family; the packet was dropped. .SH SEE ALSO intro(4N), inet(4F), acc(4), css(4), hdh(4), implog(8), implogd(8)