svn commit: r42014 - in head/en_US.ISO8859-1/books/handbook: advanced-networking audit basics boot config disks eresources install kernelconfig mac mail multimedia network-servers ports security users

Glen Barber gjb at FreeBSD.org
Sun Jun 23 22:37:08 UTC 2013


Author: gjb
Date: Sun Jun 23 22:37:08 2013
New Revision: 42014
URL: http://svnweb.freebsd.org/changeset/doc/42014

Log:
  MF ISBN:
     Merged /projects/print2013/en_US.ISO8859-1:r40693-40726
     Merged /projects/ISBN_1-57176-407-0/en_US.ISO8859-1:r40727-41455,
  	41457-41469,41472-41477,41479-41513,41515-41521,41523-41577,
  	41579-41581,41583-42013
  
  Notes:  This merge entirely excludes the en_US/books/handbook/ppp-and-slip/
  changes.  They will need to be looked at a bit more closely.
  
  Note to translators:  I am very, very sorry.  There was no *clean* way
  to merge this as separate commits.  Trust me, I tried.
  The revision logs for the ISBN branch should provide some insight to what
  content has changed.  I am more than happy to help out here.  Sorry :(
  
  Approved by:	doceng (implicit)

Modified:
  head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml
  head/en_US.ISO8859-1/books/handbook/audit/chapter.xml
  head/en_US.ISO8859-1/books/handbook/basics/chapter.xml
  head/en_US.ISO8859-1/books/handbook/boot/chapter.xml
  head/en_US.ISO8859-1/books/handbook/config/chapter.xml
  head/en_US.ISO8859-1/books/handbook/disks/chapter.xml
  head/en_US.ISO8859-1/books/handbook/eresources/chapter.xml
  head/en_US.ISO8859-1/books/handbook/install/chapter.xml
  head/en_US.ISO8859-1/books/handbook/kernelconfig/chapter.xml
  head/en_US.ISO8859-1/books/handbook/mac/chapter.xml
  head/en_US.ISO8859-1/books/handbook/mail/chapter.xml
  head/en_US.ISO8859-1/books/handbook/multimedia/chapter.xml
  head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml
  head/en_US.ISO8859-1/books/handbook/ports/chapter.xml
  head/en_US.ISO8859-1/books/handbook/security/chapter.xml
  head/en_US.ISO8859-1/books/handbook/users/chapter.xml
Directory Properties:
  head/en_US.ISO8859-1/   (props changed)

Modified: head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml	Sun Jun 23 21:55:52 2013	(r42013)
+++ head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml	Sun Jun 23 22:37:08 2013	(r42014)
@@ -11,7 +11,7 @@
   <sect1 id="advanced-networking-synopsis">
     <title>Synopsis</title>
 
-    <para>This chapter will cover a number of advanced networking
+    <para>This chapter covers a number of advanced networking
       topics.</para>
 
     <para>After reading this chapter, you will know:</para>
@@ -27,7 +27,7 @@
       </listitem>
 
       <listitem>
-	<para>How to make FreeBSD act as a bridge.</para>
+	<para>How to make &os; act as a bridge.</para>
       </listitem>
 
       <listitem>
@@ -36,8 +36,9 @@
       </listitem>
 
       <listitem>
-	<para>How to set up network PXE booting with an NFS root file
-	  system.</para>
+	<para>How to set up network <acronym>PXE</acronym> booting
+	  with an
+	  <acronym>NFS</acronym> root file system.</para>
       </listitem>
 
       <listitem>
@@ -45,16 +46,18 @@
       </listitem>
 
       <listitem>
-	<para>How to set up IPv6 on a FreeBSD machine.</para>
+	<para>How to set up <acronym>IPv6</acronym> on a &os;
+	  machine.</para>
       </listitem>
 
       <listitem>
-	<para>How to configure ATM.</para>
+	<para>How to configure <acronym>ATM</acronym>.</para>
       </listitem>
 
       <listitem>
-	<para>How to enable and utilize the features of CARP, the
-	  Common Address Redundancy Protocol in &os;</para>
+	<para>How to enable and utilize the features of the Common
+	  Address Redundancy Protocol (<acronym>CARP</acronym>) in
+	  &os;.</para>
       </listitem>
     </itemizedlist>
 
@@ -71,13 +74,13 @@
       </listitem>
 
       <listitem>
-	<para>Know how to configure and install a new FreeBSD kernel
+	<para>Know how to configure and install a new &os; kernel
 	  (<xref linkend="kernelconfig"/>).</para>
       </listitem>
 
       <listitem>
-	<para>Know how to install additional third-party
-	  software (<xref linkend="ports"/>).</para>
+	<para>Know how to install additional third-party software
+	  (<xref linkend="ports"/>).</para>
       </listitem>
 
     </itemizedlist>
@@ -105,22 +108,21 @@
       one to the other.  This is called
       <firstterm>routing</firstterm>.  A <quote>route</quote> is a
       defined pair of addresses: a <quote>destination</quote> and a
-      <quote>gateway</quote>.  The pair indicates that if you are
-      trying to get to this <emphasis>destination</emphasis>,
-      communicate through this <emphasis>gateway</emphasis>.  There
-      are three types of destinations: individual hosts, subnets, and
+      <quote>gateway</quote>.  The pair indicates that when trying
+      to get to this <emphasis>destination</emphasis>, communicate
+      through this <emphasis>gateway</emphasis>.  There are three
+      types of destinations: individual hosts, subnets, and
       <quote>default</quote>.  The <quote>default route</quote> is
-      used if none of the other routes apply.  We will talk a little
-      bit more about default routes later on.  There are also three
+      used if none of the other routes apply.  There are also three
       types of gateways: individual hosts, interfaces (also called
-      <quote>links</quote>), and Ethernet hardware addresses (MAC
-      addresses).</para>
+      <quote>links</quote>), and Ethernet hardware
+      (<acronym>MAC</acronym>) addresses.</para>
 
     <sect2>
       <title>An Example</title>
 
