![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to netintro.4 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / share / man / man4|
Return to netintro.4 CVS log | Up to [CSRG BSD Unix] / 43BSDReno / share / man / man4 |
1.1 root 1: .\" Copyright (c) 1983, 1990 The Regents of the University of California.
2: .\" All rights reserved.
3: .\"
4: .\" Redistribution and use in source and binary forms are permitted provided
5: .\" that: (1) source distributions retain this entire copyright notice and
6: .\" comment, and (2) distributions including binaries display the following
7: .\" acknowledgement: ``This product includes software developed by the
8: .\" University of California, Berkeley and its contributors'' in the
9: .\" documentation or other materials provided with the distribution and in
10: .\" all advertising materials mentioning features or use of this software.
11: .\" Neither the name of the University nor the names of its contributors may
12: .\" be used to endorse or promote products derived from this software without
13: .\" specific prior written permission.
14: .\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED
15: .\" WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
16: .\" MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
17: .\"
18: .\" @(#)netintro.4 6.9 (Berkeley) 6/23/90
19: .\"
20: .TH NETINTRO 4 "June 23, 1990"
21: .UC 5
22: .SH NAME
23: networking \- introduction to networking facilities
24: .SH SYNOPSIS
25: .nf
26: .ft B
27: #include <sys/socket.h>
28: #include <net/route.h>
29: #include <net/if.h>
30: .fi R
31: .fi
32: .SH DESCRIPTION
33: .de _d
34: .if t .ta .6i 2.1i 2.6i
35: .\" 2.94 went to 2.6, 3.64 to 3.30
36: .if n .ta .84i 2.6i 3.30i
37: ..
38: .de _f
39: .if t .ta .5i 1.25i 2.5i
40: .\" 3.5i went to 3.8i
41: .if n .ta .7i 1.75i 3.8i
42: ..
43: This section is a general introduction to the networking facilities
44: available in the system.
45: Documentation in this part of section
46: 4 is broken up into three areas:
47: .I "protocol families
48: (domains),
49: .IR protocols ,
50: and
51: .IR "network interfaces" .
52: .\" Entries describing a protocol family are marked ``4F,''
53: .\" while entries describing protocol use are marked ``4P.''
54: .\" Hardware support for network interfaces are found
55: .\" among the standard ``4'' entries.
56: .PP
57: All network protocols are associated with a specific
58: .IR "protocol family" .
59: A protocol family provides basic services to the protocol
60: implementation to allow it to function within a specific
61: network environment. These services may include
62: packet fragmentation and reassembly, routing, addressing, and
63: basic transport. A protocol family may support multiple
64: methods of addressing, though the current protocol implementations
65: do not. A protocol family is normally comprised of a number
66: of protocols, one per
67: .IR socket (2)
68: type. It is not required that a protocol family support
69: all socket types. A protocol family may contain multiple
70: protocols supporting the same socket abstraction.
71: .PP
72: A protocol supports one of the socket abstractions detailed
73: in
74: .IR socket (2).
75: A specific protocol may be accessed either by creating a
76: socket of the appropriate type and protocol family, or
77: by requesting the protocol explicitly when creating a socket.
78: Protocols normally accept only one type of address format,
79: usually determined by the addressing structure inherent in
80: the design of the protocol family/network architecture.
81: Certain semantics of the basic socket abstractions are
82: protocol specific. All protocols are expected to support
83: the basic model for their particular socket type, but may,
84: in addition, provide non-standard facilities or extensions
85: to a mechanism. For example, a protocol supporting the
86: SOCK_STREAM
87: abstraction may allow more than one byte of out-of-band
88: data to be transmitted per out-of-band message.
89: .PP
90: A network interface is similar to a device interface.
91: Network interfaces comprise the lowest layer of the
92: networking subsystem, interacting with the actual transport
93: hardware. An interface may support one or more protocol
94: families and/or address formats.
95: The SYNOPSIS section of each network interface
96: entry gives a sample specification
97: of the related drivers for use in providing
98: a system description to the
99: .IR config (8)
100: program.
101: The DIAGNOSTICS section lists messages which may appear on the console
102: and/or in the system error log,
103: .I /var/log/messages
104: (see
105: .IR syslogd (8)),
106: due to errors in device operation.
107: .SH PROTOCOLS
108: The system currently supports the DARPA Internet
109: protocols, the Xerox Network Systems(tm) protocols,
110: and some of the ISO OSI protocols.
111: Raw socket interfaces are provided to the IP protocol
112: layer of the DARPA Internet, to the IMP link layer (1822), and to
113: the IDP protocol of Xerox NS.
114: Consult the appropriate manual pages in this section for more
115: information regarding the support for each protocol family.
116: .SH ADDRESSING
117: Associated with each protocol family is an address
118: format. All network address adhere to a general structure,
119: called a sockaddr, described below. However, each protocol
120: imposes finer and more specific structure, generally renaming
121: the variant, which is discussed in the protocol family manual
122: page alluded to above.
123: .nf
124: ._f
125: struct sockaddr {
126: u_char sa_len;
127: u_char sa_family;
128: char sa_data[14];
129: };
130: .sp 1
131: .fi
132: The field sa_len contains the total length of the of the structure,
133: which may exceed 16 bytes.
134: The following address values for
135: .I sa_family
136: are known to the system
137: (and additional formats are defined for possible future implementation):
138: .sp 1
139: .nf
140: ._d
141: #define AF_UNIX 1 /* local to host (pipes, portals) */
142: #define AF_INET 2 /* internetwork: UDP, TCP, etc. */
143: #define AF_IMPLINK 3 /* arpanet imp addresses */
144: #define AF_NS 6 /* Xerox NS protocols */
145: #define AF_CCITT 10 /* CCITT protocols, X.25 etc */
146: #define AF_HYLINK 15 /* NSC Hyperchannel */
147: #define AF_ISO 18 /* ISO protocols */
148: .fi
149: .SH ROUTING
150: .PP
151: .UX
152: provides some packet routing facilities.
153: The kernel maintains a routing information database, which
154: is used in selecting the appropriate network interface when
155: transmitting packets.
156: .PP
157: A user process (or possibly multiple co-operating processes)
158: maintains this database by sending messages over a special kind
159: of socket.
160: This supplants fixed size
161: .IR ioctl 's
162: used in earlier releases.
163: .PP
164: This facility is described in
165: .IR route (4).
166: .SH INTERFACES
167: Each network interface in a system corresponds to a
168: path through which messages may be sent and received. A network
169: interface usually has a hardware device associated with it, though
170: certain interfaces such as the loopback interface,
171: .IR lo (4),
172: do not.
173: .PP
174: The following
175: .I ioctl
176: calls may be used to manipulate network interfaces.
177: The
178: .I ioctl
179: is made on a socket (typically of type SOCK_DGRAM)
180: in the desired domain.
181: Most of the requests supported in earlier releases
182: take an
183: .I ifreq
184: structure as its parameter. This structure has the form
185: .PP
186: .nf
187: ._d
188: .DT
189: struct ifreq {
190: #define IFNAMSIZ 16
191: char ifr_name[IFNAMSIZE]; /* if name, e.g. "en0" */
192: union {
193: struct sockaddr ifru_addr;
194: struct sockaddr ifru_dstaddr;
195: struct sockaddr ifru_broadaddr;
196: short ifru_flags;
197: int ifru_metric;
198: caddr_t ifru_data;
199: } ifr_ifru;
200: #define ifr_addr ifr_ifru.ifru_addr /* address */
201: #define ifr_dstaddr ifr_ifru.ifru_dstaddr /* other end of p-to-p link */
202: #define ifr_broadaddr ifr_ifru.ifru_broadaddr /* broadcast address */
203: #define ifr_flags ifr_ifru.ifru_flags /* flags */
204: #define ifr_metric ifr_ifru.ifru_metric /* metric */
205: #define ifr_data ifr_ifru.ifru_data /* for use by interface */
206: };
207: .fi
208: Calls which are now depricated are:
209: .TP
210: SIOCSIFADDR
211: Set interface address for protocol family. Following the address
212: assignment, the ``initialization'' routine for
213: the interface is called.
214: .TP
215: SIOCSIFDSTADDR
216: Set point to point address for protocol family and interface.
217: .TP
218: SIOCSIFBRDADDR
219: Set broadcast address for protocol family and interface.
220: .LP
221: .I Ioctls
222: requests to obtain addresses and requests both to set and
223: retreive other data are still fully supported
224: and use the
225: .I ifreq
226: structure:
227: .TP
228: SIOCGIFADDR
229: Get interface address for protocol family.
230: .TP
231: SIOCGIFDSTADDR
232: Get point to point address for protocol family and interface.
233: .TP
234: SIOCGIFBRDADDR
235: Get broadcast address for protocol family and interface.
236: .TP
237: SIOCSIFFLAGS
238: Set interface flags field. If the interface is marked down,
239: any processes currently routing packets through the interface
240: are notified;
241: some interfaces may be reset so that incoming packets are no longer received.
242: When marked up again, the interface is reinitialized.
243: .TP
244: SIOCGIFFLAGS
245: Get interface flags.
246: .TP
247: SIOCSIFMETRIC
248: Set interface routing metric.
249: The metric is used only by user-level routers.
250: .TP
251: SIOCGIFMETRIC
252: Get interface metric.
253: .LP
254: There are two requests that make use of a new structure:
255: .TP
256: SIOCAIFADDR
257: An interface may have more than one address associated with it
258: in some protocols. This request provides a means to
259: add additional addresses (or modify characteristics of the
260: primary address if the default address for the address family
261: is specified). Rather than making separate calls to
262: set destination or broadcast addresses, or network masks
263: (now an integral feature of multiple protocols)
264: a separate structure is used to specify all three facets simultaneously:
265: .nf
266:
267: .ta \w'struct 'u +\w'struct 'u +\w'sockaddr 'u +\w'ifra_broaddadr 'u
268: struct ifaliasreq {
269: char ifra_name[IFNAMSIZ]; /* if name, e.g. "en0" */
270: struct sockaddr ifra_addr;
271: struct sockaddr ifra_broadaddr;
272: struct sockaddr ifra_mask;
273: };
274: .fi
275: One would use a slightly tailored version of this struct specific
276: to each family (replacing each sockaddr by one
277: of the family-specific type).
278: Where the sockaddr itself is larger than the
279: default size, one needs to modify the
280: .I ioctl
281: identifier itself to include the total size, as described in
282: .IR ioctl (2).
283: .TP
284: SIOCDIFADDR
285: This requests deletes the specified address from the list
286: associated with an interface. It also uses the if_aliasreq
287: structure to allow for the possibility of protocols allowing
288: multiple masks or destination addresses, and also adopts the
289: convention that specification of the default address means
290: to delete the first address for the interface belonging to
291: the address family in which the original socket was opened.
292: .TP
293: SIOCGIFCONF
294: Get interface configuration list. This request takes an
295: .I ifconf
296: structure (see below) as a value-result parameter. The
297: .I ifc_len
298: field should be initially set to the size of the buffer
299: pointed to by
300: .IR ifc_buf .
301: On return it will contain the length, in bytes, of the
302: configuration list.
303: .PP
304: ._d
305: .nf
306: .DT
307: /*
308: * Structure used in SIOCGIFCONF request.
309: * Used to retrieve interface configuration
310: * for machine (useful for programs which
311: * must know all networks accessible).
312: */
313: struct ifconf {
314: int ifc_len; /* size of associated buffer */
315: union {
316: caddr_t ifcu_buf;
317: struct ifreq *ifcu_req;
318: } ifc_ifcu;
319: #define ifc_buf ifc_ifcu.ifcu_buf /* buffer address */
320: #define ifc_req ifc_ifcu.ifcu_req /* array of structures returned */
321: };
322: .fi
323: .SH SEE ALSO
324: socket(2), ioctl(2), intro(4), config(8), routed(8C)
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.