Intro -- introduction to special files and protocols


#include  <sys/socket.h>

#include <netinet/in.h>

#include <net/if.h>

#include <netinet/ip_str.h>

#include <net/strioc.h>


This section describes various special files and protocols that refer to specific 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(SSC) 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(SSC). 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/XTI primitives, or by opening the associated STREAMS device.

Protocol entries

The system currently supports the Internet protocols. Raw socket interfaces are provided to the IP protocol layer of the Internet, to the ICMP protocol, and to the IGMP protocol. Consult ip(ADMP), icmp(ADMP), and igmp(ADMP) for more information.


Associated with each protocol family is an address format. All network addresses adhere to a general structure, called a sockaddr, shown here:
       struct sockaddr {
           u_short sa_family;
           char    sa_data[14];
However, each protocol imposes finer and more specific structure, generally renaming the variant. See the appropriate protocol manual page for more details.

The following address values for sa_family are known to the system:

   #define    AF_INET      2    /* internetwork: UDP, TCP, etc. */
   #define    AF_LINK     18    /* data-link layer (ARP) */
   #define    AF_UNIX      1    /* UNIX domain */


The system provides some packet routing facilities. The kernel maintains a routing information database, which is used in selecting the appropriate network interface when transmitting packets.

A user process (or possibly multiple co-operating processes) maintains this database by sending messages over a special kind of stream. This supplants fixed size ioctl(S) used in earlier releases.

This facility is described in route(ADMP).

Socket ioctls

The ioctl call on a socket has the general form:
The following ioctl command codes have significance for the socket layer only:

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 <sys/protosw.h> header file as:
#define PR_ATOMIC       0x01    /* exchange atomic messages only */
#define PR_ADDR         0x02    /* addresses given with messages */
#define PR_CONNREQUIRED 0x04    /* connection required by protocol */
#define PR_RIGHTS       0x10    /* passes capabilities */
#define PR_BINDPROTO    0x20    /* pass protocol */

Purge the protocol switch table. The arguments used to create the socket used by this ioctl may be zero.

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.

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.

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.

Returns (to the int location pointed to by arg) the number of bytes currently waiting to be read on the socket.

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(S). 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;

iqp_value specifies the value for the queue parameter according to iqp_type, which may be one of: IQP_RQ (read queue), IQP_WQ (write queue), IQP_MUXRQ (mux read queue), IQP_MUXWQ (mux write queue), or IQP_HDRQ (stream head queue), each OR'ed with either IQP_LOWAT (value is for low water mark of queue), or IQP_HIWAT (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, llcloop(ADMP), 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(SFF)). Unless specified otherwise, the request takes an ifreq structure as its parameter. This structure has the form

struct  ifreq {
#define IFNAMSIZ	16
        char    ifr_name[IFNAMSIZ];   /* 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;
                caddr_t ifru_data;
                char    ifru_enaddr[6];
                struct  onepacket ifru_onepacket;
                struct  ifperf ifru_perf;
        } ifr_ifru;
#define ifr_addr		ifr_ifru.ifru_addr		/* address */
#define ifr_dstaddr   	ifr_ifru.ifru_dstaddr	/* other end of p-to-p link */
#define ifr_broadaddr 	ifr_ifru.ifru_broadaddr	/* broadcast address */
#define ifr_flags		ifr_ifru.ifru_flags	/* flags */
#define ifr_metric		ifr_ifru.ifru_metric	/* routing metric */
#define ifr_data		ifr_ifru_ifru_data		/* for use by interface */
#define ifr_enaddr		ifr_ifru_ifru_enaddr	/* ethernet address */
#define ifr_onepacket 	ifr_ifru.ifru_onepacket	/* one-packet mode params */
#define ifr_perf      	ifr_ifru.ifru_onepacket	/* performance tuning */

Set interface address for protocol family. Following the address assignment, the ``initialization'' routine for the interface is called.

Set point to point address for protocol family and interface.

Set broadcast address for protocol family and interface.

Get interface address for protocol family.

Get broadcast address for protocol family and interface.

Get point to point address for protocol family and interface.

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.

Get interface flags.

Set interface routing metric. The metric is used only by user-level routers.

Get interface metric.

Sets the maximum-transmission-unit size of the interface. This value indicates the largest atomic data-unit (including all protocol headers) that can be transmitted via this interface. The ifr_metric field is used to contain the MTU value.

Retrieves the maximum-transmission-unit size associated with the interface. The MTU value is returned in the ifr_metric field.

Retrieves the current debugging level associated with the interface. The level is returned in the ifr_metric field.

Sets the debugging level of the interface. The ifr_metric field is used to contain the MTU value.

Sets the interface type to the value specified in the ifr_metric field. Valid interface types are specified in <sys/net/if_types.h>. This is performed by the system when appropriate and should never normally be issued by an application.

Retrieves the interface type of the specified interface. The value is returned in the ifr_metric field.

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(ADMP) for an explanation of one-packet mode.

Get one-packet mode parameters.

Set performance tuning parameters. The ifr_perf field of the ifreq structure is used for this request. This structure is defined as follows:
struct ifperf {
        u_short     ip_recvspace;      /* recv buffering */
        u_short     ip_sendspace;      /* send buffering */
        u_short     ip_fullsize;       /* use full-size segments */

These values control interface-specific information that TCP will use to determine optimal window and segment sizes. They can be configured on a per-interface basis so that systems with multiple different types of interfaces do not have to be configured in such a way as to penalize faster hardware.

Get performance tuning parameters.

An interface may have more than one address associated with it in the internet protocol. This request provides a means to add additional addresses (or modify characteristics of the primary address if the default address for the address family is specified). Rather than making separate calls to set destination or broadcast addresses, or network masks (now an integral feature of the protocol), a separate structure is used to specify all three facets simultaneously (see below). One would use a slightly tailored version of this struct specific to each family (replacing each sockaddr by one of the family-specific types, for example, sockaddr_in).

This request deletes the specified address from the list associated with an interface. It also uses the if_aliasreq structure to allow for the possibility of protocols allowing multiple masks or destination addresses, and also adopts the convention that specification of the default address means to delete the first address for the interface belonging to the address family in which the original socket was opened.

The following structure is used with SIOCAIFADDR, SIOCGIFALIAS, and SIOCDIFADDR:

struct ifaliasreq {
        char    ifra_name[IFNAMSIZ];   /* if name, e.g. "en0" */
        struct  sockaddr        ifra_addr;
        struct  sockaddr        ifra_broadaddr;
        struct  sockaddr        ifra_mask;

Get interface alias. This request takes an ifaliasreq structure as an argument. The alias about which information is desired is identified by the combination of the ifra_name and ifra_addr fields. For example, to retrieve information about the alias ``'' on interface ``lo0'', ifra_name should contain the string ``lo0'' and ifra_addr should be initialized to a sockaddr_in structure whose sin_addr field contains 0x7f000002 in network-byte order. The remaining fields will be returned by the kernel.

This requests an integer argument as a result-only parameter. The current number of interfaces is returned.

This requests an integer argument as a result-only parameter. The current number of non-multicast interface addresses is returned. This may be greater than the number returned by SIOCGIFNUM if interfaces with aliases (multiple logical addresses) exist. This is useful for sizing buffers to be used with the SIOCGIFCONF ioctl, since that ioctl will return a struct ifreq for every interface address.

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. If the SIOCGIFANUM ioctl is used to size the buffer, the size should be equal to the number returned via the SIOCGIFANUM ioctl multiplied by the size of an ifreq structure. 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 {
        int     ifc_len;             /* size of associated buffer */
        union {
                caddr_t ifcu_buf;
                struct  ifreq *ifcu_req;
        } ifc_ifcu;
#define ifc_buf ifc_ifcu.ifcu_buf    /* buffer address */
#define ifc_req ifc_ifcu.ifcu_req    /* array of structures returned */

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 command code (from <sys/socket.h>) and the ic_dp 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_dp field points to the buffer to receive the ifreq structures. For the SIOCGIFNUM and SIOCGIFANUM ioctls, ic_dp should point to an integer.

In all cases, the ic_len field should be set to the appropriate size.

TLI/XTI options management

Options may be set and retrieved in a manner similar to getsockopt(SSC) and setsockopt(SSC) using t_optmgmt(NET). 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.

Obtaining RFCs

SCO TCP/IP man pages frequently cite appropriate RFCs (Requests for Comments). RFCs can be obtained from InterNIC Information Services in the following ways:

See also

icmp(ADMP), igmp(ADMP), ioctl(S), ip(ADMP), route(ADMP), socket(SSC), t_optmgmt(NET), tcp(ADMP)

RFC 1180, RFC 1500

© 2005 The SCO Group, Inc. All rights reserved.
SCO OpenServer Release 6.0.0 -- 02 June 2005