-      <para>To illustrate different aspects of routing, we will use
-	the following example from <command>netstat</command>:</para>
+      <para>This example &man.netstat.1; output illustrates several
+	aspects of routing:</para>
 
       <screen>&prompt.user; <userinput>netstat -r</userinput>
 Routing tables
@@ -138,9 +140,8 @@ host2.example.com link#1             UC 
 224              link#1             UC          0        0</screen>
 
       <indexterm><primary>default route</primary></indexterm>
-      <para>The first two lines specify the default route (which we
-	will cover in the
-	<link linkend="network-routing-default">next section</link>)
+      <para>The first two lines specify the default route, described
+	in more detail in <xref linkend="network-routing-default"/>,
 	and the <hostid>localhost</hostid> route.</para>
 
       <indexterm><primary>loopback device</primary></indexterm>
@@ -149,66 +150,60 @@ host2.example.com link#1             UC 
 	<literal>localhost</literal> is <devicename>lo0</devicename>,
 	also known as the loopback device.  This says to keep all
 	traffic for this destination internal, rather than sending it
-	out over the LAN, since it will only end up back where it
-	started.</para>
+	out over the network.</para>
 
       <indexterm>
 	<primary>Ethernet</primary>
 	<secondary>MAC address</secondary>
       </indexterm>
-      <para>The next thing that stands out are the addresses beginning
-	with <hostid role="mac">0:e0:</hostid>.  These are Ethernet
-	hardware addresses, which are also known as MAC addresses.
-	FreeBSD will automatically identify any hosts
-	(<hostid>test0</hostid> in the example) on the local Ethernet
-	and add a route for that host, directly to it over the
-	Ethernet interface, <devicename>ed0</devicename>.  There is
-	also a timeout (<literal>Expire</literal> column) associated
-	with this type of route, which is used if we fail to hear from
-	the host in a specific amount of time.  When this happens, the
-	route to this host will be automatically deleted.  These hosts
-	are identified using a mechanism known as RIP (Routing
-	Information Protocol), which figures out routes to local hosts
-	based upon a shortest path determination.</para>
+      <para>The addresses beginning with <hostid
+	  role="mac">0:e0:</hostid> are Ethernet hardware addresses,
+	also known as <acronym>MAC</acronym> addresses.  &os; will
+	automatically identify any hosts, <hostid>test0</hostid> in
+	the example, on the local Ethernet and add a route for that
+	host over the Ethernet interface,
+	<devicename>ed0</devicename>.  This type of route has a
+	timeout, seen in the <literal>Expire</literal> column, which
+	is used if the host does not respond in a specific amount of
+	time.  When this happens, the route to this host will be
+	automatically deleted.  These hosts are identified using the
+	Routing Information Protocol (<acronym>RIP</acronym>), which
+	calculates routes to local hosts based upon a shortest path
+	determination.</para>
 
       <indexterm><primary>subnet</primary></indexterm>
 
-      <para>FreeBSD will also add subnet routes for the local subnet
-	(<hostid role="ipaddr">10.20.30.255</hostid> is the broadcast
-	address for the subnet
-	<hostid role="ipaddr">10.20.30</hostid>, and
-	<hostid role="domainname">example.com</hostid> is the domain
-	name associated with that subnet).  The designation
+      <para>&os; will add subnet routes for the local subnet.
+	<hostid role="ipaddr">10.20.30.255</hostid> is the broadcast
+	address for the subnet <hostid role="ipaddr">10.20.30</hostid>
+	and <hostid role="domainname">example.com</hostid> is the
+	domain name associated with that subnet.  The designation
 	<literal>link#1</literal> refers to the first Ethernet card in
-	the machine.  You will notice no additional interface is
-	specified for those.</para>
+	the machine.</para>
+
+      <para>Local network hosts and local subnets have their routes
+	automatically configured by a daemon called &man.routed.8;.
+	If it is not running, only routes which are statically defined
+	by the administrator will exist.</para>
+
+      <para>The <literal>host1</literal> line refers to the host
+	by its Ethernet address.  Since it is the sending host, &os;
+	knows to use the loopback interface
+	(<devicename>lo0</devicename>) rather than the Ethernet
+	interface.</para>
 
-      <para>Both of these groups (local network hosts and local
-	subnets) have their routes automatically configured by a
-	daemon called <application>routed</application>.  If this is
-	not run, then only routes which are statically defined (i.e.,
-	entered explicitly) will exist.</para>
-
-      <para>The <literal>host1</literal> line refers to our host,
-	which it knows by Ethernet address.  Since we are the sending
-	host, FreeBSD knows to use the loopback interface
-	(<devicename>lo0</devicename>) rather than sending it out over
-	the Ethernet interface.</para>
-
-      <para>The two <literal>host2</literal> lines are an example of
-	what happens when we use an &man.ifconfig.8; alias (see the
-	section on Ethernet for reasons why we would do this).  The
+      <para>The two <literal>host2</literal> lines represent aliases
+	which were created using &man.ifconfig.8;.  The
 	<literal>=></literal> symbol after the
-	<devicename>lo0</devicename> interface says that not only are
-	we using the loopback (since this address also refers to the
-	local host), but specifically it is an alias.  Such routes
+	<devicename>lo0</devicename> interface says that an alias
+	has been set in addition to the loopback address.  Such routes
 	only show up on the host that supports the alias; all other
-	hosts on the local network will simply have a
+	hosts on the local network will have a
 	<literal>link#1</literal> line for such routes.</para>
 
-      <para>The final line (destination subnet
-	<hostid role="ipaddr">224</hostid>) deals with multicasting,
-	which will be covered in another section.</para>
+      <para>The final line (destination subnet <hostid
+	  role="ipaddr">224</hostid>) deals with
+	multicasting.</para>
 
       <para>Finally, various attributes of each route can be seen in
 	the <literal>Flags</literal> column.  Below is a short table
@@ -247,7 +242,7 @@ host2.example.com link#1             UC 
 	    <row>
 	      <entry>C</entry>
 	      <entry>Clone: Generates a new route based upon this
