projects / unix-history / blob
? search:
summary | tags | clone url | shortlog | log | commit | commitdiff | tree
blame | history | raw | HEAD
BSD 4_3_Tahoe development
[unix-history] / usr / man / cat4 / netintro.0
NETINTRO(4) UNIX Programmer's Manual NETINTRO(4)
N\bNA\bAM\bME\bE
networking - introduction to networking facilities
S\bSY\bYN\bNO\bOP\bPS\bSI\bIS\bS
#\b#i\bin\bnc\bcl\blu\bud\bde\be <\b<s\bsy\bys\bs/\b/s\bso\boc\bck\bke\bet\bt.\b.h\bh>\b>
#\b#i\bin\bnc\bcl\blu\bud\bde\be <\b<n\bne\bet\bt/\b/r\bro\bou\but\bte\be.\b.h\bh>\b>
#\b#i\bin\bnc\bcl\blu\bud\bde\be <\b<n\bne\bet\bt/\b/i\bif\bf.\b.h\bh>\b>
D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
This section briefly describes the networking facilities
available in the system. Documentation in this part of sec-
tion 4 is broken up into three areas: _\bp_\br_\bo_\bt_\bo_\bc_\bo_\bl _\bf_\ba_\bm_\bi_\bl_\bi_\be_\bs
(domains), _\bp_\br_\bo_\bt_\bo_\bc_\bo_\bl_\bs, and _\bn_\be_\bt_\bw_\bo_\br_\bk _\bi_\bn_\bt_\be_\br_\bf_\ba_\bc_\be_\bs. Entries
describing a protocol family are marked ``4F,'' while
entries describing protocol use are marked ``4P.'' Hardware
support for network interfaces are found among the standard
``4'' entries.
All network protocols are associated with a specific _\bp_\br_\bo_\bt_\bo_\b-
_\bc_\bo_\bl _\bf_\ba_\bm_\bi_\bl_\by. 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 implemen-
tations do not. A protocol family is normally comprised of
a number of protocols, one per _\bs_\bo_\bc_\bk_\be_\bt(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 _\bs_\bo_\bc_\bk_\be_\bt(2). A specific protocol may be accessed either by
creating a socket of the appropriate type and protocol fam-
ily, or by requesting the protocol explicitly when creating
a socket. Protocols normally accept only one type of
address format, usually determined by the addressing struc-
ture inherent in the design of the protocol family/network
architecture. Certain semantics of the basic socket
abstractions are protocol specific. All protocols are
expected to support the basic model for their particular
socket type, but may, in addition, provide non-standard
facilities or extensions to a mechanism. For example, a
protocol supporting the SOCK_STREAM abstraction may allow
more than one byte of out-of-band data to be transmitted per
out-of-band message.
A network interface is similar to a device interface. Net-
work interfaces comprise the lowest layer of the networking
subsystem, interacting with the actual transport hardware.
An interface may support one or more protocol families
and/or address formats. The SYNOPSIS section of each
Printed 7/9/88 August 1, 1987 1
NETINTRO(4) UNIX Programmer's Manual NETINTRO(4)
network interface entry gives a sample specification of the
related drivers for use in providing a system description to
the _\bc_\bo_\bn_\bf_\bi_\bg(8) program. The DIAGNOSTICS section lists mes-
sages which may appear on the console and/or in the system
error log, /_\bu_\bs_\br/_\ba_\bd_\bm/_\bm_\be_\bs_\bs_\ba_\bg_\be_\bs (see _\bs_\by_\bs_\bl_\bo_\bg_\bd(8)), due to errors
in device operation.
P\bPR\bRO\bOT\bTO\bOC\bCO\bOL\bLS\bS
The system currently supports the DARPA Internet protocols
and the Xerox Network Systems(tm) protocols. Raw socket
interfaces are provided to the IP protocol layer of the
DARPA Internet, to the IMP link layer (1822), and to the IDP
protocol of Xerox NS. Consult the appropriate manual pages
in this section for more information regarding the support
for each protocol family.
A\bAD\bDD\bDR\bRE\bES\bSS\bSI\bIN\bNG\bG
Associated with each protocol family is an address format.
The following address formats are used by the system (and
additional formats are defined for possible future implemen-
tation):
#define AF_UNIX 1 /* local to host (pipes, portals) */
#define AF_INET 2 /* internetwork: UDP, TCP, etc. */
#define AF_IMPLINK 3 /* arpanet imp addresses */
#define AF_PUP 4 /* pup protocols: e.g. BSP */
#define AF_NS 6 /* Xerox NS protocols */
#define AF_HYLINK 15 /* NSC Hyperchannel */
R\bRO\bOU\bUT\bTI\bIN\bNG\bG
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 pro-
cess, the routing daemon, maintains this data base with the
aid of two socket-specific _\bi_\bo_\bc_\bt_\bl(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
<_\bn_\be_\bt/_\br_\bo_\bu_\bt_\be._\bh>;
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;
Printed 7/9/88 August 1, 1987 2
NETINTRO(4) UNIX Programmer's Manual NETINTRO(4)
};
with _\br_\bt__\bf_\bl_\ba_\bg_\bs defined from,
#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 come in three flavors: for a specific
host, for all hosts on a specific network, for any destina-
tion not matched by entries of the first two types (a wild-
card 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 (i.e. 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 (_\br_\bt__\br_\be_\bf_\bc_\bn_\bt is non-zero), the rout-
ing 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 rout-
ing code returns EEXIST if requested to duplicate an exist-
ing entry, ESRCH if requested to delete a non-existent
entry, or ENOBUFS if insufficient resources were available
to install a new route. User processes read the routing
tables through the /_\bd_\be_\bv/_\bk_\bm_\be_\bm device. The _\br_\bt__\bu_\bs_\be field con-
tains 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 destina-
tion 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.
Printed 7/9/88 August 1, 1987 3
NETINTRO(4) UNIX Programmer's Manual NETINTRO(4)
I\bIN\bNT\bTE\bER\bRF\bFA\bAC\bCE\bES\bS
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,
though certain interfaces such as the loopback interface,
_\bl_\bo(4), do not.
The following _\bi_\bo_\bc_\bt_\bl calls may be used to manipulate network
interfaces. The _\bi_\bo_\bc_\bt_\bl is made on a socket (typically of
type SOCK_DGRAM) in the desired domain. Unless specified
otherwise, the request takes an _\bi_\bf_\br_\be_\bq_\bu_\be_\bs_\bt structure as its
parameter. This structure has the form
struct ifreq {
#define IFNAMSIZ 16
char ifr_name[IFNAMSIZE]; /* if name, e.g. "en0" */
union {
struct sockaddr ifru_addr;
struct sockaddr ifru_dstaddr;
struct sockaddr ifru_broadaddr;
short ifru_flags;
int ifru_metric;
caddr_t ifru_data;
} 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 /* metric */
#define ifr_data ifr_ifru.ifru_data /* for use by interface */
};
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 inter-
face.
Printed 7/9/88 August 1, 1987 4
NETINTRO(4) UNIX Programmer's Manual NETINTRO(4)
SIOCGIFBRDADDR
Get broadcast address for protocol family and inter-
face.
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.
SIOCGIFCONF
Get interface configuration list. This request takes
an _\bi_\bf_\bc_\bo_\bn_\bf structure (see below) as a value-result
parameter. The _\bi_\bf_\bc__\bl_\be_\bn field should be initially set
to the size of the buffer pointed to by _\bi_\bf_\bc__\bb_\bu_\bf. 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 */
};
S\bSE\bEE\bE A\bAL\bLS\bSO\bO
socket(2), ioctl(2), intro(4), config(8), routed(8C)
Printed 7/9/88 August 1, 1987 5
Continuous source code history from original PDP-7 UNIX to FreeBSD 2, the first fully unencumbered FreeBSD release.