From owner-svn-doc-head@FreeBSD.ORG Sun Jun 23 22:37:08 2013 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C110BB2A; Sun, 23 Jun 2013 22:37:08 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) by mx1.freebsd.org (Postfix) with ESMTP id B0B3A10AA; Sun, 23 Jun 2013 22:37:08 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id r5NMb80K010381; Sun, 23 Jun 2013 22:37:08 GMT (envelope-from gjb@svn.freebsd.org) Received: (from gjb@localhost) by svn.freebsd.org (8.14.7/8.14.5/Submit) id r5NMb8wI010379; Sun, 23 Jun 2013 22:37:08 GMT (envelope-from gjb@svn.freebsd.org) Message-Id: <201306232237.r5NMb8wI010379@svn.freebsd.org> From: Glen Barber Date: Sun, 23 Jun 2013 22:37:08 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: 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 X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 22:37:08 -0000 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 @@ Synopsis - This chapter will cover a number of advanced networking + This chapter covers a number of advanced networking topics. After reading this chapter, you will know: @@ -27,7 +27,7 @@ - How to make FreeBSD act as a bridge. + How to make &os; act as a bridge. @@ -36,8 +36,9 @@ - How to set up network PXE booting with an NFS root file - system. + How to set up network PXE booting + with an + NFS root file system. @@ -45,16 +46,18 @@ - How to set up IPv6 on a FreeBSD machine. + How to set up IPv6 on a &os; + machine. - How to configure ATM. + How to configure ATM. - How to enable and utilize the features of CARP, the - Common Address Redundancy Protocol in &os; + How to enable and utilize the features of the Common + Address Redundancy Protocol (CARP) in + &os;. @@ -71,13 +74,13 @@ - Know how to configure and install a new FreeBSD kernel + Know how to configure and install a new &os; kernel (). - Know how to install additional third-party - software (). + Know how to install additional third-party software + (). @@ -105,22 +108,21 @@ one to the other. This is called routing. A route is a defined pair of addresses: a destination and a - gateway. The pair indicates that if you are - trying to get to this destination, - communicate through this gateway. There - are three types of destinations: individual hosts, subnets, and + gateway. The pair indicates that when trying + to get to this destination, communicate + through this gateway. There are three + types of destinations: individual hosts, subnets, and default. The default route 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 - links), and Ethernet hardware addresses (MAC - addresses). + links), and Ethernet hardware + (MAC) addresses. An Example - To illustrate different aspects of routing, we will use - the following example from netstat: + This example &man.netstat.1; output illustrates several + aspects of routing: &prompt.user; netstat -r Routing tables @@ -138,9 +140,8 @@ host2.example.com link#1 UC 224 link#1 UC 0 0 default route - The first two lines specify the default route (which we - will cover in the - next section) + The first two lines specify the default route, described + in more detail in , and the localhost route. loopback device @@ -149,66 +150,60 @@ host2.example.com link#1 UC localhost is lo0, 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. + out over the network. Ethernet MAC address - The next thing that stands out are the addresses beginning - with 0:e0:. These are Ethernet - hardware addresses, which are also known as MAC addresses. - FreeBSD will automatically identify any hosts - (test0 in the example) on the local Ethernet - and add a route for that host, directly to it over the - Ethernet interface, ed0. There is - also a timeout (Expire 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. + The addresses beginning with 0:e0: are Ethernet hardware addresses, + also known as MAC addresses. &os; will + automatically identify any hosts, test0 in + the example, on the local Ethernet and add a route for that + host over the Ethernet interface, + ed0. This type of route has a + timeout, seen in the Expire 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 (RIP), which + calculates routes to local hosts based upon a shortest path + determination. subnet - FreeBSD will also add subnet routes for the local subnet - (10.20.30.255 is the broadcast - address for the subnet - 10.20.30, and - example.com is the domain - name associated with that subnet). The designation + &os; will add subnet routes for the local subnet. + 10.20.30.255 is the broadcast + address for the subnet 10.20.30 + and example.com is the + domain name associated with that subnet. The designation link#1 refers to the first Ethernet card in - the machine. You will notice no additional interface is - specified for those. + the machine. + + 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. + + The host1 line refers to the host + by its Ethernet address. Since it is the sending host, &os; + knows to use the loopback interface + (lo0) rather than the Ethernet + interface. - Both of these groups (local network hosts and local - subnets) have their routes automatically configured by a - daemon called routed. If this is - not run, then only routes which are statically defined (i.e., - entered explicitly) will exist. - - The host1 line refers to our host, - which it knows by Ethernet address. Since we are the sending - host, FreeBSD knows to use the loopback interface - (lo0) rather than sending it out over - the Ethernet interface. - - The two host2 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 + The two host2 lines represent aliases + which were created using &man.ifconfig.8;. The => symbol after the - lo0 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 + lo0 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 link#1 line for such routes. - The final line (destination subnet - 224) deals with multicasting, - which will be covered in another section. + The final line (destination subnet 224) deals with + multicasting. Finally, various attributes of each route can be seen in the Flags column. Below is a short table @@ -247,7 +242,7 @@ host2.example.com link#1 UC C 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. @@ -276,25 +271,24 @@ host2.example.com link#1 UC 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. + that it knows how to reach, the system checks to see if it + can connect using that interface. If all known paths fail, the system has one last option: the default route. This route is a special type of gateway route (usually the only one present in the system), and is always marked with a c 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). - - 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. + gateway is set to the system which has a direct connection to + the Internet. - Let us look at an example of default routes. This is a - common configuration: + 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 + (ISP). + + This example is a common configuration for a default + route: @@ -308,14 +302,15 @@ host2.example.com link#1 UC The hosts Local1 and - Local2 are at your site. - Local1 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. + Local2 are on the local network. + Local1 is connected to an + ISP using a + PPP connection. This + PPP server is connected through a local + area network to another gateway computer through an external + interface to the ISP. - The default routes for each of your machines will - be: + The default routes for each machine will be: @@ -343,26 +338,28 @@ host2.example.com link#1 UC - A common question is Why (or how) would we set - the T1-GW to be the default gateway for - Local1, rather than the ISP server it is - connected to?. - - 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 + A common question is Why is + T1-GW configured as the default gateway for + Local1, rather than the + ISP server it is connected + to?. + + Since the PPP interface is using an + address on the ISP's local network for + the local side of the connection, routes for any other + machines on the ISP's local network will + be automatically generated. The system already knows how to reach the T1-GW machine, so there is no - need for the intermediate step of sending traffic to the ISP - server. + need for the intermediate step of sending traffic to the + ISP's server. - It is common to use the address - X.X.X.1 as the gateway address - for your local network. So (using the same example), if your - local class-C address space was - 10.20.30 and your ISP was using - 10.9.9 then the default routes - would be: + It is common to use the address X.X.X.1 as the gateway address for + the local network. So, if the local class C address space is + 10.20.30 and the + ISP is using 10.9.9, the default routes would + be: @@ -387,19 +384,19 @@ host2.example.com link#1 UC The default route can be easily defined in - /etc/rc.conf. In our example, on - the Local2 machine, we added the following - line in /etc/rc.conf: + /etc/rc.conf. In this example, on + Local2, add the following line to + /etc/rc.conf: defaultrouter="10.20.30.1" - It is also possible to do it directly from the command - line with the &man.route.8; command: + It is also possible to add the route directly using + &man.route.8;: &prompt.root; route add default 10.20.30.1 For more information on manual manipulation of network - routing tables, consult the &man.route.8; manual page. + routing tables, refer to &man.route.8;. @@ -407,32 +404,27 @@ host2.example.com link#1 UC dual homed hosts - 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. - - 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. + A a dual-homed system is a host which resides on two + different networks. + + 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. 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. - 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. + For this machine to forward packets between the two + interfaces, &os; must be configured as a router, as + demonstrated in the next section. @@ -440,10 +432,10 @@ host2.example.com link#1 UC router - 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 + 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 YES in &man.rc.conf.5;: @@ -451,23 +443,21 @@ host2.example.com link#1 UC This option will set the &man.sysctl.8; variable net.inet.ip.forwarding to - 1. If you should need to stop routing - temporarily, you can reset this to 0 - temporarily. + 1. To stop routing, reset this to + 0. BGP RIP OSPF - 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 + 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 RIP versions + 1 and 2, and IRDP. Support for + BGPv4, OSPFv2, and other sophisticated routing protocols is available with the - net/zebra package. - Commercial products such as &gated; - are also available for more complex network routing - solutions. + net/zebra package or + port. @@ -486,7 +476,7 @@ host2.example.com link#1 UC Manual Configuration - Let us assume we have a network as follows: + Consider the following network: @@ -520,21 +510,16 @@ host2.example.com link#1 UC - In this scenario, RouterA is our &os; + In this scenario, RouterA is a &os; machine that is acting as a router to the rest of the - Internet. It has a default route set to - 10.0.0.1 which allows it to - connect with the outside world. We will assume that - RouterB 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 - RouterB using - 192.168.1.1 as the - gateway.) + Internet. It has a default route set to 10.0.0.1 which allows it to + connect with the outside world. RouterB is + already configured properly as it uses 192.168.1.1 as the gateway. - If we look at the routing table for - RouterA we would see something like the - following: + The routing table on RouterA looks + something like this: &prompt.user; netstat -nr 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 - With the current routing table RouterA - will not be able to reach our Internal Net 2. It does not - have a route for - 192.168.2.0/24. One way to - alleviate this is to manually add the route. The following - command would add the Internal Net 2 network to - RouterA's routing table using - 192.168.1.2 as the next + With the current routing table, RouterA + cannot reach Internal Net 2 as it does not have a route for + 192.168.2.0/24. The + following command adds the Internal Net 2 network to + RouterA's routing table using 192.168.1.2 as the next hop: &prompt.root; route add -net 192.168.2.0/24 192.168.1.2 @@ -566,39 +549,34 @@ default 10.0.0.1 UG Persistent Configuration - 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 /etc/rc.conf: + 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 + /etc/rc.conf: # Add Internal Net 2 as a static route static_routes="internalnet2" route_internalnet2="-net 192.168.2.0/24 192.168.1.2" The static_routes 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 static_routes. - This string is internalnet2. 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 static_routes, + internalnet2. The variable route_internalnet2 - 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: + contains all of the configuration parameters to + &man.route.8;. This example is equivalent to the + command: &prompt.root; route add -net 192.168.2.0/24 192.168.1.2 - so we need "-net 192.168.2.0/24 - 192.168.1.2". - - As said above, we can have more than one string in - static_routes. This allows us to create - multiple static routes. The following lines shows an - example of adding static routes for the - 192.168.0.0/24 and - 192.168.1.0/24 networks on an - imaginary router: + Using more than one string in + static_routes creates multiple static + routes. The following shows an example of adding static + routes for the 192.168.0.0/24 + and 192.168.1.0/24 + networks: 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. Routing Propagation - routing propagation - We have already talked about how we define our routes to - the outside world, but not about how the outside world finds - us. - - 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. - - 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? - - 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 Backbone 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. - - 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 + 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 ISP? + + 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. + + 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. @@ -646,24 +612,22 @@ route_net2="-net 192.168.1.0/24 192.168. Troubleshooting - traceroute + &man.traceroute.8; - Sometimes, there is a problem with routing propagation, - and some sites are unable to connect to you. Perhaps the most + 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). - - 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. + + 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. - For more information, see the manual page for - &man.traceroute.8;. + For more information, refer to &man.traceroute.8;. @@ -676,19 +640,18 @@ route_net2="-net 192.168.1.0/24 192.168. kernel options MROUTING - 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: + &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: options MROUTING - In addition, the multicast routing daemon, &man.mrouted.8; - must be configured to set up tunnels and - DVMRP via + The multicast routing daemon, &man.mrouted.8;, must be + configured to set up tunnels and DVMRP via /etc/mrouted.conf. More details on - multicast configuration may be found in the manual page for + multicast configuration may be found in &man.mrouted.8;. @@ -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 - net/mrouted. + in the &os; Ports Collection as net/mrouted. @@ -735,83 +698,92 @@ route_net2="-net 192.168.1.0/24 192.168. 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). + 2.3GHz and 4.9GHz ranges. - 802.11 networks are organized in two ways: in - infrastructure mode 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 - ad-hoc network. + 802.11 networks are organized in two ways. In + infrastructure mode, 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 ad-hoc + network. 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. + frequencies and the MAC 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. - Separate from the underlying transmission techniques + 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 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 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 WPA, which was a + precursor to 802.11i. 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 computationally costly to be implemented on legacy - hardware.) + hardware. - 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 + 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 (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 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. + about 802.11e and + WME/WMM is that it + enables prioritized traffic over a wireless network through + Quality of Service (QoS) protocols and + enhanced media access protocols. Proper implementation of + these protocols enables high speed bursting of data and + prioritized traffic flow. - &os; supports networks that operate - using 802.11a, 802.11b, and 802.11g. The WPA and 802.11i + &os; supports networks that operate using 802.11a, + 802.11b, and 802.11g. The WPA 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. + 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. @@ -820,63 +792,59 @@ route_net2="-net 192.168.1.0/24 192.168. Kernel Configuration - 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. - - 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 + 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. + + 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 /boot/loader.conf: if_ath_load="YES" 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.: + 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: if_wi_load="YES" - for devices based on the Intersil Prism parts - (&man.wi.4; driver). - - 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 + 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 Release - Information 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 - NDIS driver + Information 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 NDIS driver wrapper. - 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 + 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 WPA 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 /boot/loader.conf: @@ -884,17 +852,16 @@ route_net2="-net 192.168.1.0/24 192.168. wlan_ccmp_load="YES" wlan_tkip_load="YES" - With this information in the system bootstrap - configuration file (i.e., - /boot/loader.conf), 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 + Once this information has been added to + /boot/loader.conf, reboot the &os; + box. Alternately, load the modules by hand using &man.kldload.8;. - 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: + 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: 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 With this information in the kernel configuration - file, recompile the kernel and reboot your &os; + file, recompile the kernel and reboot the &os; machine. - When the system is up, we could find some information *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***