-		route for machines we connect to.  This type of route
+		route for machines to connect to.  This type of route
 		is normally used for local networks.</entry>
 	    </row>
 
@@ -276,25 +271,24 @@ host2.example.com link#1             UC 
       <para>When the local system needs to make a connection to a
 	remote host, it checks the routing table to determine if a
 	known path exists.  If the remote host falls into a subnet
-	that we know how to reach (Cloned routes), then the system
-	checks to see if it can connect along that interface.</para>
+	that it knows how to reach, the system checks to see if it
+	can connect using that interface.</para>
 
       <para>If all known paths fail, the system has one last option:
 	the <quote>default</quote> route.  This route is a special
 	type of gateway route (usually the only one present in the
 	system), and is always marked with a <literal>c</literal> in
 	the flags field.  For hosts on a local area network, this
-	gateway is set to whatever machine has a direct connection to
-	the outside world (whether via PPP link, DSL, cable modem, T1,
-	or another network interface).</para>
-
-      <para>If you are configuring the default route for a machine
-	which itself is functioning as the gateway to the outside
-	world, then the default route will be the gateway machine at
-	your Internet Service Provider's (ISP) site.</para>
+	gateway is set to the system which has a direct connection to
+	the Internet.</para>
 
-      <para>Let us look at an example of default routes.  This is a
-	common configuration:</para>
+      <para>The default route for a machine which itself is
+	functioning as the gateway to the outside world, will be the
+	gateway machine at the Internet Service Provider
+	(<acronym>ISP</acronym>).</para>
+
+      <para>This example is a common configuration for a default
+	route:</para>
 
       <mediaobject>
 	<imageobject>
@@ -308,14 +302,15 @@ host2.example.com link#1             UC 
       </mediaobject>
 
       <para>The hosts <hostid>Local1</hostid> and
-	<hostid>Local2</hostid> are at your site.
-	<hostid>Local1</hostid> is connected to an ISP via a dial up
-	PPP connection.  This PPP server computer is connected through
-	a local area network to another gateway computer through an
-	external interface to the ISPs Internet feed.</para>
+	<hostid>Local2</hostid> are on the local network.
+	<hostid>Local1</hostid> is connected to an
+	<acronym>ISP</acronym> using a
+	<acronym>PPP</acronym> connection.  This
+	<acronym>PPP</acronym> server is connected through a local
+	area network to another gateway computer through an external
+	interface to the <acronym>ISP</acronym>.</para>
 
-      <para>The default routes for each of your machines will
-	be:</para>
+      <para>The default routes for each machine will be:</para>
 
       <informaltable frame="none" pgwide="1">
 	<tgroup cols="3">
@@ -343,26 +338,28 @@ host2.example.com link#1             UC 
 	</tgroup>
       </informaltable>
 
-      <para>A common question is <quote>Why (or how) would we set
-	  the <hostid>T1-GW</hostid> to be the default gateway for
-	  <hostid>Local1</hostid>, rather than the ISP server it is
-	  connected to?</quote>.</para>
-
-      <para>Remember, since the PPP interface is using an address on
-	the ISP's local network for your side of the connection,
-	routes for any other machines on the ISP's local network will
-	be automatically generated.  Hence, you will already know how
+      <para>A common question is <quote>Why is
+	  <hostid>T1-GW</hostid> configured as the default gateway for
+	  <hostid>Local1</hostid>, rather than the
+	  <acronym>ISP</acronym> server it is connected
+	  to?</quote>.</para>
+
+      <para>Since the <acronym>PPP</acronym> interface is using an
+	address on the <acronym>ISP</acronym>'s local network for
+	the local side of the connection, routes for any other
+	machines on the <acronym>ISP</acronym>'s local network will
+	be automatically generated.  The system already knows how
 	to reach the <hostid>T1-GW</hostid> machine, so there is no
-	need for the intermediate step of sending traffic to the ISP
-	server.</para>
+	need for the intermediate step of sending traffic to the
+	<acronym>ISP</acronym>'s server.</para>
 
-      <para>It is common to use the address
-	<hostid role="ipaddr">X.X.X.1</hostid> as the gateway address
-	for your local network.  So (using the same example), if your
-	local class-C address space was
-	<hostid role="ipaddr">10.20.30</hostid> and your ISP was using
-	<hostid role="ipaddr">10.9.9</hostid> then the default routes
-	would be:</para>
+      <para>It is common to use the address <hostid
+	  role="ipaddr">X.X.X.1</hostid> as the gateway address for
+	the local network.  So, if the local class C address space is
+	<hostid role="ipaddr">10.20.30</hostid> and the
+	<acronym>ISP</acronym> is using <hostid
+	  role="ipaddr">10.9.9</hostid>, the default routes would
+	be:</para>
 
       <informaltable frame="none" pgwide="1">
 	<tgroup cols="2">
@@ -387,19 +384,19 @@ host2.example.com link#1             UC 
       </informaltable>
 
       <para>The default route can be easily defined in
-	<filename>/etc/rc.conf</filename>.  In our example, on
-	the <hostid>Local2</hostid> machine, we added the following
-	line in <filename>/etc/rc.conf</filename>:</para>
+	<filename>/etc/rc.conf</filename>.  In this example, on
+	<hostid>Local2</hostid>, add the following line to
+	<filename>/etc/rc.conf</filename>:</para>
 
       <programlisting>defaultrouter="10.20.30.1"</programlisting>
 
-      <para>It is also possible to do it directly from the command
-	line with the &man.route.8; command:</para>
+      <para>It is also possible to add the route directly using
+	&man.route.8;:</para>
 
       <screen>&prompt.root; <userinput>route add default 10.20.30.1</userinput></screen>
 
       <para>For more information on manual manipulation of network
-	routing tables, consult the &man.route.8; manual page.</para>
+	routing tables, refer to &man.route.8;.</para>
     </sect2>
 
     <sect2 id="network-dual-homed-hosts">
