![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to intro.4n CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Power 6/32 Unix Tahoe 4.2BSD] / cci / usr / src / man / man4|
Return to intro.4n CVS log | Up to [Power 6/32 Unix Tahoe 4.2BSD] / cci / usr / src / man / man4 |
1.1 root 1: .TH INTRO 4N "7 July 1983"
2: .UC 4
3: .SH NAME
4: networking \- introduction to networking facilities
5: .SH SYNOPSIS
6: .nf
7: .ft B
8: #include <sys/socket.h>
9: #include <net/route.h>
10: #include <net/if.h>
11: .fi R
12: .fi
13: .SH DESCRIPTION
14: .de _d
15: .if t .ta .6i 2.1i 2.6i
16: .\" 2.94 went to 2.6, 3.64 to 3.30
17: .if n .ta .84i 2.6i 3.30i
18: ..
19: .de _f
20: .if t .ta .5i 1.25i 2.5i
21: .\" 3.5i went to 3.8i
22: .if n .ta .7i 1.75i 3.8i
23: ..
24: This section briefly describes the networking facilities
25: available in the system.
26: Documentation in this part of section
27: 4 is broken up into three areas:
28: .IR protocol-families ,
29: .IR protocols ,
30: and
31: .IR "network interfaces" .
32: Entries describing a protocol-family are marked ``4F'',
33: while entries describing protocol use are marked ``4P''.
34: Hardware support for network interfaces are found
35: among the standard ``4'' entries.
36: .PP
37: All network protocols are associated with a specific
38: .IR protocol-family .
39: A protocol-family provides basic services to the protocol
40: implementation to allow it to function within a specific
41: network environment. These services may include
42: packet fragmentation and reassembly, routing, addressing, and
43: basic transport. A protocol-family may support multiple
44: methods of addressing, though the current protocol implementations
45: do not. A protocol-family is normally comprised of a number
46: of protocols, one per
47: .IR socket (2)
48: type. It is not required that a protocol-family support
49: all socket types. A protocol-family may contain multiple
50: protocols supporting the same socket abstraction.
51: .PP
52: A protocol supports one of the socket abstractions detailed
53: in
54: .IR socket (2).
55: A specific protocol may be accessed either by creating a
56: socket of the appropriate type and protocol-family, or
57: by requesting the protocol explicitly when creating a socket.
58: Protocols normally accept only one type of address format,
59: usually determined by the addressing structure inherent in
60: the design of the protocol-family/network architecture.
61: Certain semantics of the basic socket abstractions are
62: protocol specific. All protocols are expected to support
63: the basic model for their particular socket type, but may,
64: in addition, provide non-standard facilities or extensions
65: to a mechanism. For example, a protocol supporting the
66: SOCK_STREAM
67: abstraction may allow more than one byte of out-of-band
68: data to be transmitted per out-of-band message.
69: .PP
70: A network interface is similar to a device interface.
71: Network interfaces comprise the lowest layer of the
72: networking subsystem, interacting with the actual transport
73: hardware. An interface may support one or more protocol
74: families, and/or address formats.
75: The SYNOPSIS section of each network interface
76: entry gives a sample specification
77: of the related drivers for use in providing
78: a system description to the
79: .IR config (8)
80: program.
81: The DIAGNOSTICS section lists messages which may appear on the console
82: and in the system error log
83: .I /usr/adm/messages
84: due to errors in device operation.
85: .SH PROTOCOLS
86: The system currently supports only the DARPA Internet
87: protocols fully. Raw socket interfaces are provided to IP protocol
88: layer of the DARPA Internet, to the IMP link layer (1822), and to
89: Xerox PUP-1 layer operating on top of 3Mb/s Ethernet interfaces.
90: Consult the appropriate manual pages in this section for more
91: information regarding the support for each protocol family.
92: .SH ADDRESSING
93: Associated with each protocol family is an address
94: format. The following address formats are used by the system:
95: .sp 1
96: .nf
97: ._d
98: #define AF_UNIX 1 /* local to host (pipes, portals) */
99: #define AF_INET 2 /* internetwork: UDP, TCP, etc. */
100: #define AF_IMPLINK 3 /* arpanet imp addresses */
101: #define AF_PUP 4 /* pup protocols: e.g. BSP */
102: .fi
103: .SH ROUTING
104: The network facilities provided limited packet routing.
105: A simple set of data structures comprise a ``routing table''
106: used in selecting the appropriate network interface when
107: transmitting packets. This table contains a single entry for
108: each route to a specific network or host. A user process,
109: the routing daemon, maintains this data base with the aid
110: of two socket specific
111: .IR ioctl (2)
112: commands, SIOCADDRT and SIOCDELRT. The commands allow
113: the addition and deletion of a single routing
114: table entry, respectively. Routing table manipulations may
115: only be carried out by super-user.
116: .PP
117: A routing table entry has the following form, as defined
118: in
119: .RI < net/route.h >;
120: .sp 1
121: ._f
122: .nf
123: struct rtentry {
124: u_long rt_hash;
125: struct sockaddr rt_dst;
126: struct sockaddr rt_gateway;
127: short rt_flags;
128: short rt_refcnt;
129: u_long rt_use;
130: struct ifnet *rt_ifp;
131: };
132: .sp 1
133: .fi
134: with
135: .I rt_flags
136: defined from,
137: .sp 1
138: .nf
139: ._d
140: #define RTF_UP 0x1 /* route usable */
141: #define RTF_GATEWAY 0x2 /* destination is a gateway */
142: #define RTF_HOST 0x4 /* host entry (net otherwise) */
143: .fi
144: .PP
145: Routing table entries come in three flavors: for a specific
146: host, for all hosts on a specific network, for any destination
147: not matched by entries of the first two types (a wildcard route).
148: When the system
149: is booted, each network interface autoconfigured
150: installs a routing table entry when it wishes to have packets
151: sent through it. Normally the interface specifies the route
152: through it is a ``direct'' connection to the destination host
153: or network. If the route is direct, the transport layer of
154: a protocol family usually requests the packet be sent to the
155: same host specified in the packet. Otherwise, the interface
156: may be requested to address the packet to an entity different
157: from the eventual recipient (i.e. the packet is forwarded).
158: .PP
159: Routing table entries installed by a user process may not specify
160: the hash, reference count, use, or interface fields; these are filled
161: in by the routing routines. If
162: a route is in use when it is deleted
163: .RI ( rt_refcnt
164: is non-zero),
165: the resources associated with it will not
166: be reclaimed until further references to it are released.
167: .PP
168: The routing code returns EEXIST if
169: requested to duplicate an existing entry, ESRCH if
170: requested to delete a non-existant entry,
171: or ENOBUFS if insufficient resources were available
172: to install a new route.
173: .PP
174: User processes read the routing tables through the
175: .I /dev/kmem
176: device.
177: .PP
178: The
179: .I rt_use
180: field contains the number of packets sent along the route.
181: This value is used to select among multiple
182: routes to the same destination. When multiple routes to
183: the same destination exist, the least used route is selected.
184: .PP
185: A wildcard routing entry is specified with a zero
186: destination address value. Wildcard routes are used
187: only when the system fails to find a route to the
188: destination host and network. The combination of wildcard
189: routes and routing redirects can provide an economical
190: mechanism for routing traffic.
191: .SH INTERFACES
192: Each network interface in a system corresponds to a
193: path through which messages may be sent and received. A network
194: interface usually has a hardware device associated with it, though
195: certain interfaces such as the loopback interface,
196: .IR lo (4),
197: do not.
198: .PP
199: At boot time each interface which has underlying hardware support
200: makes itself known to the system during the autoconfiguration
201: process. Once the interface has acquired its address it is
202: expected to install a routing table entry so that messages may
203: be routed through it. Most interfaces require some part of
204: their address specified with an SIOCSIFADDR ioctl before they
205: will allow traffic to flow through them. On interfaces where
206: the network-link layer address mapping is static, only the
207: network number is taken from the ioctl; the remainder is found
208: in a hardware specific manner. On interfaces which provide
209: dynamic network-link layer address mapping facilities (e.g.
210: 10Mb/s Ethernets), the entire address specified in the ioctl
211: is used.
212: .PP
213: The following
214: .I ioctl
215: calls may be used to manipulate network interfaces. Unless
216: specified otherwise, the request takes an
217: .I ifrequest
218: structure as its parameter. This structure has the form
219: .PP
220: .nf
221: .DT
222: struct ifreq {
223: char ifr_name[16]; /* name of interface (e.g. "ec0") */
224: union {
225: struct sockaddr ifru_addr;
226: struct sockaddr ifru_dstaddr;
227: short ifru_flags;
228: } ifr_ifru;
229: #define ifr_addr ifr_ifru.ifru_addr /* address */
230: #define ifr_dstaddr ifr_ifru.ifru_dstaddr /* other end of p-to-p link */
231: #define ifr_flags ifr_ifru.ifru_flags /* flags */
232: };
233: .fi
234: .TP
235: SIOCSIFADDR
236: Set interface address. Following the address
237: assignment, the ``initialization'' routine for
238: the interface is called.
239: .TP
240: SIOCGIFADDR
241: Get interface address.
242: .TP
243: SIOCSIFDSTADDR
244: Set point to point address for interface.
245: .TP
246: SIOCGIFDSTADDR
247: Get point to point address for interface.
248: .TP
249: SIOCSIFFLAGS
250: Set interface flags field. If the interface is marked down,
251: any processes currently routing packets through the interface
252: are notified.
253: .TP
254: SIOCGIFFLAGS
255: Get interface flags.
256: .TP
257: SIOCGIFCONF
258: Get interface configuration list. This request takes an
259: .I ifconf
260: structure (see below) as a value-result parameter. The
261: .I ifc_len
262: field should be initially set to the size of the buffer
263: pointed to by
264: .IR ifc_buf .
265: On return it will contain the length, in bytes, of the
266: configuration list.
267: .PP
268: .nf
269: .DT
270: /*
271: * Structure used in SIOCGIFCONF request.
272: * Used to retrieve interface configuration
273: * for machine (useful for programs which
274: * must know all networks accessible).
275: */
276: struct ifconf {
277: int ifc_len; /* size of associated buffer */
278: union {
279: caddr_t ifcu_buf;
280: struct ifreq *ifcu_req;
281: } ifc_ifcu;
282: #define ifc_buf ifc_ifcu.ifcu_buf /* buffer address */
283: #define ifc_req ifc_ifcu.ifcu_req /* array of structures returned */
284: };
285: .fi
286: .SH SEE ALSO
287: socket(2),
288: ioctl(2),
289: intro(4),
290: config(8),
291: routed(8C)
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.