bind -a #I[ifn] /net /net/arp /net/bootp /net/iproute /net/ipselftab /net/iprouter /net/log /net/ipifc/clone /net/ipifc/stats /net/ipifc/n /net/ipifc/n/data /net/ipifc/n/ctl /net/ipifc/n/local /net/ipifc/n/status /net/proto/clone /net/proto/stats /net/proto/n /net/proto/n/ctl /net/proto/n/data /net/proto/n/err /net/proto/n/local /net/proto/n/remote /net/proto/n/status /net/proto/n/listen ...
Hosted Inferno provides a subset of the interface described here that gives to the TCP/IP and UDP/IP of the host system's own IP subsystem. See Hosted interfaces below for a summary of the differences.
Each of the protocols is served by the IP device, which represents a connection by a set of device files. The top level directory, proto in the SYNOPSIS above, is named after a protocol (eg, tcp, il, udp) and contains a clone file, a stats file, and subdirectories numbered from zero to the number of connections configured for this protocol.
The read-only stats file contains protocol-specific statistics as one or more lines of text. There is no particular format, but the values are often a superset of those required by the SNMP MIB.
Opening the clone file reserves a connection, represented by one of the numbered subdirectories. The resulting file descriptor will be open on the control file, ctl, of the newly allocated connection. Reading the ctl file returns a text string representing the number of the connection. Connections may be used either to listen for incoming calls or to initiate calls to other machines.
A connection is controlled by writing text strings to the associated ctl file. After a connection has been established data may be read from and written to the data file.
Before sending data, remote and local addresses must be set for the connection. For outgoing calls the local port number will be allocated randomly if none is set. Addresses are set by writing control messages to the ctl file of the connection. The connection is not established until the data file is opened. There are two models depending on the nature of the protocol. For connection-oriented protocols, the process will block on open until the remote host has acknowledged the connection, either accepting it, causing a successful return from open, or rejecting it, causing open to return an appropriate error. For connectionless protocols, the open always succeeds; the `connect' request sets local parameters for the source and destination fields for use by subsequent read and write requests.
The following control messages are provided by this interface to all protocols. A particular protocol can provide additional commands, or change the interpretation or even syntax of those below, as described in the manual page for that protocol. The description below shows the standard commands with the default argument syntax and interpretation:
Port numbers must be in the range 1 to 32767.
Several read-only files report the status of a connection. The remote and local files contain the IP address and port number for the remote and local side of the connection. The status file contains protocol-dependent information to help debug network connections. The first word on the first line gives the status of the connection.
Having announced, a process may accept incoming connections by calling open on the listen file. The open will block until a new connection request arrives; it will then return an open file descriptor that points to the control file of the newly accepted connection. Repeating this procedure will accept all calls for the given protocol.
In general it should not be necessary to use the file system interface to the networks. The dial, announce, and listen functions described in dial(2) perform the necessary I/O to establish and manipulate network connections.
A connection is controlled by writing text strings to the associated ctl file. After a connection has been established data may be read from and written to the data file. The TCP protocol provides a stream connection that does not preserve read/write boundaries.
For outgoing calls the local port number will be allocated randomly if none is set. Addresses are set by writing control messages to the ctl file of the connection. The connection is not established until the data file is opened. For TCP the process will block until the remote host has acknowledged the connection.
As well as the standard control messages above, TCP accepts the following:
The status file has many lines, each containing a labelled number, giving the values of parameters and statistics such as: maximum allowed connections, outgoing calls, incoming calls, established but later reset, active calls, input segments, output segments, retransmitted segments, retransmitted timeouts, input errors, transmitted reset.
UDP opens always succeed. Before sending data, remote and local addresses must be set for the connection. Alternatively, the following special control requests can be used:
A read of less than the size of the datagram will cause the entire datagram to be consumed. Each write to the data file will send a single datagram on the network.
In replies, in connection-oriented mode, if the remote address has not been set, the first arriving packet sets the following based on the source of the incoming datagram: the remote address and port for the conversation, and the local address is set to the destination address in the datagram unless that is a multicast address, and then the address of the receiving interface is used.
If a conversation is in headers mode, only the local port is relevant.
Connection-oriented UDP is hungup if an ICMP error (eg, host or port unreachable, or time exceeded) arrives with matching port.
The udp status file contains four lines, each containing a labelled number counting an event: input datagrams, datagrams on unannounced ports, datagrams with wrong checksum, and output datagrams.
Commands can also be written to control the routing:
The ipselftab file summarises the addresses and routes that refer to the local host. It gives an address, the number of logical interfaces, and the interface type in the same form as the route type of iproute.
The iprouter file is provided for use by a user-level application acting as an IP gateway. It is effective only when the kernel-level gateway is not enabled (see the iprouting interface control request below). Once opened, packets that are not addressed to a local address can be read from this device. The packet contents are preceded by a 16 byte binary header that gives the IPv6 address of the local interface that received the packet.
If any value is unknown (no reply to BOOTP, or value unspecified), the value will be zero, represented as 0.0.0.0.
Opening the clone file returns a file descriptor open on the ctl file for a new connection. A medium is then attached using a bind request; logical interfaces are associated by connect or add; they are removed by remove; and finally unbind detaches the medium from the connection. For certain types of media, the unbind is automatic when the connection itself is closed. With most media, including Ethernet, the ipifc connection files can be closed after configuration, and later reopened if need be to add or remove logical interfaces, or set other parameters.
The ctl file responds to the following text commands, including interface-specific variants of standard IP device requests:
The local file contains one line for each logical interface, of the form:
where local is the local address associated with the interface and each self is a broadcast or multicast address that can address that interface, including subnet addresses, if any.
The status file contains many fields: the first two give the device name and the value of the current MTU, followed by 7 fields per line for each logical interface: local address, address mask, remote address, packets in, packets out, input errors, and output errors.
The following sections describe the media drivers available. Each is separately configurable into a kernel.
The interface opens two conversations on the given Ethernet device, for instance ether0, using an internal version of dial, with the addresses device!0x800 (IPv4) and device!0x806 (ARP). See dial(2) for the interpretation of such addresses. The interface runs until a process does an explicit unbind. Multicast settings made on the interface are propagated to the device.
All parameters except serial are optional. The character `-' can appear as a placeholder for any parameter. Except for authentication data, an attempt is made to negotiate suitable values for any missing parameter values, including network addresses. The parameters are interpreted as follows:
If the name serial contains `!' a connection will be opened using dial (see dial(2)). Otherwise the name will be opened as-is; usually it is the name of a serial device (eg, #t/eia0). In the latter case, a companion ctl file will also be opened if possible, to set serial characteristics for PPP (flow control, 64kbyte queue size, nonblocking writes). An attempt is made to start the PPP link immediately. The write of the bind control message returns with an error if the link cannot be started, or if negotiation fails. The PPP link is automatically unbound if the line hangs up (eg, modem drops carrier), or an unrecoverable error occurs when reading or writing the connection.
The PPP implementation can use either PAP and CHAP authentication, as negotiated, provided an appropriate username and secret is given in the bind request. It does not yet support the Microsoft authentication scheme.
All other interface parameters including its IP address are set using the standard ipifc requests described above. Once that has been done, the application reads the data file of the interface to receive packets addressed to the interface, and it writes to the file to inject packets into the IP network. The interface is automatically unbound when all interface files are closed.
On all other hosted platforms, the IP device gives applications within emu(1) a portable interface to TCP/IP and UDP/IP, even through it is ultimately using the host system's own TCP/IP and UDP/IP implementations (usually but not always socket based). The interface remains the same: for instance by /net/tcp and /net/udp, but is currently more limited in the set of services and control requests. Both IPv4 and IPv6 address syntax may be used, but the IPv6 form must still map to the IPv4 address space if the IPv6 support is not configured into emu. Only TCP and UDP are generally available, and a limited interface to ARP on some platforms (see below). The set of TCP/UDP control requests is limited to: connect, announce, bind, ttl, tos, ignoreadvice, headers4, oldheaders, headers, hangup and keepalive.
The write-only arp file is implemented only on some Unix systems, and is intended to allow the implementation of the BOOTP protocol using Inferno, on hosted systems. It accepts a single textual control request:
An error results if the host system does not allow the ARP map to be set, or the current user lacks the privileges to set it.
| IP(3 ) | Rev: Tue Mar 31 02:42:38 GMT 2015 |