@@ -407,32 +404,27 @@ host2.example.com link#1             UC 
 
       <indexterm><primary>dual homed hosts</primary></indexterm>
 
-      <para>There is one other type of configuration that we should
-	cover, and that is a host that sits on two different networks.
-	Technically, any machine functioning as a gateway (in the
-	example above, using a PPP connection) counts as a dual-homed
-	host.  But the term is really only used to refer to a machine
-	that sits on two local-area networks.</para>
-
-      <para>In one case, the machine has two Ethernet cards, each
-	having an address on the separate subnets.  Alternately, the
-	machine may only have one Ethernet card, and be using
-	&man.ifconfig.8; aliasing.  The former is used if two
-	physically separate Ethernet networks are in use, the latter
-	if there is one physical network segment, but two logically
-	separate subnets.</para>
+      <para>A a dual-homed system is a host which resides on two
+	different networks.</para>
+
+      <para>The dual-homed machine might have two Ethernet cards, each
+	having an address on a separate subnet.  Alternately, the
+	machine can have one Ethernet card and uses &man.ifconfig.8;
+	aliasing.  The former is used if two physically separate
+	Ethernet networks are in use and the latter if there is one
+	physical network segment, but two logically separate
+	subnets.</para>
 
       <para>Either way, routing tables are set up so that each subnet
 	knows that this machine is the defined gateway (inbound route)
 	to the other subnet.  This configuration, with the machine
-	acting as a router between the two subnets, is often used when
-	we need to implement packet filtering or firewall security in
+	acting as a router between the two subnets, is often used
+	to implement packet filtering or firewall security in
 	either or both directions.</para>
 
-      <para>If you want this machine to actually forward packets
-	between the two interfaces, you need to tell FreeBSD to enable
-	this ability.  See the next section for more details on how
-	to do this.</para>
+      <para>For this machine to forward packets between the two
+	interfaces, &os; must be configured as a router, as
+	demonstrated in the next section.</para>
     </sect2>
 
     <sect2 id="network-dedicated-router">
@@ -440,10 +432,10 @@ host2.example.com link#1             UC 
 
       <indexterm><primary>router</primary></indexterm>
 
-      <para>A network router is simply a system that forwards packets
-	from one interface to another.  Internet standards and good
-	engineering practice prevent the FreeBSD Project from enabling
-	this by default in FreeBSD.  You can enable this feature by
+      <para>A network router is a system that forwards packets from
+	one interface to another.  Internet standards and good
+	engineering practice prevent the &os; Project from enabling
+	this by default in &os;.  This feature can be enabled by
 	changing the following variable to <literal>YES</literal> in
 	&man.rc.conf.5;:</para>
 
@@ -451,23 +443,21 @@ host2.example.com link#1             UC 
 
       <para>This option will set the &man.sysctl.8; variable
 	<varname>net.inet.ip.forwarding</varname> to
-	<literal>1</literal>.  If you should need to stop routing
-	temporarily, you can reset this to <literal>0</literal>
-	temporarily.</para>
+	<literal>1</literal>.  To stop routing, reset this to
+	<literal>0</literal>.</para>
 
       <indexterm><primary>BGP</primary></indexterm>
       <indexterm><primary>RIP</primary></indexterm>
       <indexterm><primary>OSPF</primary></indexterm>
-      <para>Your new router will need routes to know where to send the
-	traffic.  If your network is simple enough you can use static
-	routes.  FreeBSD also comes with the standard BSD routing
-	daemon &man.routed.8;, which speaks RIP (both version 1 and
-	version 2) and IRDP.  Support for BGP v4, OSPF v2, and other
+      <para>The new router will need routes to know where to send the
+	traffic.  If the network is simple enough, static routes can
+	be used.  &os; comes with the standard BSD routing daemon
+	&man.routed.8;, which speaks <acronym>RIP</acronym> versions
+	1 and 2, and <acronym>IRDP</acronym>.  Support for
+	<acronym>BGP</acronym>v4, <acronym>OSPF</acronym>v2, and other
 	sophisticated routing protocols is available with the
-	<filename role="package">net/zebra</filename> package.
-	Commercial products such as <application>&gated;</application>
-	are also available for more complex network routing
-	solutions.</para>
+	<filename role="package">net/zebra</filename> package or
+	port.</para>
     </sect2>
 
     <sect2 id="network-static-routes">
@@ -486,7 +476,7 @@ host2.example.com link#1             UC 
       <sect3>
 	<title>Manual Configuration</title>
 
-	<para>Let us assume we have a network as follows:</para>
+	<para>Consider the following network:</para>
 
 	<mediaobject>
 	  <imageobject>
@@ -520,21 +510,16 @@ host2.example.com link#1             UC 
 	  </textobject>
 	</mediaobject>
 
-	<para>In this scenario, <hostid>RouterA</hostid> is our &os;
+	<para>In this scenario, <hostid>RouterA</hostid> is a &os;
 	  machine that is acting as a router to the rest of the
-	  Internet.  It has a default route set to
-	  <hostid role="ipaddr">10.0.0.1</hostid> which allows it to
-	  connect with the outside world.  We will assume that
-	  <hostid>RouterB</hostid> is already configured properly and
-	  knows how to get wherever it needs to go.  (This is simple
-	  in this picture.  Just add a default route on
-	  <hostid>RouterB</hostid> using
-	  <hostid role="ipaddr">192.168.1.1</hostid> as the
-	  gateway.)</para>
+	  Internet.  It has a default route set to <hostid
+	    role="ipaddr">10.0.0.1</hostid> which allows it to
+	  connect with the outside world.  <hostid>RouterB</hostid> is
+	  already configured properly as it uses <hostid
+	    role="ipaddr">192.168.1.1</hostid> as the gateway.</para>
 
-	<para>If we look at the routing table for
-	  <hostid>RouterA</hostid> we would see something like the
-	  following:</para>
+	<para>The routing table on <hostid>RouterA</hostid> looks
+	  something like this:</para>
 
 	<screen>&prompt.user; <userinput>netstat -nr</userinput>
 Routing tables
