9srv Manual Collection/plan9/ip(3) | 9srv Manual Collection/plan9/ip(3) |
---|
All addresses used are 16-byte IPv6 addresses. IPv4 addresses are a subset of the IPv6 addresses and both standard ASCII formats are accepted. In binary representation, all v4 addresses start with the 12 bytes, in hex:
Opening the clone file reserves an interface. The file descriptor returned from the open(2) will point to the control file, ctl, of the newly allocated interface. Reading ctl returns a text string representing the number of the interface. Writing ctl alters aspects of the interface. The possible ctl messages are those described under Protocol directories below and these:
Reading the interface's status file returns information about the interface, one line for each local address on that interface. The first line has 9 white-space-separated fields: device, mtu, local address, mask, remote or network address, packets in, packets out, input errors, output errors. Each subsequent line contains all but the device and mtu. See readipifc in ip(2).
The tag is an arbitrary, up to 4 character, string. It is normally used to indicate what routing protocol originated the route.
Writing to /net/iproute changes the route table. The messages are:
ARP entries do not time out. The ARP table is a cache with an LRU replacement policy. The IP stack listens for all ARP requests and, if the requester is in the table, the entry is updated. Also, whenever a new address is configured onto an Ethernet, an ARP request is sent to help update the table on other systems.
Currently, the only medium type is
ether.
Writing to /net/log controls debugging. The control messages are:
The file /net/ndb can be read or written by programs. It is normally used by ipconfig(8) to leave configuration information for other programs such as dns and cs (see ndb(8)). /net/ndb may contain up to 1024 bytes.
The file
/net/ipselftab
is a read-only file containing all the IP addresses
considered local. Each line in the file contains
three white-space-separated fields: IP address, usage count,
and flags. The usage count is the number of interfaces to which
the address applies. The flags are the same as for routing
entries.
Note that the `IPv4 route' flag will never be set.
Each protocol is a subdirectory of the IP stack. The top level directory of each protocol contains a clone file, a stats file, and subdirectories numbered from zero to the number of connections opened for this protocol.
Opening the clone file reserves a connection. The file descriptor returned from the open(2) will point to the control file, ctl, of the newly allocated connection. Reading ctl 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 data. A connection can be actively established using the connect message (see also dial(2)). A connection can be established passively by first using an announce message (see dial(2)) to bind to a local port and then opening the listen file (see dial(2)) to receive incoming calls.
The following control messages are supported:
Port numbers must be in the range 1 to 32767.
Several 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. On receiving and error or EOF reading or writing the data file, the err file contains the reason for error.
A process may accept incoming connections by open(2)ing the listen file. The open will block until a new connection request arrives. Then open will return an open file descriptor which points to the control file of the newly accepted connection. This procedure will accept all calls for the given protocol. See dial(2).
By default, a UDP connection is a point-to-point link. Either a connect establishes a local and remote address/port pair or after an announce, each datagram coming from a different remote address/port pair establishes a new incoming connection. However, many-to-one semantics is also possible.
If, after an announce, the message headers is written to ctl, then all messages sent to the announced port are received on the announced connection prefixed with the corresponding structure, declared in <ip.h>:
Before a write, a user must prefix a similar structure to each message. The system overrides the user specified local port with the announced one. If the user specifies an address that isn't a unicast address in /net/ipselftab, that too is overridden. Since the prefixed structure is the same in read and write, it is relatively easy to write a server that responds to client requests by just copying new data into the message body and then writing back the same buffer that was read.
In this case (writing headers to the ctl file), no listen nor accept is needed; otherwise, the usual sequence of announce, listen, accept must be executed before performing I/O on the corresponding data file.
Unlike TCP, the reboot of one end of a connection does not force a closing of the connection. Communications will resume when the rebooted machine resumes talking. Any unacknowledged packets queued before the reboot will be lost. A reboot can be detected by reading the err file. It will contain the message
where address and port are of the far side of the connection. Retransmitting a datagram more than 10 times is treated like a reboot: all queued messages are dropped, an error is queued to the err file, and the conversation resumes.
RUDP ctl files accept the following messages:
In this case (writing headers to the ctl file), no listen nor accept is needed; otherwise, the usual sequence of announce, listen, accept must be executed before performing I/O on the corresponding data file.
Reads and writes transfer a
GRE datagram starting at the GRE header.
On write, the kernel fills in the
eproto
field with the port number specified
in the connect message.
A filter is a semicolon-separated list of relations. Each relation describes a portion of a packet to match. The possible relations are:
Expr is of the form:
If a mask is given, the relevant field is first ANDed with the mask. The result is compared against the value or list of values for a match. In the case of ifc, dst, and src the value is a dot-formatted IP address and the mask is a dot-formatted IP mask. In the case of data, iph and proto, both value and mask are strings of 2 hexadecimal digits representing 8-bit values.
A packet is delivered to only one filter. The filters are merged into a single comparison tree. If two filters match the same packet, the following rules apply in order (here '>' means is preferred to):
So far this has just been used to implement a version of
OSPF in Inferno
and 6to4 tunnelling.
Reading
/net/ipifc/stats
returns a list of 19 tagged and newline-separated fields representing:
Reading
/net/icmp/stats
returns a list of 26 tagged and newline-separated fields representing:
Reading
/net/tcp/stats
returns a list of 11 tagged and newline-separated fields representing:
Reading
/net/udp/stats
returns a list of 4 tagged and newline-separated fields representing:
Reading
/net/gre/stats
returns a list of 1 tagged number representing:
9srv Manual Collection/plan9/ip(3) | Rev: Fri Aug 02 04:59:26 BST 2013 |