INTRO(ADMP) UNIX System V
Name
intro - introduction to special files and protocols
#include <sys/socket.h>
#include <netinet/in.h>
#include <netinet/ipstr.h>
#include <netinet/strioc.h>
Description
This section describes various special files and protocols
that refer to specific System V STREAMS TCP/IP networking
protocol drivers. Features common to a set of protocols are
documented as a protocol family.
Protocol Family Entries
A protocol family provides basic services to the protocol
implementation to allow it to function within a specific
network environment. These services may include packet
fragmentation and reassembly, routing, addressing, and basic
transport. A protocol family may support multiple methods
of addressing, though the current protocol implementations
do not. A protocol family is normally comprised of a number
of protocols, one per socket(2) type. It is not required
that a protocol family support all socket types. A protocol
family may contain multiple protocols supporting the same
socket abstraction.
A protocol supports one of the socket abstractions detailed
in socket(2). A specific protocol may be accessed by
creating a socket of the appropriate type and protocol
family, by requesting the protocol explicitly when creating
a socket, by executing the appropriate TLI primitives, or by
opening the associated STREAMS device.
Protocol Entries
The system currently supports the DARPA Internet protocols.
Raw socket interfaces are provided to the IP protocol layer
of the DARPA Internet and to the ICMP protocol. Consult the
appropriate manual pages in this section for more
information.
Routing Ioctls
The network facilities provided limited packet routing. A
simple set of data structures comprise a ``routing table''
used in selecting the appropriate network interface when
transmitting packets. This table contains a single entry
for each route to a specific network or host. A user
process, the routing daemon, maintains this data base with
the aid of two socket-specific ioctl(2) commands, SIOCADDRT
and SIOCDELRT. The commands allow the addition and deletion
of a single routing table entry, respectively. Routing
table manipulations may only be carried out by super-user.
A routing table entry has the following form, as defined in
<net/route.h>:
struct rtentry {
u_long rt_hash;
struct sockaddr rt_dst;
struct sockaddr rt_gateway;
short rt_flags;
short rt_refcnt;
u_long rt_use;
struct ifnet *rt_ifp;
};
with rt_flags defined as follows:
#define RTF_UP 0x1 /* route usable */
#define RTF_GATEWAY 0x2 /* destination is a gateway */
#define RTF_HOST 0x4 /* host entry (net otherwise) */
#define RTF_DYNAMIC 0x10 /* created dynamically
(by redirect) */
Routing table entries are of three general types: those for
a specific host, those for all hosts on a specific network,
and those for any destination not matched by entries of the
first two types (a wildcard route). When the system is
booted and addresses are assigned to the network interfaces,
each protocol family installs a routing table entry for each
interface when it is ready for traffic. Normally the
protocol specifies the route through each interface as a
``direct'' connection to the destination host or network.
If the route is direct, the transport layer of a protocol
family usually requests the packet be sent to the same host
specified in the packet. Otherwise, the interface is
requested to address the packet to the gateway listed in the
routing entry (that is, the packet is forwarded).
Routing table entries installed by a user process may not
specify the hash, reference count, use, or interface fields;
these are filled in by the routing routines. If a route is
in use when it is deleted (rt_refcnt is non-zero), the
routing entry will be marked down and removed from the
routing table, but the resources associated with it will not
be reclaimed until all references to it are released. The
routing code returns EEXIST if requested to duplicate an
existing entry, ESRCH if requested to delete a non-existent
entry, or ENOSR if insufficient resources were available to
install a new route. User processes read the routing tables
through the /dev/kmem device. The rt_use field contains the
number of packets sent along the route.
When routing a packet, the kernel will first attempt to find
a route to the destination host. Failing that, a search is
made for a route to the network of the destination.
Finally, any route to a default (``wildcard'') gateway is
chosen. If multiple routes are present in the table, the
first route found will be used. If no entry is found, the
destination is declared to be unreachable.
A wildcard routing entry is specified with a zero
destination address value. Wildcard routes are used only
when the system fails to find a route to the destination
host and network. The combination of wildcard routes and
routing redirects can provide an economical mechanism for
routing traffic.
Socket Ioctls
There are a few ioctls which have significance for the
socket layer only. The ioctl call has the general form:
ioctl(so, code, arg)
SIOCPROTO
Enter a socket type into the kernel protocol switch
table. The arguments used to create the socket used by
this ioctl may be zero. The new socket type is
downloaded by setting arg to a pointer to a
specification block with the following structure:
struct socknewproto {
int family; /* address family (AF_INET, etc.) */
int type; /* protocol type
(SOCK_STREAM, etc.) */
int proto; /* per family proto number */
dev_t dev; /* major/minor to use
(must be a clone) */
int flags; /* protosw flags */
};
The flags currently supported are specified in the
<net/protosw.h> header file as:
/* exchange atomic messages only */
#define PR_ATOMIC 0x01
/* addresses given with messages */
#define PR_ADDR 0x02
/* connection required by protocol */
#define PR_CONNREQUIRED 0x04
#define PR_RIGHTS 0x10 /* passes capabilities */
#define PR_BINDPROTO 0x20 /* pass protocol */
SIOCXPROTO
Purge the protocol switch table. The arguments used to
create the socket used by this ioctl may be zero.
SIOCSPGRP
Set the process group for a socket to enable signaling
(SIGUSR1) of that process group when out-of-band data
arrives. The argument, arg, is a pointer to an int
and, if positive, is treated as a process ID;
otherwise, (if negative) is treated as a process group
ID.
SIOCGPGRP
Get the process group ID associated with a particular
socket. If the value returned to the int location
pointed to by arg is negative, it should be interpreted
as a process group ID; otherwise, it should be
interpreted as a process ID.
SIOCCATMARK
Used to ascertain whether or not the socket read
pointer is currently at the point (mark) in the data
stream where out-of-band data was sent. If a 1 is
returned to the int location pointed to by arg, the
next read will return data after the mark. Otherwise
(assuming out-of-band data has arrived), the next read
will provide data sent by the client prior to
transmission of the out-of-band signal.
FIONREAD
Returns (to the int location pointed to by arg ) the
number of bytes currently waiting to be read on the
socket.
FIONBIO
Toggles the socket into blocking/non-blocking mode. If
the int location pointed to by arg contains a non-zero
value, subsequent socket operations that would cause
the process to block waiting on a specific event will
return abnormally with errno set to EWOULDBLOCK;
otherwise, the process will block.
Queue Ioctls
Each STREAMS device has default queue high and low water
marks, that can be changed by the super-user with the
INITQPARMS specification in an ioctl(2). The ioctl is done
on a driver or module, with the argument being an array of
structures of type:
struct iocqp {
ushort iqp_type;
ushort iqp_value;
}
iqpvalue specifies the value for the queue parameter
according to iqptype, which may be one of: IQPRQ(read
queue), IQPWQ(write queue), IQPMUXRQ(mux read queue),
IQPMUXWQ(mux write queue), or IQPHDRQ(stream head queue),
each OR'ed with either IQPLOWAT(value is for low water mark
of queue), or IQPHIWAT(value is for high water mark of
queue).
Interface Ioctls
Each network interface in a system corresponds to a path
through which messages may be sent and received. A network
interface usually has a hardware device associated with it,
although certain interfaces such as the loopback interface,
lo(7), do not.
The following ioctl calls may be used to manipulate network
interfaces. The ioctl is made on a socket (typically of
type SOCK_DGRAM ) in the desired "communications domain"
[see protocols(4)]. Unless specified otherwise, the request
takes an ifrequest structure as its parameter. This
structure has the form
struct ifreq {
char ifr_name[16]; /* name of interface (e.g. ec0) */
union {
struct sockaddr ifru_addr;
struct sockaddr ifru_dstaddr;
struct sockaddr ifru_broadaddr;
short ifru_flags;
int ifru_metric;
struct onepacket ifru_onepacket;
} ifr_ifru;
#define ifr_addr ifr_ifru.ifru_addr /* address */
/* other end of p-to-p link */
#define ifr_dstaddr ifr_ifru.ifru_dstaddr
/* broadcast address */
#define ifr_broadaddr ifr_ifru.ifru_broadaddr
#define ifr_flags ifr_ifru.ifru_flags /* flags */
/* routing metric */
#define ifr_metric ifr_ifru.ifru_metric
/* one-packet mode params */
#define ifr_onepacket ifr_ifru.ifru_onepacket
};
SIOCSIFADDR
Set interface address for protocol family. Following
the address assignment, the ``initialization'' routine
for the interface is called.
SIOCGIFADDR
Get interface address for protocol family.
SIOCSIFDSTADDR
Set point to point address for protocol family and
interface.
SIOCGIFDSTADDR
Get point to point address for protocol family and
interface.
SIOCSIFBRDADDR
Set broadcast address for protocol family and
interface.
SIOCGIFBRDADDR
Get broadcast address for protocol family and
interface.
SIOCSIFFLAGS
Set interface flags field. If the interface is marked
down, any processes currently routing packets through
the interface are notified; some interfaces may be
reset so that incoming packets are no longer received.
When marked up again, the interface is reinitialized.
SIOCGIFFLAGS
Get interface flags.
SIOCSIFMETRIC
Set interface routing metric. The metric is used only
by user-level routers.
SIOCGIFMETRIC
Get interface metric.
SIOCSIFONEP
Set one-packet mode parameters. The ifr_onepacket
field of the ifreq structure is used for this request.
This structure is defined as follows:
struct onepacket {
int spsize; /* small packet size */
int spthresh; /* small packet threshold */
};
One-packet mode is enabled by setting the IFF_ONEPACKET flag
(see SIOCSIFFLAGS above). See tcp(7) for an explanation of
one-packet mode.
SIOCGIFONEP
Get one-packet mode parameters.
SIOCGIFCONF
Get interface configuration list. This request takes
an ifconf structure (see below) as a value-result
parameter. The ifc_len field should be initially set
to the size of the buffer pointed to by ifc_buf. On
return it will contain the length, in bytes, of the
configuration list.
/* Structure used in SIOCGIFCONF request.
* Used to retrieve interface configuration
* for machine (useful for programs which
* must know all networks accessible).
*/
struct ifconf {
/* size of associated buffer */
int ifc_len;
union {
caddr_t ifcu_buf;
struct ifreq *ifcu_req;
} ifc_ifcu;
/* buffer address */
#define ifc_buf ifc_ifcu.ifcu_buf
/* array of structures returned */
#define ifc_req ifc_ifcu.ifcu_req
};
Streams Ioctl Interface
Socket ioctl calls can also be issued using STREAMS file
descriptors. The standard strioctl structure is used, with
the ic_cmd field containing the socket ioctl code (from
<sys/socket.h>) and the ic_db field pointing to the data
structure appropriate for that ioctl, for all socket ioctls
except SIOCGIFCONF. For the SIOCGIFCONF ioctl, an ifconf
structure is not used. Rather, the ic_db field points to
the buffer to receive the ifreq structures.
TLI Options Management
Options may be set and retrieved in a manner similar to
getsockopt(2) and setsockopt(2) using t_optmgmt(3N).
Options are communicated using an options buffer, which
contains a list of options. Each option consists of an
option header and an option value. The opthdr structure
gives the format of the option header:
struct opthdr {
long level; /* protocol level affected */
long name; /* option to modify */
long len; /* length of option value (in bytes) */
};
The option value must be a multiple of sizeof(long) bytes in
length, and must immediately follow the option header.
Following the option value is the header of the next option,
if present.
To get the values of options, set the flags field of the
t_optmgmt structure to T_CHECK. It is not necessary to set
the len fields in the option headers to the expected lengths
of the option values, nor is it necessary to provide space
between option headers for the option values to be stored
(the len fields should be set to zero and the option headers
should be adjacent). A new options buffer will be formatted
and returned to the user. Note that T_CHECK may have failed
even if t_optmgmt returns zero. The user must check the
flags field of the returned t_optmgmt structure. If this
field contains T_FAILURE, one or more of the options were
invalid.
To set options, set the flags field of the t_optmgmt
structure to T_NEGOTIATE.
To retrieve the default values of all options, set the flags
field of the t_optmgmt structure to T_DEFAULT. For this
operation, no input buffer should be specified.
Note
System V STREAMS TCP/IP man pages frequently cite
appropriate RFCs (Requests for Comments). RFCs can be
obtained from the DDN Network Information Center, SRI
International, Menlo Park, CA 94025.
See Also
ioctl(SSC), socket(SSC), t_optmgmt(NSL), tcp(ADMP).
(printed 8/17/89) INTRO(ADMP)