@@ -546,14 +531,12 @@ default            10.0.0.1           UG
 10.0.0.0/24        link#1             UC          0        0    xl0
 192.168.1.0/24     link#2             UC          0        0    xl1</screen>
 
-	<para>With the current routing table  <hostid>RouterA</hostid>
-	  will not be able to reach our Internal Net 2.  It does not
-	  have a route for
-	  <hostid role="ipaddr">192.168.2.0/24</hostid>.  One way to
-	  alleviate this is to manually add the route.  The following
-	  command would add the Internal Net 2 network to
-	  <hostid>RouterA</hostid>'s routing table using
-	  <hostid role="ipaddr">192.168.1.2</hostid> as the next
+	<para>With the current routing table, <hostid>RouterA</hostid>
+	  cannot reach Internal Net 2 as it does not have a route for
+	  <hostid role="ipaddr">192.168.2.0/24</hostid>.  The
+	  following command adds the Internal Net 2 network to
+	  <hostid>RouterA</hostid>'s routing table using <hostid
+	    role="ipaddr">192.168.1.2</hostid> as the next
 	  hop:</para>
 
 	<screen>&prompt.root; <userinput>route add -net 192.168.2.0/24 192.168.1.2</userinput></screen>
@@ -566,39 +549,34 @@ default            10.0.0.1           UG
       <sect3>
 	<title>Persistent Configuration</title>
 
-	<para>The above example is perfect for configuring a static
-	  route on a running system.  However, one problem is that the
-	  routing information will not persist if you reboot your &os;
-	  machine.  Additional static routes can be
-	  entered in <filename>/etc/rc.conf</filename>:</para>
+	<para>The above example configures a static route on a
+	  running system.  However, the routing information will not
+	  persist if the &os; system reboots.  Persistent static
+	  routes can be entered in
+	  <filename>/etc/rc.conf</filename>:</para>
 
 	<programlisting># Add Internal Net 2 as a static route
 static_routes="internalnet2"
 route_internalnet2="-net 192.168.2.0/24 192.168.1.2"</programlisting>
 
 	<para>The <literal>static_routes</literal> configuration
-	  variable is a list of strings separated by a space.  Each
-	  string references to a route name.  In our above example we
-	  only have one string in <literal>static_routes</literal>.
-	  This string is <replaceable>internalnet2</replaceable>.  We
-	  then add a configuration variable called
+	  variable is a list of strings separated by a space, where
+	  each string references a route name.  This example only
+	  has one string in <literal>static_routes</literal>,
+	  <replaceable>internalnet2</replaceable>.  The variable
 	  <literal>route_<replaceable>internalnet2</replaceable></literal>
-	  where we put all of the configuration parameters we would
-	  give to the &man.route.8; command.  For our example above we
-	  would have used the command:</para>
+	  contains all of the configuration parameters to
+	  &man.route.8;.  This example is equivalent to the
+	  command:</para>
 
 	  <screen>&prompt.root; <userinput>route add -net 192.168.2.0/24 192.168.1.2</userinput></screen>
 
-	<para>so we need <literal>"-net 192.168.2.0/24
-	    192.168.1.2"</literal>.</para>
-
-	<para>As said above, we can have more than one string in
-	  <literal>static_routes</literal>.  This allows us to create
-	  multiple static routes.  The following lines shows an
-	  example of adding static routes for the
-	  <hostid role="ipaddr">192.168.0.0/24</hostid> and
-	  <hostid role="ipaddr">192.168.1.0/24</hostid> networks on an
-	  imaginary router:</para>
+	<para>Using more than one string in
+	  <literal>static_routes</literal> creates multiple static
+	  routes.  The following shows an example of adding static
+	  routes for the <hostid role="ipaddr">192.168.0.0/24</hostid>
+	  and <hostid role="ipaddr">192.168.1.0/24</hostid>
+	  networks:</para>
 
 	<programlisting>static_routes="net1 net2"
 route_net1="-net 192.168.0.0/24 192.168.0.1"
@@ -609,36 +587,24 @@ route_net2="-net 192.168.1.0/24 192.168.
     <sect2 id="network-routing-propagation">
       <title>Routing Propagation</title>
 
-      <indexterm><primary>routing propagation</primary></indexterm>
-      <para>We have already talked about how we define our routes to
-	the outside world, but not about how the outside world finds
-	us.</para>
-
-      <para>We already know that routing tables can be set up so that
-	all traffic for a particular address space (in our examples, a
-	class-C subnet) can be sent to a particular host on that
-	network, which will forward the packets inbound.</para>
-
-      <para>When you get an address space assigned to your site, your
-	service provider will set up their routing tables so that all
-	traffic for your subnet will be sent down your PPP link to
-	your site.  But how do sites across the country know to send
-	to your ISP?</para>
-
-      <para>There is a system (much like the distributed DNS
-	information) that keeps track of all assigned address-spaces,
-	and defines their point of connection to the Internet
-	Backbone.  The <quote>Backbone</quote> are the main trunk
-	lines that carry Internet traffic across the country, and
-	around the world.  Each backbone machine has a copy of a
-	master set of tables, which direct traffic for a particular
-	network to a specific backbone carrier, and from there down
-	the chain of service providers until it reaches your
-	network.</para>
-
-      <para>It is the task of your service provider to advertise to
-	the backbone sites that they are the point of connection (and
-	thus the path inward) for your site.  This is known as route
+      <para>When an address space is assigned to a network, the
+	service provider configures their routing tables so that all
+	traffic for the network will be sent to the link for the
+	site.  But how do external sites know to send their packets
+	to the network's <acronym>ISP</acronym>?</para>
+
+      <para>There is a system that keeps track of all assigned
+	address spaces and defines their point of connection to the
+	Internet backbone, or the main trunk lines that carry Internet
+	traffic across the country and around the world.  Each
+	backbone machine has a copy of a master set of tables, which
+	direct traffic for a particular network to a specific
+	backbone carrier, and from there down the chain of service
+	providers until it reaches your network.</para>
+
+      <para>It is the task of the service provider to advertise to
+	the backbone sites that they are the point of connection, and
+	thus the path inward, for a site.  This is known as route
 	propagation.</para>
     </sect2>
 
