Intro(ADMP) 19 June 1992 Intro(ADMP) Name Intro - introduction to special files and protocols Syntax #include <sys/socket.h> #include <netinet/in.h> #include <netinet/ip_str.h> #include <netinet/strioc.h> Description 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(SLIB) type. It is not required that a protocol family support all socket types. A protocol family may contain multiple proto- cols supporting the same socket abstraction. A protocol supports one of the socket abstractions detailed in socket(SLIB). 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 prim- itives, 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 con- tains 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(S) 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 rtflags 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 desti- nation 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 desti- nation 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 (rtrefcnt 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 rtuse 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 (``wild- card'') gateway is chosen. If multiple routes are present in the table, the first route found will be used. If no entry is found, the destina- tion 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 argu- ments 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 speci- fication 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: #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 */ 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 loca- tion 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; } 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, 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 SOCKDGRAM) in the desired ``communications domain'' (see protocols(SFF)). Unless specified otherwise, the request takes an ifrequest structure as its parameter. This structure has the form #define IFNAMSIZ 16 struct ifreq { 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; struct onepacket ifru_onepacket; } 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_onepacket ifr_ifru.ifru_onepacket /* one-packet mode params */ }; 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 pro- cesses 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 ifronepacket field of the ifreq structure is used for this request. This structure is defined as fol- lows: struct onepacket { int spsize; /* small packet size */ int spthresh; /* small packet threshold */ }; One-packet mode is enabled by setting the IFFONEPACKET flag (see SIOCSIFFLAGS above). See tcp(ADMP) for an explanation of one-packet mode. SIOCGIFONEP Get one-packet mode parameters. SIOCGIFCONF Get interface configuration list. This request takes an ifconf struc- ture (see below) as a value-result parameter. The ifclen field should be initially set to the size of the buffer pointed to by ifcbuf. On return it will contain the length, in bytes, of the con- figuration 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 iccmd field containing the socket ioctl code (from <sys/socket.h>) and the icdb 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 icdb 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(SSC) and setsockopt(SSC) using toptmgmt(S). Options are communicated using an options buffer, which contains a list of options. Each option con- sists 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 toptmgmt struc- ture to TCHECK. 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 TCHECK may have failed even if toptmgmt returns zero. The user must check the flags field of the returned toptmgmt structure. If this field contains TFAILURE, one or more of the options were invalid. To set options, set the flags field of the toptmgmt structure to TNEGOTIATE. To retrieve the default values of all options, set the flags field of the toptmgmt structure to TDEFAULT. For this operation, no input buffer should be specified. Notes STREAMS TCP/IP man pages frequently cite appropriateRFCs (Requests for Comments). RFCs can be obtained from the DDN Network Information Center, SRI International, Menlo Park, CA 94025. See also ioctl(S), socket(SSC), toptmgmt(S), tcp(ADMP)