@@ -646,24 +612,22 @@ route_net2="-net 192.168.1.0/24 192.168.
       <title>Troubleshooting</title>
 
       <indexterm>
-	<primary><command>traceroute</command></primary>
+	<primary>&man.traceroute.8;</primary>
       </indexterm>
 
-      <para>Sometimes, there is a problem with routing propagation,
-	and some sites are unable to connect to you.  Perhaps the most
+      <para>Sometimes, there is a problem with routing propagation
+	and some sites are unable to connect.  Perhaps the most
 	useful command for trying to figure out where routing is
-	breaking down is the &man.traceroute.8; command.  It is
-	equally useful if you cannot seem to make a connection to a
-	remote machine (i.e., &man.ping.8; fails).</para>
-
-      <para>The &man.traceroute.8; command is run with the name of the
-	remote host you are trying to connect to.  It will show the
-	gateway hosts along the path of the attempt, eventually either
+	breaking down is &man.traceroute.8;.  It is useful when
+	&man.ping.8; fails.</para>
+
+      <para>When using &man.traceroute.8;, include the name of the
+	remote host to connect to.  The output will show the gateway
+	hosts along the path of the attempt, eventually either
 	reaching the target host, or terminating because of a lack of
 	connection.</para>
 
-      <para>For more information, see the manual page for
-	&man.traceroute.8;.</para>
+      <para>For more information, refer to &man.traceroute.8;.</para>
     </sect2>
 
     <sect2 id="network-routing-multicast">
@@ -676,19 +640,18 @@ route_net2="-net 192.168.1.0/24 192.168.
 	<primary>kernel options</primary>
 	<secondary>MROUTING</secondary>
       </indexterm>
-      <para>FreeBSD supports both multicast applications and multicast
-	routing natively.  Multicast applications do not require any
-	special configuration of FreeBSD; applications will generally
-	run out of the box.  Multicast routing
-	requires that support be compiled into the kernel:</para>
+      <para>&os; natively supports both multicast applications and
+	multicast routing.  Multicast applications do not require any
+	special configuration of &os;; as applications will generally
+	run out of the box.  Multicast routing requires that support
+	be compiled into a custom kernel:</para>
 
       <programlisting>options MROUTING</programlisting>
 
-      <para>In addition, the multicast routing daemon, &man.mrouted.8;
-	must be configured to set up tunnels and
-	<acronym>DVMRP</acronym> via
+      <para>The multicast routing daemon, &man.mrouted.8;, must be
+	configured to set up tunnels and <acronym>DVMRP</acronym> via
 	<filename>/etc/mrouted.conf</filename>.  More details on
-	multicast configuration may be found in the manual page for
+	multicast configuration may be found in
 	&man.mrouted.8;.</para>
 
       <note>
@@ -697,8 +660,8 @@ route_net2="-net 192.168.1.0/24 192.168.
 	  which has largely been replaced by &man.pim.4; in many
 	  multicast installations.  &man.mrouted.8; and the related
 	  &man.map-mbone.8; and &man.mrinfo.8; utilities are available
-	  in the &os; Ports Collection as
-	  <filename role="package">net/mrouted</filename>.</para>
+	  in the &os; Ports Collection as <filename
+	    role="package">net/mrouted</filename>.</para>
       </note>
     </sect2>
   </sect1>
@@ -735,83 +698,92 @@ route_net2="-net 192.168.1.0/24 192.168.
       <para>Most wireless networks are based on the &ieee; 802.11
 	standards.  A basic wireless network consists of multiple
 	stations communicating with radios that broadcast in either
-	the 2.4GHz or 5GHz band (though this varies according to the
+	the 2.4GHz or 5GHz band, though this varies according to the
 	locale and is also changing to enable communication in the
-	2.3GHz and 4.9GHz ranges).</para>
+	2.3GHz and 4.9GHz ranges.</para>
 
-      <para>802.11 networks are organized in two ways: in
-	<emphasis>infrastructure mode</emphasis> one station acts as a
-	master with all the other stations associating to it; the
-	network is known as a BSS and the master station is termed an
-	access point (AP).  In a BSS all communication passes through
-	the AP; even when one station wants to communicate with
-	another wireless station messages must go through the AP.  In
-	the second form of network there is no master and stations
-	communicate directly.  This form of network is termed an IBSS
-	and is commonly known as an
-	<emphasis>ad-hoc network</emphasis>.</para>
+      <para>802.11 networks are organized in two ways.  In
+	<emphasis>infrastructure mode</emphasis>, one station acts as
+	a
+	master with all the other stations associating to it, the
+	network is known as a <acronym>BSS</acronym>, and the master
+	station is termed an access point (<acronym>AP</acronym>).
+	In a <acronym>BSS</acronym>, all communication passes through
+	the <acronym>AP</acronym>; even when one station wants to
+	communicate with another wireless station, messages must go
+	through the <acronym>AP</acronym>.  In the second form of
+	network, there is no master and stations communicate directly.
+	This form of network is termed an <acronym>IBSS</acronym>
+	and is commonly known as an <emphasis>ad-hoc
+	  network</emphasis>.</para>
 
       <para>802.11 networks were first deployed in the 2.4GHz band
 	using protocols defined by the &ieee; 802.11 and 802.11b
 	standard.  These specifications include the operating
-	frequencies, MAC layer characteristics including framing and
-	transmission rates (communication can be done at various
-	rates).  Later the 802.11a standard defined operation in the
-	5GHz band, including different signalling mechanisms and
-	higher transmission rates.  Still later the 802.11g standard
-	was defined to enable use of 802.11a signalling and
-	transmission mechanisms in the 2.4GHz band in such a way as to
-	be backwards compatible with 802.11b networks.</para>
+	frequencies and the <acronym>MAC</acronym> layer
+	characteristics, including framing and transmission rates,
+	as communication can occur at various rates.  Later, the
+	802.11a standard defined operation in the 5GHz band, including
+	different signaling mechanisms and higher transmission rates.
+	Still later, the 802.11g standard defined the use of 802.11a
+	signaling and transmission mechanisms in the 2.4GHz band in
+	such a way as to be backwards compatible with 802.11b
+	networks.</para>
 
-      <para>Separate from the underlying transmission techniques
+      <para>Separate from the underlying transmission techniques,
 	802.11 networks have a variety of security mechanisms.  The
 	original 802.11 specifications defined a simple security
-	protocol called WEP. This protocol uses a fixed pre-shared key
-	and the RC4 cryptographic cipher to encode data transmitted on
-	a network.  Stations must all agree on the fixed key in order
-	to communicate.  This scheme was shown to be easily broken and
-	is now rarely used except to discourage transient users from
-	joining networks.  Current security practice is given by the
-	&ieee; 802.11i specification that defines new cryptographic
-	ciphers and an additional protocol to authenticate stations to
-	an access point and exchange keys for doing data
-	communication.  Further, cryptographic keys are periodically
-	refreshed and there are mechanisms for detecting intrusion
-	attempts (and for countering intrusion attempts).  Another
+	protocol called <acronym>WEP</acronym>.  This protocol uses a
+	fixed pre-shared key and the RC4 cryptographic cipher to
+	encode data transmitted on a network.  Stations must all
+	agree on the fixed key in order to communicate.  This scheme
+	was shown to be easily broken and is now rarely used except
+	to discourage transient users from joining networks.  Current
+	security practice is given by the &ieee; 802.11i specification
+	that defines new cryptographic ciphers and an additional
+	protocol to authenticate stations to an access point and
+	exchange keys for data communication.  Cryptographic keys
+	are periodically refreshed and there are mechanisms for
+	detecting and countering intrusion attempts.  Another
 	security protocol specification commonly used in wireless
-	networks is termed WPA.  This was a precursor to 802.11i
-	defined by an industry group as an interim measure while
-	waiting for 802.11i to be ratified.  WPA specifies a subset of
-	the requirements found in 802.11i and is designed for
-	implementation on legacy hardware.  Specifically WPA requires
-	only the TKIP cipher that is derived from the original WEP
-	cipher.  802.11i permits use of TKIP but also requires support
-	for a stronger cipher, AES-CCM, for encrypting data.  (The AES
-	cipher was not required in WPA because it was deemed too
+	networks is termed <acronym>WPA</acronym>, which was a
+	precursor to 802.11i.  <acronym>WPA</acronym> specifies a
+	subset of the requirements found in 802.11i and is designed
+	for implementation on legacy hardware.  Specifically,
+	<acronym>WPA</acronym> requires only the
+	<acronym>TKIP</acronym> cipher that is derived from the
+	original <acronym>WEP</acronym> cipher.  802.11i permits use
+	of <acronym>TKIP</acronym> but also requires support for a
+	stronger cipher, AES-CCM, for encrypting data.  The
+	<acronym>AES</acronym> cipher was not required in
+	<acronym>WPA</acronym> because it was deemed too
 	computationally costly to be implemented on legacy
-	hardware.)</para>
+	hardware.</para>
 
-      <para>Other than the above protocol standards the other
-	important standard to be aware of is 802.11e.  This defines
-	protocols for deploying multi-media applications such as
-	streaming video and voice over IP (VoIP) in an 802.11 network.
-	Like 802.11i, 802.11e also has a precursor specification
-	termed WME (later renamed WMM) that has been defined by an
+      <para>The other standard to be aware of is 802.11e.  It defines
+	protocols for deploying multimedia applications, such as
+	streaming video and voice over IP (<acronym>VoIP</acronym>),
+	in an 802.11 network.  Like 802.11i, 802.11e also has a
+	precursor specification termed <acronym>WME</acronym> (later
+	renamed <acronym>WMM</acronym>) that has been defined by an
 	industry group as a subset of 802.11e that can be deployed now
-	to enable multi-media applications while waiting for the final
+	to enable multimedia applications while waiting for the final
 	ratification of 802.11e.  The most important thing to know
-	about 802.11e and WME/WMM is that it enables prioritized
-	traffic use of a wireless network through Quality of Service
-	(QoS) protocols and enhanced media access protocols.  Proper
-	implementation of these protocols enable high speed bursting
-	of data and prioritized traffic flow.</para>
+	about 802.11e and
+	<acronym>WME</acronym>/<acronym>WMM</acronym> is that it
+	enables prioritized traffic over a wireless network through
+	Quality of Service (<acronym>QoS</acronym>) protocols and
+	enhanced media access protocols.  Proper implementation of
+	these protocols enables high speed bursting of data and
+	prioritized traffic flow.</para>
 
-      <para>&os; supports networks that operate
-	using 802.11a, 802.11b, and 802.11g.  The WPA and 802.11i
+      <para>&os; supports networks that operate using 802.11a,
+	802.11b, and 802.11g.  The <acronym>WPA</acronym> and 802.11i
 	security protocols are likewise supported (in conjunction with
-	any of 11a, 11b, and 11g) and QoS and traffic prioritization
-	required by the WME/WMM protocols are supported for a limited
-	set of wireless devices.</para>
+	any of 11a, 11b, and 11g) and <acronym>QoS</acronym> and
+	traffic prioritization required by the
+	<acronym>WME</acronym>/<acronym>WMM</acronym> protocols are
+	supported for a limited set of wireless devices.</para>
     </sect2>
 
     <sect2 id="network-wireless-basic">
@@ -820,63 +792,59 @@ route_net2="-net 192.168.1.0/24 192.168.
       <sect3>
 	<title>Kernel Configuration</title>
 
-	<para>To use wireless networking, you need a wireless
-	  networking card and to configure the kernel with the
-	  appropriate wireless networking support.  The latter is
-	  separated into multiple modules so that you only need to
-	  configure the software you are actually going to use.</para>
-
-	<para>The first thing you need is a wireless device.  The most
-	  commonly used devices are those that use parts made by
-	  Atheros.  These devices are supported by the &man.ath.4;
-	  driver and require the following line to be added to
+	<para>To use wireless networking, a wireless networking card
+	  is needed and the kernel needs to be configured with the
+	  appropriate wireless networking support.  The kernel is
+	  separated into multiple modules so that only the required
+	  support needs to be configured.</para>
+
+	<para>The most
+	  commonly used wireless devices are those that use parts made
+	  by Atheros.  These devices are supported by &man.ath.4;
+	  and require the following line to be added to
 	  <filename>/boot/loader.conf</filename>:</para>
 
 	<programlisting>if_ath_load="YES"</programlisting>
 
 	<para>The Atheros driver is split up into three separate
-	  pieces: the proper driver (&man.ath.4;), the hardware
-	  support layer that handles chip-specific functions
-	  (&man.ath.hal.4;), and an algorithm for selecting which of
-	  several possible rates for transmitting frames
-	  (ath_rate_sample here).  When this support is loaded as
-	  kernel modules, these dependencies are automatically handled
-	  for you.  If, instead of an Atheros device, you had another
-	  device you would select the module for that device;
-	  e.g.:</para>
+	  pieces: the driver (&man.ath.4;), the hardware support
+	  layer that handles chip-specific functions
+	  (&man.ath.hal.4;), and an algorithm for selecting the
+	  rate for transmitting frames.  When this support is loaded
+	  as kernel modules, any dependencies are automatically
+	  handled.  To load support for a different type of wireless
+	  device, specify the module for that device.  This example
+	  is for devices based on the Intersil Prism parts
+	  (&man.wi.4;) driver:</para>
 
 	<programlisting>if_wi_load="YES"</programlisting>
 
-	<para>for devices based on the Intersil Prism parts
-	  (&man.wi.4; driver).</para>
-
 	<note>
-	  <para>In the rest of this document, we will use an
-	    &man.ath.4; device, the device name in the examples must
-	    be changed according to your configuration.  A list of
+	  <para>The examples in this section use an &man.ath.4;
+	    device and the device name in the examples must be
+	    changed according to the configuration.  A list of
 	    available wireless drivers and supported adapters can be
-	    found in the &os; Hardware Notes.  Copies of these notes
-	    for various releases and architectures are available on
+	    found in the &os; Hardware Notes, available on
 	    the <ulink
 	      url="http://www.FreeBSD.org/releases/index.html">Release
-	      Information</ulink> page of the &os; Web site.  If a
-	    native &os; driver for your wireless device does not
-	    exist, it may be possible to directly use the &windows;
-	    driver with the help of the
-	    <link linkend="config-network-ndis">NDIS</link> driver
+	      Information</ulink> page of the &os; website.  If a
+	    native &os; driver for the wireless device does not
+	    exist, it may be possible to use the &windows; driver
+	    with the help of the <link
+	      linkend="config-network-ndis">NDIS</link> driver
 	    wrapper.</para>
 	</note>
 
-	<para>With that, you will need the modules that implement
-	  cryptographic support for the security protocols you intend
-	  to use.  These are intended to be dynamically loaded on
-	  demand by the &man.wlan.4; module but for now they must be
-	  manually configured.  The following modules are available:
-	  &man.wlan.wep.4;, &man.wlan.ccmp.4; and &man.wlan.tkip.4;.
-	  Both &man.wlan.ccmp.4; and &man.wlan.tkip.4; drivers are
-	  only needed if you intend to use the WPA and/or 802.11i
-	  security protocols.  If your network does not use
-	  encryption, you will not need &man.wlan.wep.4; support.  To
+	<para>In addition, the modules that implement cryptographic
+	  support for the security protocols to use must be loaded.
+	  These are intended to be dynamically loaded on demand by
+	  the &man.wlan.4; module, but for now they must be manually
+	  configured.  The following modules are available:
+	  &man.wlan.wep.4;, &man.wlan.ccmp.4;, and &man.wlan.tkip.4;.
+	  The &man.wlan.ccmp.4; and &man.wlan.tkip.4; drivers are
+	  only needed when using the <acronym>WPA</acronym> or
+	  802.11i security protocols.  If the network does not use
+	  encryption, &man.wlan.wep.4; support is not needed.  To
 	  load these modules at boot time, add the following lines to
 	  <filename>/boot/loader.conf</filename>:</para>
 
@@ -884,17 +852,16 @@ route_net2="-net 192.168.1.0/24 192.168.
 wlan_ccmp_load="YES"
 wlan_tkip_load="YES"</programlisting>
 
-	<para>With this information in the system bootstrap
-	  configuration file (i.e.,
-	  <filename>/boot/loader.conf</filename>), you have to reboot
-	  your &os; box.  If you do not want to reboot your machine
-	  for the moment, you can load the modules by hand using
+	<para>Once this information has been added to
+	  <filename>/boot/loader.conf</filename>, reboot the &os;
+	  box.  Alternately, load the modules by hand using
 	  &man.kldload.8;.</para>
 
 	<note>
-	  <para>If you do not want to use modules, it is possible to
-	    compile these drivers into the kernel by adding the
-	    following lines to your kernel configuration file:</para>
+	  <para>For users who do not want to use modules, it is
+	    possible to compile these drivers into the kernel by
+	    adding the following lines to a custom kernel
+	    configuration file:</para>
 
 	  <programlisting>device wlan              # 802.11 support
 device wlan_wep          # 802.11 WEP support
@@ -907,13 +874,12 @@ options AH_SUPPORT_AR5416 # enable AR541
 device ath_rate_sample   # SampleRate tx rate control for ath</programlisting>
 
 	  <para>With this information in the kernel configuration
-	    file, recompile the kernel and reboot your &os;
+	    file, recompile the kernel and reboot the &os;
 	    machine.</para>
 	</note>
 
-	<para>When the system is up, we could find some information

*** DIFF OUTPUT TRUNCATED AT 1000 LINES ***


More information about the svn-doc-all mailing list