diff --git a/en_US.ISO8859-1/books/handbook/Makefile b/en_US.ISO8859-1/books/handbook/Makefile
index b0dca1956f..067b62a88e 100644
--- a/en_US.ISO8859-1/books/handbook/Makefile
+++ b/en_US.ISO8859-1/books/handbook/Makefile
@@ -1,257 +1,258 @@
#
# $FreeBSD$
#
# Build the FreeBSD Handbook.
#
# ------------------------------------------------------------------------
#
# Handbook-specific variables
#
# WITH_PGPKEYS The print version of the handbook only prints PGP
# fingerprints by default. If you would like for the
# entire key to be displayed, then set this variable.
# This option has no affect on the HTML formats.
#
# Handbook-specific targets
#
# pgpkeyring This target will read the contents of
# pgpkeys/chapter.sgml and will extract all of
# the pgpkeys to standard out. This output can then
# be redirected into a file and distributed as a
# public keyring of FreeBSD developers that can
# easily be imported into PGP/GPG.
#
# ------------------------------------------------------------------------
.PATH: ${.CURDIR}/../../share/sgml/glossary
MAINTAINER= doc@FreeBSD.org
DOC?= book
FORMATS?= html-split
HAS_INDEX= true
INSTALL_COMPRESSED?= gz
INSTALL_ONLY_COMPRESSED?=
IMAGES_EN = advanced-networking/isdn-bus.eps
IMAGES_EN+= advanced-networking/isdn-twisted-pair.eps
IMAGES_EN+= advanced-networking/natd.eps
IMAGES_EN+= advanced-networking/net-routing.pic
IMAGES_EN+= advanced-networking/static-routes.pic
IMAGES_EN+= install/adduser1.scr
IMAGES_EN+= install/adduser2.scr
IMAGES_EN+= install/adduser3.scr
IMAGES_EN+= install/boot-mgr.scr
IMAGES_EN+= install/console-saver1.scr
IMAGES_EN+= install/console-saver2.scr
IMAGES_EN+= install/console-saver3.scr
IMAGES_EN+= install/console-saver4.scr
IMAGES_EN+= install/desktop.scr
IMAGES_EN+= install/disklabel-auto.scr
IMAGES_EN+= install/disklabel-ed1.scr
IMAGES_EN+= install/disklabel-ed2.scr
IMAGES_EN+= install/disklabel-fs.scr
IMAGES_EN+= install/disklabel-root1.scr
IMAGES_EN+= install/disklabel-root2.scr
IMAGES_EN+= install/disklabel-root3.scr
IMAGES_EN+= install/disk-layout.eps
IMAGES_EN+= install/dist-set.scr
IMAGES_EN+= install/dist-set2.scr
IMAGES_EN+= install/docmenu1.scr
IMAGES_EN+= install/ed0-conf.scr
IMAGES_EN+= install/ed0-conf2.scr
IMAGES_EN+= install/edit-inetd-conf.scr
IMAGES_EN+= install/fdisk-drive1.scr
IMAGES_EN+= install/fdisk-drive2.scr
IMAGES_EN+= install/fdisk-edit1.scr
IMAGES_EN+= install/fdisk-edit2.scr
IMAGES_EN+= install/ftp-anon1.scr
IMAGES_EN+= install/ftp-anon2.scr
IMAGES_EN+= install/hdwrconf.scr
IMAGES_EN+= install/keymap.scr
IMAGES_EN+= install/main1.scr
IMAGES_EN+= install/mainexit.scr
IMAGES_EN+= install/main-std.scr
IMAGES_EN+= install/main-options.scr
IMAGES_EN+= install/main-doc.scr
IMAGES_EN+= install/main-keymap.scr
IMAGES_EN+= install/media.scr
IMAGES_EN+= install/mouse1.scr
IMAGES_EN+= install/mouse2.scr
IMAGES_EN+= install/mouse3.scr
IMAGES_EN+= install/mouse4.scr
IMAGES_EN+= install/mouse5.scr
IMAGES_EN+= install/mouse6.scr
IMAGES_EN+= install/mta-main.scr
IMAGES_EN+= install/net-config-menu1.scr
IMAGES_EN+= install/net-config-menu2.scr
IMAGES_EN+= install/nfs-server-edit.scr
IMAGES_EN+= install/ntp-config.scr
IMAGES_EN+= install/options.scr
IMAGES_EN+= install/pkg-cat.scr
IMAGES_EN+= install/pkg-confirm.scr
IMAGES_EN+= install/pkg-install.scr
IMAGES_EN+= install/pkg-sel.scr
IMAGES_EN+= install/probstart.scr
IMAGES_EN+= install/routed.scr
IMAGES_EN+= install/security.scr
IMAGES_EN+= install/sysinstall-exit.scr
IMAGES_EN+= install/timezone1.scr
IMAGES_EN+= install/timezone2.scr
IMAGES_EN+= install/timezone3.scr
IMAGES_EN+= install/userconfig.scr
IMAGES_EN+= install/userconfig2.scr
IMAGES_EN+= install/xf86setup.scr
IMAGES_EN+= mail/mutt1.scr
IMAGES_EN+= mail/mutt2.scr
IMAGES_EN+= mail/mutt3.scr
IMAGES_EN+= mail/pine1.scr
IMAGES_EN+= mail/pine2.scr
IMAGES_EN+= mail/pine3.scr
IMAGES_EN+= mail/pine4.scr
IMAGES_EN+= mail/pine5.scr
IMAGES_EN+= install/example-dir1.eps
IMAGES_EN+= install/example-dir2.eps
IMAGES_EN+= install/example-dir3.eps
IMAGES_EN+= install/example-dir4.eps
IMAGES_EN+= install/example-dir5.eps
IMAGES_EN+= security/ipsec-network.pic
IMAGES_EN+= security/ipsec-crypt-pkt.pic
IMAGES_EN+= security/ipsec-encap-pkt.pic
IMAGES_EN+= security/ipsec-out-pkt.pic
IMAGES_EN+= vinum/vinum-concat.pic
IMAGES_EN+= vinum/vinum-mirrored-vol.pic
IMAGES_EN+= vinum/vinum-raid10-vol.pic
IMAGES_EN+= vinum/vinum-raid5-org.pic
IMAGES_EN+= vinum/vinum-simple-vol.pic
IMAGES_EN+= vinum/vinum-striped-vol.pic
IMAGES_EN+= vinum/vinum-striped.pic
# Images from the cross-document image library
IMAGES_LIB= callouts/1.png
IMAGES_LIB+= callouts/2.png
IMAGES_LIB+= callouts/3.png
IMAGES_LIB+= callouts/4.png
IMAGES_LIB+= callouts/5.png
IMAGES_LIB+= callouts/6.png
IMAGES_LIB+= callouts/7.png
IMAGES_LIB+= callouts/8.png
IMAGES_LIB+= callouts/9.png
IMAGES_LIB+= callouts/10.png
#
# SRCS lists the individual SGML files that make up the document. Changes
# to any of these files will force a rebuild
#
# SGML content
+SRCS+= audit/chapter.sgml
SRCS+= book.sgml
SRCS+= colophon.sgml
SRCS+= freebsd-glossary.sgml
SRCS+= advanced-networking/chapter.sgml
SRCS+= basics/chapter.sgml
SRCS+= bibliography/chapter.sgml
SRCS+= boot/chapter.sgml
SRCS+= config/chapter.sgml
SRCS+= cutting-edge/chapter.sgml
SRCS+= desktop/chapter.sgml
SRCS+= disks/chapter.sgml
SRCS+= eresources/chapter.sgml
SRCS+= firewalls/chapter.sgml
SRCS+= install/chapter.sgml
SRCS+= introduction/chapter.sgml
SRCS+= kernelconfig/chapter.sgml
SRCS+= l10n/chapter.sgml
SRCS+= linuxemu/chapter.sgml
SRCS+= mac/chapter.sgml
SRCS+= mail/chapter.sgml
SRCS+= mirrors/chapter.sgml
SRCS+= multimedia/chapter.sgml
SRCS+= network-servers/chapter.sgml
SRCS+= pgpkeys/chapter.sgml
SRCS+= ports/chapter.sgml
SRCS+= ppp-and-slip/chapter.sgml
SRCS+= preface/preface.sgml
SRCS+= printing/chapter.sgml
SRCS+= security/chapter.sgml
SRCS+= serialcomms/chapter.sgml
SRCS+= users/chapter.sgml
SRCS+= vinum/chapter.sgml
SRCS+= x11/chapter.sgml
# Entities
SRCS+= chapters.ent
SYMLINKS= ${DESTDIR} index.html handbook.html
# Turn on all the chapters.
CHAPTERS?= ${SRCS:M*chapter.sgml}
SGMLFLAGS+= ${CHAPTERS:S/\/chapter.sgml//:S/^/-i chap./}
SGMLFLAGS+= -i chap.freebsd-glossary
# XXX The Handbook build currently overflows some internal, hardcoded
# limits in pdftex. Until we split the Handbook up, build the PDF
# version using ps2pdf instead of pdftex.
PS2PDF?= ${PREFIX}/bin/ps2pdf
book.tex-pdf:
${TOUCH} book.tex-pdf
book.pdf: book.ps
${PS2PDF} book.ps book.pdf
pgpkeyring: pgpkeys/chapter.sgml
@${JADE} -V nochunks ${OTHERFLAGS} ${JADEOPTS} -d ${DSLPGP} -t sgml ${MASTERDOC}
#
# Handbook-specific variables
#
.if defined(WITH_PGPKEYS)
JADEFLAGS+= -V withpgpkeys
.endif
.for p in ftp cvsup
SRCS+= mirrors.sgml.${p}.inc
CLEANFILES+= mirrors.sgml.${p}.inc
CLEANFILES+= mirrors.sgml.${p}.inc.tmp
.endfor
SRCS+= eresources.sgml.www.inc
CLEANFILES+= eresources.sgml.www.inc
CLEANFILES+= eresources.sgml.www.inc.tmp
URL_RELPREFIX?= ../../../..
DOC_PREFIX?= ${.CURDIR}/../../..
.include "${DOC_PREFIX}/share/mk/doc.project.mk"
.for p in ftp cvsup
mirrors.sgml.${p}.inc: ${XML_MIRRORS} ${XSL_MIRRORS}
${XSLTPROC} ${XSLTPROCOPTS} \
-o $@.tmp \
--param 'type' "'$p'" \
--param 'proto' "'$p'" \
--param 'target' "'handbook/mirrors/chapter.sgml'" \
${XSL_MIRRORS} ${XML_MIRRORS}
${SED} -e 's,<\([^ >]*\)\([^>]*\)/>,<\1\2>\1>,;s,,,'\
< $@.tmp > $@ || (${RM} -f $@ && false)
${RM} -f $@.tmp
.endfor
eresources.sgml.www.inc: ${XML_MIRRORS} ${XSL_MIRRORS}
${XSLTPROC} ${XSLTPROCOPTS} \
-o $@.tmp \
--param 'type' "'www'" \
--param 'proto' "'http'" \
--param 'target' "'handbook/eresources/chapter.sgml'" \
${XSL_MIRRORS} ${XML_MIRRORS}
${SED} -e 's,<\([^ >]*\)\([^>]*\)/>,<\1\2>\1>,;s,,,'\
< $@.tmp > $@ || (${RM} -f $@ && false)
${RM} -f $@.tmp
diff --git a/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml b/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml
index a79a5b9cb6..359c37dd2d 100644
--- a/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml
+++ b/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml
@@ -1,4205 +1,4205 @@
Advanced NetworkingSynopsisThis chapter will cover a number of advanced networking
topics.After reading this chapter, you will know:The basics of gateways and routes.How to set up IEEE 802.11 and &bluetooth; devices.How to make FreeBSD act as a bridge.How to set up network booting on a diskless machine.How to set up network address translation.How to connect two computers via PLIP.How to set up IPv6 on a FreeBSD machine.How to configure ATM under &os; 5.X.Before reading this chapter, you should:Understand the basics of the /etc/rc scripts.Be familiar with basic network terminology.Know how to configure and install a new FreeBSD kernel
().Know how to install additional third-party
software ().CoranthGryphonContributed by Gateways and RoutesroutinggatewaysubnetFor one machine to be able to find another over a network,
there must be a mechanism in place to describe how to get from
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
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
types of gateways: individual hosts, interfaces (also called
links), and Ethernet hardware addresses (MAC
addresses).
An ExampleTo illustrate different aspects of routing, we will use the
following example from netstat:&prompt.user; netstat -r
Routing tables
Destination Gateway Flags Refs Use Netif Expire
default outside-gw UGSc 37 418 ppp0
localhost localhost UH 0 181 lo0
test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77
10.20.30.255 link#1 UHLW 1 2421
example.com link#1 UC 0 0
host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0
host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 =>
host2.example.com link#1 UC 0 0
224 link#1 UC 0 0default routeThe first two lines specify the default route (which we
will cover in the next
section) and the localhost route.loopback deviceThe interface (Netif column) that this
routing table specifies to use for
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.EthernetMAC addressThe 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.subnetFreeBSD 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 link#1 refers
to the first Ethernet card in the machine. You will notice no
additional interface is specified for those.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
=> 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
only show up on the host that supports the alias; all other
hosts on the local network will simply have a
link#1 line for such routes.The final line (destination subnet 224) deals
with multicasting, which will be covered in another section.Finally, various attributes of each route can be seen in
the Flags column. Below is a short table
of some of these flags and their meanings:UUp: The route is active.HHost: The route destination is a single host.GGateway: Send anything for this destination on to this
remote system, which will figure out from there where to send
it.SStatic: This route was configured manually, not
automatically generated by the system.CClone: Generates a new route based upon this route for
machines we connect to. This type of route is normally used
for local networks.WWasCloned: Indicated a route that was auto-configured
based upon a local area network (Clone) route.LLink: Route involves references to Ethernet
hardware.Default Routesdefault routeWhen 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.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.Let us look at an example of default routes. This is a common
configuration:
[Local2] <--ether--> [Local1] <--PPP--> [ISP-Serv] <--ether--> [T1-GW]
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.The default routes for each of your machines will be:HostDefault GatewayInterfaceLocal2Local1EthernetLocal1T1-GWPPPA 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 to reach the T1-GW
machine, so there is no need for the intermediate step
of sending traffic to the ISP 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:HostDefault RouteLocal2 (10.20.30.2)Local1 (10.20.30.1)Local1 (10.20.30.1, 10.9.9.30)T1-GW (10.9.9.1)You can easily define the default route via the
/etc/rc.conf file. In our example, on the
Local2 machine, we added the following line
in /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:&prompt.root; route add default 10.20.30.1For more information on manual manipulation of network
routing tables, consult &man.route.8; manual page.Dual Homed Hostsdual homed hostsThere 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.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 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.Building a RouterrouterA 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
changing the following variable to YES in
&man.rc.conf.5;:gateway_enable=YES # Set to YES if this host will be a gatewayThis 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.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
sophisticated routing protocols is available with the
net/zebra package.
Commercial products such as &gated; are also available for more
complex network routing solutions.BGPRIPOSPFAlHoangContributed by Setting Up Static RoutesManual ConfigurationLet us assume we have a network as follows:
INTERNET
| (10.0.0.1/24) Default Router to Internet
|
|Interface xl0
|10.0.0.10/24
+------+
| | RouterA
| | (FreeBSD gateway)
+------+
| Interface xl1
| 192.168.1.1/24
|
+--------------------------------+
Internal Net 1 | 192.168.1.2/24
|
+------+
| | RouterB
| |
+------+
| 192.168.2.1/24
|
Internal Net 2
In this scenario, RouterA is our &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.)If we look at the routing table for
RouterA we would see something like the
following:&prompt.user; netstat -nr
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 10.0.0.1 UGS 0 49378 xl0
127.0.0.1 127.0.0.1 UH 0 6 lo0
10.0.0/24 link#1 UC 0 0 xl0
192.168.1/24 link#2 UC 0 0 xl1With 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 hop:&prompt.root; route add -net 192.168.2.0/24 192.168.1.2Now RouterA can reach any hosts on the
192.168.2.0/24
network.Persistent ConfigurationThe 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. The way to handle the addition of a static route
is to put it in your /etc/rc.conf
file:# 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
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:&prompt.root; route add -net 192.168.2.0/24 192.168.1.2so 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:static_routes="net1 net2"
route_net1="-net 192.168.0.0/24 192.168.0.1"
route_net2="-net 192.168.1.0/24 192.168.1.1"Routing Propagationrouting propagationWe 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
propagation.TroubleshootingtracerouteSometimes, there is a problem with routing propagation, and some
sites are unable to connect to you. 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 reaching the target
host, or terminating because of a lack of connection.For more information, see the manual page for
&man.traceroute.8;.Multicast Routingmulticast routingkernel optionsMROUTINGFreeBSD 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:options MROUTINGIn addition, 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
&man.mrouted.8;.EricAndersonWritten by Wireless Networkingwireless networking802.11wireless networkingIntroductionIt can be very useful to be able to use a computer without the
annoyance of having a network cable attached at all times. FreeBSD can
be used as a wireless client, and even as a wireless access
point.Wireless Modes of OperationThere are two different ways to configure 802.11 wireless devices:
BSS and IBSS.BSS ModeBSS mode is the mode that typically is used. BSS mode is
also called infrastructure mode. In this mode, a number of
wireless access points are connected to a wired network. Each
wireless network has its own name. This name is called the
SSID of the network.Wireless clients connect to these wireless access
points. The IEEE 802.11 standard defines the protocol that
wireless networks use to connect. A wireless client can be
tied to a specific network, when a SSID is set. A wireless
client can also attach to any network by not explicitly
setting a SSID.IBSS ModeIBSS mode, also called ad-hoc mode, is designed for point
to point connections. There are actually two types of ad-hoc
mode. One is IBSS mode, also called ad-hoc or IEEE ad-hoc
mode. This mode is defined by the IEEE 802.11 standards.
The second is called demo ad-hoc mode or Lucent ad-hoc mode
(and sometimes, confusingly, ad-hoc mode). This is the old,
pre-802.11 ad-hoc mode and should only be used for legacy
installations. We will not cover either of the ad-hoc modes
further.Infrastructure ModeAccess PointsAccess points are wireless networking devices that allow
one or more wireless clients to use the device as a central
hub. When using an access point, all clients communicate
through the access point. Multiple access points are often
used to cover a complete area such as a house, business, or
park with a wireless network.Access points typically have multiple network
connections: the wireless card, and one or more wired Ethernet
adapters for connection to the rest of the network.
Access points can either be purchased prebuilt, or you
can build your own with FreeBSD and a supported wireless card.
Several vendors make wireless access points and wireless cards
with various features.Building a FreeBSD Access Pointwireless networkingaccess pointRequirementsIn order to set up a wireless access point with
FreeBSD, you need to have a compatible wireless card.
Currently, only cards with the Prism chipset are
supported. You will also need a wired network card that is
supported by FreeBSD (this should not be difficult to find,
FreeBSD supports a lot of different devices). For this
guide, we will assume you want to &man.bridge.4; all traffic
between the wireless device and the network attached to the
wired network card.The hostap functionality that FreeBSD uses to implement
the access point works best with certain versions of
firmware. Prism 2 cards should use firmware version 1.3.4
or newer. Prism 2.5 and Prism 3 cards should use firmware
1.4.9. Older versions of the firmware way or may not
function correctly. At this time, the only way to update
cards is with &windows; firmware update utilities available
from your card's manufacturer.Setting It UpFirst, make sure your system can see the wireless card:&prompt.root; ifconfig -a
wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::202:2dff:fe2d:c938%wi0 prefixlen 64 scopeid 0x7
inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
ether 00:09:2d:2d:c9:50
media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps)
status: no carrier
ssid ""
stationname "FreeBSD Wireless node"
channel 10 authmode OPEN powersavemode OFF powersavesleep 100
wepmode OFF weptxkey 1Do not worry about the details now, just make sure it shows you
something to indicate you have a wireless card installed.
If you have trouble seeing the wireless interface, and you
are using a PC Card, you may want to check out
&man.pccardc.8; and &man.pccardd.8; manual pages for more
information.Next, you will need to load a module in order to get
the bridging part of FreeBSD ready for the access point.
To load the &man.bridge.4; module, simply run the
following command:&prompt.root; kldload bridgeIt should not have produced any errors when loading the
module. If it did, you may need to compile the
&man.bridge.4; code into your kernel. The Bridging section of this handbook
should be able to help you accomplish that task.Now that you have the bridging stuff done, we need to
tell the FreeBSD kernel which interfaces to bridge together.
We do that by using &man.sysctl.8;:&prompt.root; sysctl net.link.ether.bridge.enable=1
&prompt.root; sysctl net.link.ether.bridge.config="wi0,xl0"
&prompt.root; sysctl net.inet.ip.forwarding=1On &os; versions earlier than 5.2, you
need to use the following options instead:&prompt.root; sysctl net.link.ether.bridge=1
&prompt.root; sysctl net.link.ether.bridge_cfg="wi0,xl0"
&prompt.root; sysctl net.inet.ip.forwarding=1Now it is time for the wireless card setup.
The following command will set the card into an access point:
&prompt.root; ifconfig wi0 ssid my_net channel 11 media DS/11Mbps mediaopt hostap up stationname "FreeBSD AP"The &man.ifconfig.8; line brings the
wi0 interface up, sets its SSID to
my_net, and sets the station name to
FreeBSD AP. The sets the card into 11Mbps mode and is
needed for any to take effect.
The option places the
interface into access point mode. The option sets the 802.11b channel to use. The
&man.wicontrol.8; manual page has valid channel options for
your regulatory domain.
Now you should have a complete functioning access point
up and running. You are encouraged to read
&man.wicontrol.8;, &man.ifconfig.8;, and &man.wi.4; for
further information.
It is also suggested that you read the section on encryption that follows.Status InformationOnce the access point is configured and operational,
operators will want to see the clients that are associated
with the access point. At any time, the operator may type:&prompt.root; wicontrol -l
1 station:
00:09:b7:7b:9d:16 asid=04c0, flags=3<ASSOC,AUTH>, caps=1<ESS>, rates=f<1M,2M,5.5M,11M>, sig=38/15
This shows that there is one station associated, along
with its parameters. The signal indicated should be used
as a relative indication of strength only. Its
translation to dBm or other units varies between different
firmware revisions.ClientsA wireless client is a system that accesses an access
point or another client directly. Typically, wireless clients only have one network device,
the wireless networking card.There are a few different ways to configure a wireless
client. These are based on the different wireless modes,
generally BSS (infrastructure mode, which requires an access
point), and IBSS (ad-hoc, or peer-to-peer mode). In our
example, we will use the most popular of the two, BSS mode, to
talk to an access point.RequirementsThere is only one real requirement for setting up FreeBSD as a wireless client.
You will need a wireless card that is supported by FreeBSD.Setting Up a Wireless FreeBSD ClientYou will need to know a few things about the wireless
network you are joining before you start. In this example, we
are joining a network that has a name of
my_net, and encryption turned off.In this example, we are not using encryption, which
is a dangerous situation. In the next section, you will learn
how to turn on encryption, why it is important to do so,
and why some encryption technologies still do not completely
protect you.Make sure your card is recognized by FreeBSD:&prompt.root; ifconfig -a
wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::202:2dff:fe2d:c938%wi0 prefixlen 64 scopeid 0x7
inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255
ether 00:09:2d:2d:c9:50
media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps)
status: no carrier
ssid ""
stationname "FreeBSD Wireless node"
channel 10 authmode OPEN powersavemode OFF powersavesleep 100
wepmode OFF weptxkey 1Now, we can set the card to the correct settings for our
network:&prompt.root; ifconfig wi0 inet 192.168.0.20 netmask 255.255.255.0 ssid my_netReplace 192.168.0.20 and
255.255.255.0 with a valid IP
address and netmask on your wired network. Remember, our
access point is bridging the data between the wireless
network, and the wired network, so it will appear to the other
devices on your network that you are on the wired network just
as they are.Once you have done that, you should be able to ping hosts
on the wired network just as if you were connected using a
standard wired connection.If you are experiencing problems with your wireless
connection, check to make sure that you are associated
(connected) to the access point:&prompt.root; ifconfig wi0should return some information, and you should see:status: associatedIf it does not show associated, then you may be out of
range of the access point, have encryption on, or
possibly have a configuration problem.Encryptionwireless networkingencryptionEncryption on a wireless network is important because you
no longer have the ability to keep the network contained in a
well protected area. Your wireless data will be broadcast
across your entire neighborhood, so anyone who cares to read it
can. This is where encryption comes in. By encrypting the
data that is sent over the airwaves, you make it much more
difficult for any interested party to grab your data right out
of the air. The two most common ways to encrypt the data between your
client and the access point are WEP, and &man.ipsec.4;.WEPWEPWEP is an abbreviation for Wired Equivalency Protocol.
WEP is an attempt to make wireless networks as safe and secure
as a wired network. Unfortunately, it has been cracked, and is
fairly trivial to break. This also means it is not something
to rely on when it comes to encrypting sensitive data. It is better than nothing, so use the following to turn on
WEP on your new FreeBSD access point:&prompt.root; ifconfig wi0 inet up ssid my_net wepmode on wepkey 0x1234567890 media DS/11Mbps mediaopt hostapAnd you can turn on WEP on a client with this command:&prompt.root; ifconfig wi0 inet 192.168.0.20 netmask 255.255.255.0 ssid my_net wepmode on wepkey 0x1234567890Note that you should replace the 0x1234567890 with a more unique key.IPsec&man.ipsec.4; is a much more robust and powerful tool for
encrypting data across a network. This is definitely the
preferred way to encrypt data over a wireless network. You can
read more about &man.ipsec.4; security and how to implement it
in the IPsec section of this
handbook.ToolsThere are a small number of tools available for use in
debugging and setting up your wireless network, and here we will
attempt to describe some of them and what they do.The bsd-airtools PackageThe bsd-airtools package is a
complete toolset that includes wireless auditing tools for WEP
key cracking, access point detection, etc.The bsd-airtools utilities can be
installed from the net/bsd-airtools port. Information on
installing ports can be found in of this
handbook.The program dstumbler is the packaged
tool that allows for access point discovery and signal to noise
ratio graphing. If you are having a hard time getting your
access point up and running, dstumbler may
help you get started.To test your wireless network security, you may choose to
use dweputils (dwepcrack,
dwepdump and dwepkeygen)
to help you determine if WEP is the right solution to your
wireless security needs.The wicontrol, ancontrol and raycontrol UtilitiesThese are the tools you can use to control how your wireless
card behaves on the wireless network. In the examples above, we
have chosen to use &man.wicontrol.8;, since our wireless card is
a wi0 interface. If you had a Cisco
wireless device, it would come up as
an0, and therefore you would use
&man.ancontrol.8;.The ifconfig CommandifconfigThe &man.ifconfig.8; command can be used to do many of the same options
as &man.wicontrol.8;, however it does lack a few options. Check
&man.ifconfig.8; for command line parameters and options.Supported CardsAccess PointsThe only cards that are currently supported for BSS (as an
access point) mode are devices based on the Prism 2, 2.5, or 3
chipsets. For a complete list, look at &man.wi.4;.802.11b ClientsAlmost all 802.11b wireless cards are currently supported
under FreeBSD. Most cards based on Prism, Spectrum24, Hermes,
Aironet, and Raylink will work as a wireless network card in
IBSS (ad-hoc, peer-to-peer, and BSS) mode.802.11a & 802.11g ClientsThe &man.ath.4; device driver supports 802.11a and 802.11g.
If your card is based on an Atheros chipset, you may
be able to use this driver.Unfortunately, there are still many vendors that do not
provide schematics for their drivers to the open source
community because they regard such information as trade
secrets. Consequently, the developers of FreeBSD and other
operating systems are left two choices: develop the drivers by
a long and pain-staking process of reverse engineering or using
the existing driver binaries available for the
µsoft.windows; platforms. Most developers, including those
involved with FreeBSD, have taken the latter approach.Thanks to the contributions of Bill Paul (wpaul), as of
FreeBSD 5.3-RELEASE there is native
support for the Network Driver Interface Specification
(NDIS). The FreeBSD NDISulator (otherwise known as Project Evil)
takes a &windows; driver binary and basically tricks it into
thinking it is running on &windows;. This feature is still
relatively new, but most test cases seem to work
adequately.NDISNDISulator&windows; driversMicrosoft WindowsMicrosoft Windowsdevice driversKLD (kernel loadable object)In order to use the NDISulator, you need three things:Kernel sources&windowsxp; driver binary
(.SYS extension)&windowsxp; driver configuration file
(.INF extension)You may need to compile the &man.ndis.4; mini port driver
wrapper module. As root:&prompt.root; cd /usr/src/sys/modules/ndis
&prompt.root; make && make installLocate the files for your specific card. Generally, they can
be found on the included CDs or at the vendors' websites. In the
following examples, we will use
W32DRIVER.SYS and
W32DRIVER.INF.The next step is to compile the driver binary into a
loadable kernel module. To accomplish this, as
root, go into the
if_ndis module directory and copy the
&windows; driver files into it:&prompt.root; cd /usr/src/sys/modules/if_ndis
&prompt.root; cp /path/to/driver/W32DRIVER.SYS ./
&prompt.root; cp /path/to/driver/W32DRIVER.INF ./We will now use the ndiscvt utility to
create the driver definition header
ndis_driver_data.h to build the
module:&prompt.root; ndiscvt -i W32DRIVER.INF -s W32DRIVER.SYS -o ndis_driver_data.hThe and options specify
the configuration and binary files, respectively. We use the
option because the
Makefile will be looking for this file when it
comes time to build the module. Some &windows; drivers require additional files to operate. You
may include them with ndiscvt by using the
option. Consult the &man.ndiscvt.8; manual page
for more information.Finally, we can build and install the driver module:&prompt.root; make && make installTo use the driver, you must load the appropriate modules:&prompt.root; kldload ndis
&prompt.root; kldload if_ndisThe first command loads the NDIS miniport driver wrapper,
the second loads the actual network interface. Check
&man.dmesg.8; to see if there were any errors loading. If all
went well, you should get output resembling the
following:ndis0: <Wireless-G PCI Adapter> mem 0xf4100000-0xf4101fff irq 3 at device 8.0 on pci1
ndis0: NDIS API version: 5.0
ndis0: Ethernet address: 0a:b1:2c:d3:4e:f5
ndis0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
ndis0: 11g rates: 6Mbps 9Mbps 12Mbps 18Mbps 36Mbps 48Mbps 54MbpsFrom here you can treat the ndis0 device
like any other wireless device (e.g. wi0) and
consult the earlier sections of this chapter.PavLucistnikWritten by pav@oook.czBluetoothBluetoothIntroductionBluetooth is a wireless technology for creating personal networks
operating in the 2.4 GHz unlicensed band, with a range of 10 meters.
Networks are usually formed ad-hoc from portable devices such as
cellular phones, handhelds and laptops. Unlike the other popular
wireless technology, Wi-Fi, Bluetooth offers higher level service
profiles, e.g. FTP-like file servers, file pushing, voice transport,
serial line emulation, and more.The Bluetooth stack in &os; is implemented using the Netgraph
framework (see &man.netgraph.4;). A broad variety of Bluetooth USB
dongles is supported by the &man.ng.ubt.4; driver. The Broadcom BCM2033
chip based Bluetooth devices are supported via the &man.ubtbcmfw.4; and
&man.ng.ubt.4; drivers. The 3Com Bluetooth PC Card 3CRWB60-A is
supported by the &man.ng.bt3c.4; driver. Serial and UART based
Bluetooth devices are supported via &man.sio.4;, &man.ng.h4.4;
and &man.hcseriald.8;. This section describes the use of the USB
Bluetooth dongle. Bluetooth support is available in &os; 5.0 and newer
systems.Plugging in the DeviceBy default Bluetooth device drivers are available as kernel modules.
Before attaching a device, you will need to load the driver into the
kernel:&prompt.root; kldload ng_ubtIf the Bluetooth device is present in the system during system
startup, load the module from
/boot/loader.conf:ng_ubt_load="YES"Plug in your USB dongle. The output similar to the following will
appear on the console (or in syslog):ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2
ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2
ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3,
wMaxPacketSize=49, nframes=6, buffer size=294Copy
/usr/share/examples/netgraph/bluetooth/rc.bluetooth
into some convenient place, like /etc/rc.bluetooth.
This script is used to start and stop the Bluetooth stack. It is a good
idea to stop the stack before unplugging the device, but it is not
(usually) fatal. When starting the stack, you will receive output similar
to the following:&prompt.root; /etc/rc.bluetooth start ubt0
BD_ADDR: 00:02:72:00:d4:1a
Features: 0xff 0xff 0xf 00 00 00 00 00
<3-Slot> <5-Slot> <Encryption> <Slot offset>
<Timing accuracy> <Switch> <Hold mode> <Sniff mode>
<Park mode> <RSSI> <Channel quality> <SCO link>
<HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD>
<Paging scheme> <Power control> <Transparent SCO data>
Max. ACL packet size: 192 bytes
Number of ACL packets: 8
Max. SCO packet size: 64 bytes
Number of SCO packets: 8HCIHost Controller Interface (HCI)Host Controller Interface (HCI) provides a command interface to the
baseband controller and link manager, and access to hardware status and
control registers. This interface provides a uniform method of accessing
the Bluetooth baseband capabilities. HCI layer on the Host exchanges
data and commands with the HCI firmware on the Bluetooth hardware.
The Host Controller Transport Layer (i.e. physical bus) driver provides
both HCI layers with the ability to exchange information with each
other.A single Netgraph node of type hci is
created for a single Bluetooth device. The HCI node is normally
connected to the Bluetooth device driver node (downstream) and
the L2CAP node (upstream). All HCI operations must be performed
on the HCI node and not on the device driver node. Default name
for the HCI node is devicehci.
For more details refer to the &man.ng.hci.4; manual page.One of the most common tasks is discovery of Bluetooth devices in
RF proximity. This operation is called inquiry.
Inquiry and other HCI related operations are done with the
&man.hccontrol.8; utility. The example below shows how to find out
which Bluetooth devices are in range. You should receive the list of
devices in a few seconds. Note that a remote device will only answer
the inquiry if it put into discoverable
mode.&prompt.user; hccontrol -n ubt0hci inquiry
Inquiry result, num_responses=1
Inquiry result #0
BD_ADDR: 00:80:37:29:19:a4
Page Scan Rep. Mode: 0x1
Page Scan Period Mode: 00
Page Scan Mode: 00
Class: 52:02:04
Clock offset: 0x78ef
Inquiry complete. Status: No error [00]BD_ADDR is unique address of a Bluetooth
device, similar to MAC addresses of a network card. This address
is needed for further communication with a device. It is possible
to assign human readable name to a BD_ADDR.
The /etc/bluetooth/hosts file contains information
regarding the known Bluetooth hosts. The following example shows how
to obtain human readable name that was assigned to the remote
device:&prompt.user; hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4
BD_ADDR: 00:80:37:29:19:a4
Name: Pav's T39If you perform an inquiry on a remote Bluetooth device, it will
find your computer as your.host.name (ubt0). The name
assigned to the local device can be changed at any time.The Bluetooth system provides a point-to-point connection (only two
Bluetooth units involved), or a point-to-multipoint connection. In the
point-to-multipoint connection the connection is shared among several
Bluetooth devices. The following example shows how to obtain the list
of active baseband connections for the local device:&prompt.user; hccontrol -n ubt0hci read_connection_list
Remote BD_ADDR Handle Type Mode Role Encrypt Pending Queue State
00:80:37:29:19:a4 41 ACL 0 MAST NONE 0 0 OPENA connection handle is useful when termination
of the baseband connection is required. Note, that it is normally not
required to do it by hand. The stack will automatically terminate
inactive baseband connections.&prompt.root; hccontrol -n ubt0hci disconnect 41
Connection handle: 41
Reason: Connection terminated by local host [0x16]Refer to hccontrol help for a complete listing
of available HCI commands. Most of the HCI commands do not require
superuser privileges.L2CAPLogical Link Control and Adaptation Protocol (L2CAP)Logical Link Control and Adaptation Protocol (L2CAP) provides
connection-oriented and connectionless data services to upper layer
protocols with protocol multiplexing capability and segmentation and
reassembly operation. L2CAP permits higher level protocols and
applications to transmit and receive L2CAP data packets up to 64
kilobytes in length.L2CAP is based around the concept of channels.
Channel is a logical connection on top of baseband connection. Each
channel is bound to a single protocol in a many-to-one fashion. Multiple
channels can be bound to the same protocol, but a channel cannot be
bound to multiple protocols. Each L2CAP packet received on a channel is
directed to the appropriate higher level protocol. Multiple channels
can share the same baseband connection.A single Netgraph node of type l2cap is
created for a single Bluetooth device. The L2CAP node is normally
connected to the Bluetooth HCI node (downstream) and Bluetooth sockets
nodes (upstream). Default name for the L2CAP node is
devicel2cap. For more details refer to the
&man.ng.l2cap.4; manual page.A useful command is &man.l2ping.8;, which can be used to ping
other devices. Some Bluetooth implementations might not return all of
the data sent to them, so 0 bytes in the following
example is normal.&prompt.root; l2ping -a 00:80:37:29:19:a4
0 bytes from 0:80:37:29:19:a4 seq_no=0 time=48.633 ms result=0
0 bytes from 0:80:37:29:19:a4 seq_no=1 time=37.551 ms result=0
0 bytes from 0:80:37:29:19:a4 seq_no=2 time=28.324 ms result=0
0 bytes from 0:80:37:29:19:a4 seq_no=3 time=46.150 ms result=0The &man.l2control.8; utility is used to perform various operations
on L2CAP nodes. This example shows how to obtain the list of logical
connections (channels) and the list of baseband connections for the
local device:&prompt.user; l2control -a 00:02:72:00:d4:1a read_channel_list
L2CAP channels:
Remote BD_ADDR SCID/ DCID PSM IMTU/ OMTU State
00:07:e0:00:0b:ca 66/ 64 3 132/ 672 OPEN
&prompt.user; l2control -a 00:02:72:00:d4:1a read_connection_list
L2CAP connections:
Remote BD_ADDR Handle Flags Pending State
00:07:e0:00:0b:ca 41 O 0 OPENAnother diagnostic tool is &man.btsockstat.1;. It does a job
similar to as &man.netstat.1; does, but for Bluetooth network-related
data structures. The example below shows the same logical connection as
&man.l2control.8; above.&prompt.user; btsockstat
Active L2CAP sockets
PCB Recv-Q Send-Q Local address/PSM Foreign address CID State
c2afe900 0 0 00:02:72:00:d4:1a/3 00:07:e0:00:0b:ca 66 OPEN
Active RFCOMM sessions
L2PCB PCB Flag MTU Out-Q DLCs State
c2afe900 c2b53380 1 127 0 Yes OPEN
Active RFCOMM sockets
PCB Recv-Q Send-Q Local address Foreign address Chan DLCI State
c2e8bc80 0 250 00:02:72:00:d4:1a 00:07:e0:00:0b:ca 3 6 OPENRFCOMMRFCOMM ProtocolThe RFCOMM protocol provides emulation of serial ports over the
L2CAP protocol. The protocol is based on the ETSI standard TS 07.10.
RFCOMM is a simple transport protocol, with additional provisions for
emulating the 9 circuits of RS-232 (EIATIA-232-E) serial ports. The
RFCOMM protocol supports up to 60 simultaneous connections (RFCOMM
channels) between two Bluetooth devices.For the purposes of RFCOMM, a complete communication path involves
two applications running on different devices (the communication
endpoints) with a communication segment between them. RFCOMM is intended
to cover applications that make use of the serial ports of the devices
in which they reside. The communication segment is a Bluetooth link from
one device to another (direct connect).RFCOMM is only concerned with the connection between the devices in
the direct connect case, or between the device and a modem in the
network case. RFCOMM can support other configurations, such as modules
that communicate via Bluetooth wireless technology on one side and
provide a wired interface on the other side.In &os; the RFCOMM protocol is implemented at the Bluetooth sockets
layer.pairingPairing of DevicesBy default, Bluetooth communication is not authenticated, and any
device can talk to any other device. A Bluetooth device (for example,
cellular phone) may choose to require authentication to provide a
particular service (for example, Dial-Up service). Bluetooth
authentication is normally done with PIN codes.
A PIN code is an ASCII string up to 16 characters in length. User is
required to enter the same PIN code on both devices. Once user has
entered the PIN code, both devices will generate a
link key. After that the link key can be stored
either in the devices themselves or in a persistent storage. Next time
both devices will use previously generated link key. The described
above procedure is called pairing. Note that if
the link key is lost by any device then pairing must be repeated.The &man.hcsecd.8; daemon is responsible for handling of all
Bluetooth authentication requests. The default configuration file is
/etc/bluetooth/hcsecd.conf. An example section for
a cellular phone with the PIN code arbitrarily set to
1234 is shown below:device {
bdaddr 00:80:37:29:19:a4;
name "Pav's T39";
key nokey;
pin "1234";
}There is no limitation on PIN codes (except length). Some devices
(for example Bluetooth headsets) may have a fixed PIN code built in.
The switch forces the &man.hcsecd.8; daemon to stay
in the foreground, so it is easy to see what is happening. Set the
remote device to receive pairing and initiate the Bluetooth connection
to the remote device. The remote device should say that pairing was
accepted, and request the PIN code. Enter the same PIN code as you
have in hcsecd.conf. Now your PC and the remote
device are paired. Alternatively, you can initiate pairing on the remote
device. The following is a sample of the
hcsecd daemon output:hcsecd[16484]: Got Link_Key_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4
hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', link key doesn't exist
hcsecd[16484]: Sending Link_Key_Negative_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4
hcsecd[16484]: Got PIN_Code_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4
hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', PIN code exists
hcsecd[16484]: Sending PIN_Code_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4SDPService Discovery Protocol (SDP)The Service Discovery Protocol (SDP) provides the means for client
applications to discover the existence of services provided by server
applications as well as the attributes of those services. The attributes
of a service include the type or class of service offered and the
mechanism or protocol information needed to utilize the service.SDP involves communication between a SDP server and a SDP client.
The server maintains a list of service records that describe the
characteristics of services associated with the server. Each service
record contains information about a single service. A client may
retrieve information from a service record maintained by the SDP server
by issuing a SDP request. If the client, or an application associated
with the client, decides to use a service, it must open a separate
connection to the service provider in order to utilize the service.
SDP provides a mechanism for discovering services and their attributes,
but it does not provide a mechanism for utilizing those services.Normally, a SDP client searches for services based on some desired
characteristics of the services. However, there are times when it is
desirable to discover which types of services are described by an SDP
server's service records without any a priori information about the
services. This process of looking for any offered services is called
browsing.The Bluetooth SDP server &man.sdpd.8; and command line client
&man.sdpcontrol.8; are included in the standard &os; installation.
The following example shows how to perform a SDP browse query.&prompt.user; sdpcontrol -a 00:01:03:fc:6e:ec browse
Record Handle: 00000000
Service Class ID List:
Service Discovery Server (0x1000)
Protocol Descriptor List:
L2CAP (0x0100)
Protocol specific parameter #1: u/int/uuid16 1
Protocol specific parameter #2: u/int/uuid16 1
Record Handle: 0x00000001
Service Class ID List:
Browse Group Descriptor (0x1001)
Record Handle: 0x00000002
Service Class ID List:
LAN Access Using PPP (0x1102)
Protocol Descriptor List:
L2CAP (0x0100)
RFCOMM (0x0003)
Protocol specific parameter #1: u/int8/bool 1
Bluetooth Profile Descriptor List:
LAN Access Using PPP (0x1102) ver. 1.0
... and so on. Note that each service has a list of attributes
(RFCOMM channel for example). Depending on the service you might need to
make a note of some of the attributes. Some Bluetooth implementations do
not support service browsing and may return an empty list. In this case
it is possible to search for the specific service. The example below
shows how to search for the OBEX Object Push (OPUSH) service:&prompt.user; sdpcontrol -a 00:01:03:fc:6e:ec search OPUSHOffering services on &os; to Bluetooth clients is done with the
&man.sdpd.8; server:&prompt.root; sdpdThe local server application that wants to provide Bluetooth
service to the remote clients will register service with the local
SDP daemon. The example of such application is &man.rfcomm.pppd.8;.
Once started it will register Bluetooth LAN service with the local
SDP daemon.The list of services registered with the local SDP server can be
obtained by issuing SDP browse query via local control channel:&prompt.root; sdpcontrol -l browseDial-Up Networking (DUN) and Network Access with PPP (LAN)
ProfilesThe Dial-Up Networking (DUN) profile is mostly used with modems
and cellular phones. The scenarios covered by this profile are the
following:use of a cellular phone or modem by a computer as
a wireless modem for connecting to a dial-up Internet access server,
or using other dial-up services;use of a cellular phone or modem by a computer to
receive data calls.Network Access with PPP (LAN) profile can be used in the following
situations:LAN access for a single Bluetooth device;
LAN access for multiple Bluetooth devices;
PC to PC (using PPP networking over serial cable
emulation).In &os; both profiles are implemented with &man.ppp.8; and
&man.rfcomm.pppd.8; - a wrapper that converts RFCOMM Bluetooth
connection into something PPP can operate with. Before any profile
can be used, a new PPP label in the /etc/ppp/ppp.conf
must be created. Consult &man.rfcomm.pppd.8; manual page for examples.
In the following example &man.rfcomm.pppd.8; will be used to open
RFCOMM connection to remote device with BD_ADDR 00:80:37:29:19:a4 on
DUN RFCOMM channel. The actual RFCOMM channel number will be obtained
from the remote device via SDP. It is possible to specify RFCOMM channel
by hand, and in this case &man.rfcomm.pppd.8; will not perform SDP
query. Use &man.sdpcontrol.8; to find out RFCOMM
channel on the remote device.&prompt.root; rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialupIn order to provide Network Access with PPP (LAN) service the
&man.sdpd.8; server must be running. A new entry for LAN clients must
be created in the /etc/ppp/ppp.conf file. Consult
&man.rfcomm.pppd.8; manual page for examples. Finally, start RFCOMM PPP
server on valid RFCOMM channel number. The RFCOMM PPP server will
automatically register Bluetooth LAN service with the local SDP daemon.
The example below shows how to start RFCOMM PPP server.&prompt.root; rfcomm_pppd -s -C 7 -l rfcomm-serverOBEXOBEX Object Push (OPUSH) ProfileOBEX is a widely used protocol for simple file transfers between
mobile devices. Its main use is in infrared communication, where it is
used for generic file transfers between notebooks or PDAs,
and for sending business cards or calendar entries between cellular
phones and other devices with PIM applications.The OBEX server and client are implemented as a third-party package
obexapp, which is available as
comms/obexapp port.OBEX client is used to push and/or pull objects from the OBEX server.
An object can, for example, be a business card or an appointment.
The OBEX client can obtain RFCOMM channel number from the remote device
via SDP. This can be done by specifying service name instead of RFCOMM
channel number. Supported service names are: IrMC, FTRN and OPUSH.
It is possible to specify RFCOMM channel as a number. Below is an
example of an OBEX session, where device information object is pulled
from the cellular phone, and a new object (business card) is pushed
into the phone's directory.&prompt.user; obexapp -a 00:80:37:29:19:a4 -C IrMC
obex> get telecom/devinfo.txt devinfo-t39.txt
Success, response: OK, Success (0x20)
obex> put new.vcf
Success, response: OK, Success (0x20)
obex> di
Success, response: OK, Success (0x20)In order to provide OBEX Object Push service,
&man.sdpd.8; server must be running. A root folder, where all incoming
objects will be stored, must be created. The default path to the root
folder is /var/spool/obex. Finally, start OBEX
server on valid RFCOMM channel number. The OBEX server will
automatically register OBEX Object Push service with the local SDP
daemon. The example below shows how to start OBEX server.&prompt.root; obexapp -s -C 10Serial Port Profile (SPP)The Serial Port Profile (SPP) allows Bluetooth devices to perform
RS232 (or similar) serial cable emulation. The scenario covered by this
profile deals with legacy applications using Bluetooth as a cable
replacement, through a virtual serial port abstraction.The &man.rfcomm.sppd.1; utility implements the Serial Port profile.
A pseudo tty is used as a virtual serial port abstraction. The example
below shows how to connect to a remote device Serial Port service.
Note that you do not have to specify a RFCOMM channel -
&man.rfcomm.sppd.1; can obtain it from the remote device via SDP.
If you would like to override this, specify a RFCOMM channel on the
command line.&prompt.root; rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6
rfcomm_sppd[94692]: Starting on /dev/ttyp6...Once connected, the pseudo tty can be used as serial port:&prompt.root; cu -l ttyp6TroubleshootingA remote device cannot connectSome older Bluetooth devices do not support role switching.
By default, when &os; is accepting a new connection, it tries to
perform a role switch and become master. Devices, which do not
support this will not be able to connect. Note that role switching is
performed when a new connection is being established, so it is not
possible to ask the remote device if it does support role switching.
There is a HCI option to disable role switching on the local
side:&prompt.root; hccontrol -n ubt0hci write_node_role_switch 0Something is going wrong, can I see what exactly is happening?Yes, you can. Use the third-party package
hcidump, which is available as
comms/hcidump port.
The hcidump utility is similar to
&man.tcpdump.1;. It can be used to display the content of the Bluetooth
packets on the terminal and to dump the Bluetooth packets to a
file.StevePetersonWritten by BridgingIntroductionIP subnetbridgeIt is sometimes useful to divide one physical network
(such as an Ethernet segment) into two separate network
segments without having to create IP subnets and use a router
to connect the segments together. A device that connects two
networks together in this fashion is called a
bridge. A FreeBSD system with two network
interface cards can act as a bridge.The bridge works by learning the MAC layer addresses
(Ethernet addresses) of the devices on each of its network interfaces.
It forwards traffic between two networks only when its source and
destination are on different networks.In many respects, a bridge is like an Ethernet switch with very
few ports.Situations Where Bridging Is AppropriateThere are two common situations in which a bridge is used
today.High Traffic on a SegmentSituation one is where your physical network segment is
overloaded with traffic, but you do not want for whatever reason to
subnet the network and interconnect the subnets with a
router.Let us consider an example of a newspaper where the Editorial and
Production departments are on the same subnetwork. The Editorial
users all use server A for file service, and the Production users
are on server B. An Ethernet network is used to connect all users together,
and high loads on the network are slowing things down.If the Editorial users could be segregated on one
network segment and the Production users on another, the two
network segments could be connected with a bridge. Only the
network traffic destined for interfaces on the
other side of the bridge would be sent to the
other network, reducing congestion on each network
segment.Filtering/Traffic Shaping FirewallfirewallNATThe second common situation is where firewall functionality is
needed without network address translation (NAT).An example is a small company that is connected via DSL
or ISDN to their ISP. They have a 13 globally-accessible IP
addresses from their ISP and have 10 PCs on their network.
In this situation, using a router-based firewall is
difficult because of subnetting issues.routerDSLISDNA bridge-based firewall can be configured and dropped into the
path just downstream of their DSL/ISDN router without any IP
numbering issues.Configuring a BridgeNetwork Interface Card SelectionA bridge requires at least two network cards to function.
Unfortunately, not all network interface cards as of FreeBSD 4.0
support bridging. Read &man.bridge.4; for details on the cards that
are supported.Install and test the two network cards before continuing.Kernel Configuration Changeskernel optionsBRIDGETo enable kernel support for bridging, add the:options BRIDGEstatement to your kernel configuration file, and rebuild your
kernel.Firewall SupportfirewallIf you are planning to use the bridge as a firewall, you
will need to add the IPFIREWALL option as
well. Read for general
information on configuring the bridge as a firewall.If you need to allow non-IP packets (such as ARP) to flow
through the bridge, there is a firewall option that
must be set. This option is
IPFIREWALL_DEFAULT_TO_ACCEPT. Note that this
changes the default rule for the firewall to accept any packet.
Make sure you know how this changes the meaning of your ruleset
before you set it.Traffic Shaping SupportIf you want to use the bridge as a traffic shaper, you will need
to add the DUMMYNET option to your kernel
configuration. Read &man.dummynet.4; for further
information.Enabling the BridgeAdd the line:net.link.ether.bridge.enable=1to /etc/sysctl.conf to enable the bridge at
runtime, and the line:net.link.ether.bridge.config=if1,if2to enable bridging on the specified interfaces (replace
if1 and
if2 with the names of your two
network interfaces). If you want the bridged packets to be
filtered by &man.ipfw.8;, you should add:net.link.ether.bridge.ipfw=1as well.For versions prior to &os; 5.2-RELEASE, use instead the following
lines:net.link.ether.bridge=1
net.link.ether.bridge_cfg=if1,if2
net.link.ether.bridge_ipfw=1Other InformationIf you want to be able to &man.ssh.1; into the bridge from the network,
it is correct to assign one of the network cards an IP address. The
consensus is that assigning both cards an address is a bad
idea.If you have multiple bridges on your network, there cannot be more
than one path between any two workstations. Technically, this means
that there is no support for spanning tree link management.A bridge can add latency to your &man.ping.8; times, especially for
traffic from one segment to another.Jean-FrançoisDockèsUpdated by AlexDupreReorganized and enhanced by Diskless Operationdiskless workstationdiskless operationA FreeBSD machine can boot over the network and operate without a
- local disk, using filesystems mounted from an NFS server. No system
+ local disk, using file systems mounted from an NFS server. No system
modification is necessary, beyond standard configuration files.
Such a system is relatively easy to set up because all the necessary elements
are readily available:There are at least two possible methods to load the kernel over
the network:PXE: The &intel; Preboot eXecution
Environment system is a form of smart boot ROM built into some
networking cards or motherboards. See &man.pxeboot.8; for more
details.The Etherboot
port (net/etherboot) produces
ROM-able code to boot kernels over the network. The
code can be either burnt into a boot PROM on a network
card, or loaded from a local floppy (or hard) disk
drive, or from a running &ms-dos; system. Many network
cards are supported.A sample script
(/usr/share/examples/diskless/clone_root) eases
- the creation and maintenance of the workstation's root filesystem
+ the creation and maintenance of the workstation's root file system
on the server. The script will probably require a little
customization but it will get you started very quickly.Standard system startup files exist in /etc
to detect and support a diskless system startup.Swapping, if needed, can be done either to an NFS file or to
a local disk.There are many ways to set up diskless workstations. Many
elements are involved, and most can be customized to suit local
taste. The following will describe variations on the setup of a complete system,
emphasizing simplicity and compatibility with the
standard FreeBSD startup scripts. The system described has the
following characteristics:The diskless workstations use a shared
- read-only / filesystem, and a shared
+ read-only / file system, and a shared
read-only /usr.
- The root filesystem is a copy of a
+ The root file system is a copy of a
standard FreeBSD root (typically the server's), with some
configuration files overridden by ones specific to diskless
operation or, possibly, to the workstation they belong to.The parts of the root which have to be
- writable are overlaid with &man.mfs.8; (&os; 4.X) or &man.md.4; (&os; 5.X) filesystems. Any changes
+ writable are overlaid with &man.mfs.8; (&os; 4.X) or &man.md.4; (&os; 5.X) file systems. Any changes
will be lost when the system reboots.The kernel is transferred and loaded either with
Etherboot or PXE
as some situations may mandate the use of either method.As described, this system is insecure. It should
live in a protected area of a network, and be untrusted by
other hosts.All the information in this section has been tested
using &os; releases 4.9-RELEASE and 5.2.1-RELEASE. The text is
primarily structured for 4.X usage. Notes have been inserted where
appropriate to indicate 5.X changes.Background InformationSetting up diskless workstations is both relatively
straightforward and prone to errors. These are sometimes
difficult to diagnose for a number of reasons. For example:Compile time options may determine different behaviors at
runtime.Error messages are often cryptic or totally absent.In this context, having some knowledge of the background
mechanisms involved is very useful to solve the problems that
may arise.Several operations need to be performed for a successful
bootstrap:The machine needs to obtain initial parameters such as its IP
address, executable filename, server name, root path. This is
done using the DHCP or BOOTP protocols.
DHCP is a compatible extension of BOOTP, and
uses the same port numbers and basic packet format.It is possible to configure a system to use only BOOTP.
The &man.bootpd.8; server program is included in the base &os;
system.However, DHCP has a number of advantages
over BOOTP (nicer configuration files, possibility of using
PXE, plus many others not directly related to
diskless operation), and we will describe mainly a
DHCP configuration, with equivalent examples
using &man.bootpd.8; when possible. The sample configuration will
use the ISC DHCP software package
(release 3.0.1.r12 was installed on the test server).The machine needs to transfer one or several programs to local
memory. Either TFTP or NFS
are used. The choice between TFTP and
NFS is a compile time option in several places.
A common source of error is to specify filenames for the wrong
protocol: TFTP typically transfers all files from
a single directory on the server, and would expect filenames
relative to this directory. NFS needs absolute
file paths.The possible intermediate bootstrap programs and the kernel
need to be initialized and executed. There are several important
variations in this area:PXE will load &man.pxeboot.8;, which is
a modified version of the &os; third stage loader. The
&man.loader.8; will obtain most parameters necessary to system
startup, and leave them in the kernel environment before
transferring control. It is possible to use a
GENERIC kernel in this case.Etherboot, will directly
load the kernel, with less preparation. You will need to
build a kernel with specific options.PXE and Etherboot
work equally well with 4.X systems. Because 5.X kernels
normally let the &man.loader.8; do more work for them,
PXE is preferred for 5.X systems.If your BIOS and network cards support
PXE, you should probably use it. However,
it is still possible to start a 5.X system with
Etherboot.
- Finally, the machine needs to access its filesystems.
+ Finally, the machine needs to access its file systems.
NFS is used in all cases.See also &man.diskless.8; manual page.Setup InstructionsConfiguration Using ISC DHCPDHCPdiskless operationThe ISC DHCP server can answer
both BOOTP and DHCP requests.As of release 4.9, ISC DHCP
3.0 is not part of the base
system. You will first need to install the
net/isc-dhcp3-server port or the
corresponding package.Once ISC DHCP is installed, it
needs a configuration file to run, (normally named
/usr/local/etc/dhcpd.conf). Here follows
a commented example, where host margaux
uses Etherboot and host
corbieres uses PXE:
default-lease-time 600;
max-lease-time 7200;
authoritative;
option domain-name "example.com";
option domain-name-servers 192.168.4.1;
option routers 192.168.4.1;
subnet 192.168.4.0 netmask 255.255.255.0 {
use-host-decl-names on;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.4.255;
host margaux {
hardware ethernet 01:23:45:67:89:ab;
fixed-address margaux.example.com;
next-server 192.168.4.4;
filename "/data/misc/kernel.diskless";
option root-path "192.168.4.4:/data/misc/diskless";
}
host corbieres {
hardware ethernet 00:02:b3:27:62:df;
fixed-address corbieres.example.com;
next-server 192.168.4.4;
filename "pxeboot";
option root-path "192.168.4.4:/data/misc/diskless";
}
}
This option tells
dhcpd to send the value in the
host declarations as the hostname for the
diskless host. An alternate way would be to add an
option host-name
margaux inside the
host declarations.The
next-server directive designates
the TFTP or NFS server to
use for loading loader or kernel file (the default is to use
the same host as the
DHCP server).The
filename directive defines the file that
Etherboot or PXE
will load for the next execution step. It must be specified
according to the transfer method used.
Etherboot can be compiled to use
NFS or TFTP. The &os;
port configures NFS by default.
PXE uses TFTP, which is
why a relative filename is used here (this may depend on the
TFTP server configuration, but would be
fairly typical). Also, PXE loads
pxeboot, not the kernel. There are other
interesting possibilities, like loading
pxeboot from a &os; CD-ROM
/boot directory (as
&man.pxeboot.8; can load a GENERIC kernel,
this makes it possible to use PXE to boot
from a remote CD-ROM).The
root-path option defines the path to
- the root filesystem, in usual NFS notation.
+ the root file system, in usual NFS notation.
When using PXE, it is possible to leave off
the host's IP as long as you do not enable the kernel option
BOOTP. The NFS server will then be
the same as the TFTP one.Configuration Using BOOTPBOOTPdiskless operationHere follows an equivalent bootpd
configuration (reduced to one client). This would be found in
/etc/bootptab.Please note that Etherboot
must be compiled with the non-default option
NO_DHCP_SUPPORT in order to use BOOTP,
and that PXE needs DHCP. The only
obvious advantage of bootpd is
that it exists in the base system.
.def100:\
:hn:ht=1:sa=192.168.4.4:vm=rfc1048:\
:sm=255.255.255.0:\
:ds=192.168.4.1:\
:gw=192.168.4.1:\
:hd="/tftpboot":\
:bf="/kernel.diskless":\
:rp="192.168.4.4:/data/misc/diskless":
margaux:ha=0123456789ab:tc=.def100
Preparing a Boot Program with
EtherbootEtherbootEtherboot's Web
site contains
extensive documentation mainly intended for Linux
systems, but nonetheless containing useful information. The
following will just outline how you would use
Etherboot on a FreeBSD
system.You must first install the net/etherboot package or port.You can change the Etherboot
configuration (i.e. to use TFTP instead of
NFS) by editing the Config
file in the Etherboot source
directory.For our setup, we shall use a boot floppy. For other methods
(PROM, or &ms-dos; program), please refer to the
Etherboot documentation.To make a boot floppy, insert a floppy in the drive on the
machine where you installed Etherboot,
then change your current directory to the src
directory in the Etherboot tree and
type:
&prompt.root; gmake bin32/devicetype.fd0devicetype depends on the type of
the Ethernet card in the diskless workstation. Refer to the
NIC file in the same directory to determine the
right devicetype.Booting with PXEBy default, the &man.pxeboot.8; loader loads the kernel via
NFS. It can be compiled to use
TFTP instead by specifying the
LOADER_TFTP_SUPPORT option in
/etc/make.conf. See the comments in
/etc/defaults/make.conf (or
/usr/share/examples/etc/make.conf for 5.X
systems) for instructions.There are two other undocumented make.conf
options which may be useful for setting up a serial console diskless
machine: BOOT_PXELDR_PROBE_KEYBOARD, and
BOOT_PXELDR_ALWAYS_SERIAL (the latter only exists
on &os; 5.X).To use PXE when the machine starts, you will
usually need to select the Boot from network
option in your BIOS setup, or type a function key
during the PC initialization.Configuring the TFTP and NFS ServersTFTPdiskless operationNFSdiskless operationIf you are using PXE or
Etherboot configured to use
TFTP, you need to enable
tftpd on the file server:Create a directory from which tftpd
will serve the files, e.g. /tftpboot.Add this line to your
/etc/inetd.conf:tftp dgram udp wait root /usr/libexec/tftpd tftpd -l -s /tftpbootIt appears that at least some PXE versions want
the TCP version of TFTP. In this case, add a second line,
replacing dgram udp with stream
tcp.Tell inetd to reread its configuration
file:&prompt.root; kill -HUP `cat /var/run/inetd.pid`You can place the tftpboot
directory anywhere on the server. Make sure that the
location is set in both inetd.conf and
dhcpd.conf.In all cases, you also need to enable NFS and export the
- appropriate filesystem on the NFS server.
+ appropriate file system on the NFS server.
Add this to /etc/rc.conf:nfs_server_enable="YES"
- Export the filesystem where the diskless root directory
+ Export the file system where the diskless root directory
is located by adding the following to
/etc/exports (adjust the volume mount
point and replace margaux corbieres
with the names of the diskless workstations):/data/misc -alldirs -ro margaux corbieresTell mountd to reread its configuration
file. If you actually needed to enable NFS in
/etc/rc.conf
at the first step, you probably want to reboot instead.&prompt.root; kill -HUP `cat /var/run/mountd.pid`Building a Diskless Kerneldiskless operationkernel configurationIf using Etherboot, you need to
create a kernel configuration file for the diskless client
with the following options (in addition to the usual ones):
options BOOTP # Use BOOTP to obtain IP address/hostname
-options BOOTP_NFSROOT # NFS mount root filesystem using BOOTP info
+options BOOTP_NFSROOT # NFS mount root file system using BOOTP info
You may also want to use BOOTP_NFSV3,
BOOT_COMPAT and BOOTP_WIRED_TO
(refer to LINT in 4.X or
NOTES on 5.X).These option names are historical and slightly misleading as
they actually enable indifferent use of DHCP and
BOOTP inside the kernel (it is also possible to force strict BOOTP
or DHCP use).Build the kernel (see ),
and copy it to the place specified
in dhcpd.conf.When using PXE, building a kernel with the
above options is not strictly necessary (though suggested).
Enabling them will cause more DHCP requests to be
issued during kernel startup, with a small risk of inconsistency
between the new values and those retrieved by &man.pxeboot.8; in some
special cases. The advantage of using them is that the host name
will be set as a side effect. Otherwise you will need to set the
host name by another method, for example in a client-specific
rc.conf file.In order to be loadable with
Etherboot, a 5.X kernel needs to have
the device hints compiled in. You would typically set the
following option in the configuration file (see the
NOTES configuration comments file):hints "GENERIC.hints"Preparing the Root Filesystemroot file systemdiskless operation
- You need to create a root filesystem for the diskless
+ You need to create a root file system for the diskless
workstations, in the location listed as
root-path in
dhcpd.conf. The following sections describe
two ways to do it.Using the clone_root Script
- This is the quickest way to create a root filesystem, but
+ This is the quickest way to create a root file system, but
currently it is only supported on &os; 4.X. This shell script
is located at
/usr/share/examples/diskless/clone_root
and needs customization, at least to adjust
- the place where the filesystem will be created (the
+ the place where the file system will be created (the
DEST variable).Refer to the comments at the top of the script for
- instructions. They explain how the base filesystem is built,
+ instructions. They explain how the base file system is built,
and how files may be selectively overridden by versions specific
to diskless operation, to a subnetwork, or to an individual
workstation. They also give examples for the diskless
/etc/fstab and
/etc/rc.conf files.The README files in
/usr/share/examples/diskless contain a lot
of interesting background information, but, together with the
other examples in the diskless directory,
they actually document a configuration method which is distinct
from the one used by clone_root and
the system startup scripts in
/etc, which is a little
confusing. Use them for reference only, except if you prefer
the method that they describe, in which case you will need
customized rc scripts.Using the Standard make world
ProcedureThis method can be applied to either &os; 4.X or 5.X and
- will install a complete virgin system (not only the root filesystem)
+ will install a complete virgin system (not only the root file system)
into DESTDIR.
All you have to do is simply execute the following script:#!/bin/sh
export DESTDIR=/data/misc/diskless
mkdir -p ${DESTDIR}
cd /usr/src; make world && make kernel
cd /usr/src/etc; make distributionOnce done, you may need to customize your
/etc/rc.conf and
/etc/fstab placed into
DESTDIR according to your needs.Configuring SwapIf needed, a swap file located on the server can be
accessed via NFS. One of the methods commonly
used to do this has been discontinued in release 5.X.NFS Swap with &os; 4.XThe swap file location and size can be specified with
BOOTP/DHCP &os;-specific options 128 and 129.
Examples of configuration files for
ISC DHCP 3.0 or
bootpd follow:Add the following lines to
dhcpd.conf:
# Global section
option swap-path code 128 = string;
option swap-size code 129 = integer 32;
host margaux {
... # Standard lines, see above
option swap-path "192.168.4.4:/netswapvolume/netswap";
option swap-size 64000;
}
swap-path is the path to a directory
where swap files will be located. Each file will be named
swap.client-ip.Older versions of dhcpd used a syntax of
option option-128 "..., which is no
longer supported./etc/bootptab would use the
following syntax instead:T128="192.168.4.4:/netswapvolume/netswap":T129=0000fa00In /etc/bootptab, the swap
size must be expressed in hexadecimal format.On the NFS swap file server, create the swap
file(s):
&prompt.root; mkdir /netswapvolume/netswap
&prompt.root; cd /netswapvolume/netswap
&prompt.root; dd if=/dev/zero bs=1024 count=64000 of=swap.192.168.4.6
&prompt.root; chmod 0600 swap.192.168.4.6192.168.4.6 is the IP address
for the diskless client.On the NFS swap file server, add the following line to
/etc/exports:/netswapvolume -maproot=0:10 -alldirs margaux corbieresThen tell mountd to reread the
exports file, as above.NFS Swap with &os 5.XThe kernel does not support enabling NFS
swap at boot time. Swap must be enabled by the startup scripts,
by mounting a writeable file system and creating and enabling a
swap file. To create a swap file of appropriate size, you can do
like this:&prompt.root; dd if=/dev/zero of=/path/to/swapfile bs=1k count=1 oseek=100000To enable it you have to add the following line to your
rc.conf:swapfile=/path/to/swapfileMiscellaneous IssuesRunning with a Read-only /usrdiskless operation/usr read-onlyIf the diskless workstation is configured to run X, you
will have to adjust the XDM configuration file, which puts
the error log on /usr by default.Using a Non-FreeBSD Server
- When the server for the root filesystem is not running FreeBSD,
- you will have to create the root filesystem on a
+ When the server for the root file system is not running FreeBSD,
+ you will have to create the root file system on a
FreeBSD machine, then copy it to its destination, using
tar or cpio.In this situation, there are sometimes
problems with the special files in /dev,
due to differing major/minor integer sizes. A solution to this
problem is to export a directory from the non-FreeBSD server,
mount this directory onto a FreeBSD machine, and run
MAKEDEV on the FreeBSD machine
to create the correct device entries (FreeBSD 5.0 and later
use &man.devfs.5; to allocate device nodes transparently for
the user, running MAKEDEV on these
versions is pointless).ISDNISDNA good resource for information on ISDN technology and hardware is
Dan Kegel's ISDN
Page.A quick simple road map to ISDN follows:If you live in Europe you might want to investigate the ISDN card
section.If you are planning to use ISDN primarily to connect to the
Internet with an Internet Provider on a dial-up non-dedicated basis,
you might look into Terminal Adapters. This will give you the
most flexibility, with the fewest problems, if you change
providers.If you are connecting two LANs together, or connecting to the
Internet with a dedicated ISDN connection, you might consider
the stand alone router/bridge option.Cost is a significant factor in determining what solution you will
choose. The following options are listed from least expensive to most
expensive.HellmuthMichaelisContributed by ISDN CardsISDNcardsFreeBSD's ISDN implementation supports only the DSS1/Q.931
(or Euro-ISDN) standard using passive cards. Starting with
FreeBSD 4.4, some active cards are supported where the firmware
also supports other signaling protocols; this also includes the
first supported Primary Rate (PRI) ISDN card.The isdn4bsd software allows you to connect
to other ISDN routers using either IP over raw HDLC or by using
synchronous PPP: either by using kernel PPP with isppp, a
modified &man.sppp.4; driver, or by using userland &man.ppp.8;. By using
userland &man.ppp.8;, channel bonding of two or more ISDN
B-channels is possible. A telephone answering machine
application is also available as well as many utilities such as
a software 300 Baud modem.Some growing number of PC ISDN cards are supported under
FreeBSD and the reports show that it is successfully used all
over Europe and in many other parts of the world.The passive ISDN cards supported are mostly the ones with
the Infineon (formerly Siemens) ISAC/HSCX/IPAC ISDN chipsets,
but also ISDN cards with chips from Cologne Chip (ISA bus only),
PCI cards with Winbond W6692 chips, some cards with the
Tiger300/320/ISAC chipset combinations and some vendor specific
chipset based cards such as the AVM Fritz!Card PCI V.1.0 and the
AVM Fritz!Card PnP.Currently the active supported ISDN cards are the AVM B1
(ISA and PCI) BRI cards and the AVM T1 PCI PRI cards.For documentation on isdn4bsd,
have a look at /usr/share/examples/isdn/
directory on your FreeBSD system or at the homepage of
isdn4bsd which also has pointers to hints, erratas and
much more documentation such as the isdn4bsd
handbook.In case you are interested in adding support for a
different ISDN protocol, a currently unsupported ISDN PC card or
otherwise enhancing isdn4bsd, please
get in touch with &a.hm;.For questions regarding the installation, configuration
and troubleshooting isdn4bsd, a
&a.isdn.name; mailing list is available.ISDN Terminal AdaptersTerminal adapters (TA), are to ISDN what modems are to regular
phone lines.modemMost TA's use the standard Hayes modem AT command set, and can be
used as a drop in replacement for a modem.A TA will operate basically the same as a modem except connection
and throughput speeds will be much faster than your old modem. You
will need to configure PPP exactly the same
as for a modem setup. Make sure you set your serial speed as high as
possible.PPPThe main advantage of using a TA to connect to an Internet
Provider is that you can do Dynamic PPP. As IP address space becomes
more and more scarce, most providers are not willing to provide you
with a static IP anymore. Most stand-alone routers are not able to
accommodate dynamic IP allocation.TA's completely rely on the PPP daemon that you are running for
their features and stability of connection. This allows you to
upgrade easily from using a modem to ISDN on a FreeBSD machine, if you
already have PPP set up. However, at the same time any problems you
experienced with the PPP program and are going to persist.If you want maximum stability, use the kernel PPP option, not the userland PPP.The following TA's are known to work with FreeBSD:Motorola BitSurfer and Bitsurfer ProAdtranMost other TA's will probably work as well, TA vendors try to make
sure their product can accept most of the standard modem AT command
set.The real problem with external TA's is that, like modems,
you need a good serial card in your computer.You should read the FreeBSD Serial
Hardware tutorial for a detailed understanding of
serial devices, and the differences between asynchronous and
synchronous serial ports.A TA running off a standard PC serial port (asynchronous) limits
you to 115.2 Kbs, even though you have a 128 Kbs connection.
To fully utilize the 128 Kbs that ISDN is capable of,
you must move the TA to a synchronous serial card.Do not be fooled into buying an internal TA and thinking you have
avoided the synchronous/asynchronous issue. Internal TA's simply have
a standard PC serial port chip built into them. All this will do is
save you having to buy another serial cable and find another empty
electrical socket.A synchronous card with a TA is at least as fast as a stand-alone
router, and with a simple 386 FreeBSD box driving it, probably more
flexible.The choice of synchronous card/TA v.s. stand-alone router is largely a
religious issue. There has been some discussion of this in
the mailing lists. We suggest you search the archives for
the complete discussion.Stand-alone ISDN Bridges/RoutersISDNstand-alone bridges/routersISDN bridges or routers are not at all specific to FreeBSD
or any other operating system. For a more complete
description of routing and bridging technology, please refer
to a networking reference book.In the context of this section, the terms router and bridge will
be used interchangeably.As the cost of low end ISDN routers/bridges comes down, it
will likely become a more and more popular choice. An ISDN
router is a small box that plugs directly into your local
Ethernet network, and manages its own connection to the other
bridge/router. It has built in software to communicate via
PPP and other popular protocols.A router will allow you much faster throughput than a
standard TA, since it will be using a full synchronous ISDN
connection.The main problem with ISDN routers and bridges is that
interoperability between manufacturers can still be a problem.
If you are planning to connect to an Internet provider, you
should discuss your needs with them.If you are planning to connect two LAN segments together,
such as your home LAN to the office LAN, this is the simplest
lowest
maintenance solution. Since you are buying the equipment for
both sides of the connection you can be assured that the link
will work.For example to connect a home computer or branch office
network to a head office network the following setup could be
used:Branch Office or Home Network10 base 2Network uses a bus based topology with 10 base 2
Ethernet (thinnet). Connect router to network cable with
AUI/10BT transceiver, if necessary.---Sun workstation
|
---FreeBSD box
|
---Windows 95
|
Stand-alone router
|
ISDN BRI line10 Base 2 EthernetIf your home/branch office is only one computer you can use a
twisted pair crossover cable to connect to the stand-alone router
directly.Head Office or Other LAN10 base TNetwork uses a star topology with 10 base T Ethernet
(Twisted Pair). -------Novell Server
| H |
| ---Sun
| |
| U ---FreeBSD
| |
| ---Windows 95
| B |
|___---Stand-alone router
|
ISDN BRI lineISDN Network DiagramOne large advantage of most routers/bridges is that they allow you
to have 2 separate independent PPP connections to
2 separate sites at the same time. This is not
supported on most TA's, except for specific (usually expensive) models
that
have two serial ports. Do not confuse this with channel bonding, MPP,
etc.This can be a very useful feature if, for example, you
have an dedicated ISDN connection at your office and would
like to tap into it, but do not want to get another ISDN line
at work. A router at the office location can manage a
dedicated B channel connection (64 Kbps) to the Internet
and use the other B channel for a separate data connection.
The second B channel can be used for dial-in, dial-out or
dynamically bonding (MPP, etc.) with the first B channel for
more bandwidth.IPX/SPXAn Ethernet bridge will also allow you to transmit more than just
IP traffic. You can also send IPX/SPX or whatever other protocols you
use.ChernLeeContributed by Network Address TranslationOverviewnatdFreeBSD's Network Address Translation daemon, commonly known as
&man.natd.8; is a daemon that accepts incoming raw IP packets,
changes the source to the local machine and re-injects these packets
back into the outgoing IP packet stream. &man.natd.8; does this by changing
the source IP address and port such that when data is received back,
it is able to determine the original location of the data and forward
it back to its original requester.Internet connection sharingNATThe most common use of NAT is to perform what is commonly known as
Internet Connection Sharing.SetupDue to the diminishing IP space in IPv4, and the increased number
of users on high-speed consumer lines such as cable or DSL, people are
increasingly in need of an Internet Connection Sharing solution. The
ability to connect several computers online through one connection and
IP address makes &man.natd.8; a reasonable choice.Most commonly, a user has a machine connected to a cable or DSL
line with one IP address and wishes to use this one connected computer to
provide Internet access to several more over a LAN.To do this, the FreeBSD machine on the Internet must act as a
gateway. This gateway machine must have two NICs—one for connecting
to the Internet router, the other connecting to a LAN. All the
machines on the LAN are connected through a hub or switch. _______ __________ ________
| | | | | |
| Hub |-----| Client B |-----| Router |----- Internet
|_______| |__________| |________|
|
____|_____
| |
| Client A |
|__________|Network LayoutA setup like this is commonly used to share an Internet
connection. One of the LAN machines is
connected to the Internet. The rest of the machines access
the Internet through that gateway
machine.kernelconfigurationConfigurationThe following options must be in the kernel configuration
file:options IPFIREWALL
options IPDIVERTAdditionally, at choice, the following may also be suitable:options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPFIREWALL_VERBOSEThe following must be in /etc/rc.conf:gateway_enable="YES"
firewall_enable="YES"
firewall_type="OPEN"
natd_enable="YES"
natd_interface="fxp0"
natd_flags="" Sets up the machine to act as a gateway. Running
sysctl net.inet.ip.forwarding=1 would
have the same effect.Enables the firewall rules in
/etc/rc.firewall at boot.This specifies a predefined firewall ruleset that
allows anything in. See
/etc/rc.firewall for additional
types.Indicates which interface to forward packets through
(the interface connected to the Internet).Any additional configuration options passed to
&man.natd.8; on boot.Having the previous options defined in
/etc/rc.conf would run
natd -interface fxp0 at boot. This can also
be run manually.It is also possible to use a configuration file for
&man.natd.8; when there are too many options to pass. In this
case, the configuration file must be defined by adding the
following line to /etc/rc.conf:natd_flags="-f /etc/natd.conf"The /etc/natd.conf file will
contain a list of configuration options, one per line. For
example the next section case would use the following
file:redirect_port tcp 192.168.0.2:6667 6667
redirect_port tcp 192.168.0.3:80 80For more information about the configuration file,
consult the &man.natd.8; manual page about the
option.Each machine and interface behind the LAN should be
assigned IP address numbers in the private network space as
defined by RFC 1918
and have a default gateway of the natd machine's internal IP
address.For example, client A and
B behind the LAN have IP addresses of 192.168.0.2 and 192.168.0.3, while the natd machine's
LAN interface has an IP address of 192.168.0.1. Client A
and B's default gateway must be set to that
of the natd machine, 192.168.0.1. The natd machine's
external, or Internet interface does not require any special
modification for &man.natd.8; to work.Port RedirectionThe drawback with &man.natd.8; is that the LAN clients are not accessible
from the Internet. Clients on the LAN can make outgoing connections to
the world but cannot receive incoming ones. This presents a problem
if trying to run Internet services on one of the LAN client machines.
A simple way around this is to redirect selected Internet ports on the
natd machine to a LAN client.
For example, an IRC server runs on client A, and a web server runs
on client B. For this to work properly, connections received on ports
6667 (IRC) and 80 (web) must be redirected to the respective machines.
The must be passed to
&man.natd.8; with the proper options. The syntax is as follows: -redirect_port proto targetIP:targetPORT[-targetPORT]
[aliasIP:]aliasPORT[-aliasPORT]
[remoteIP[:remotePORT[-remotePORT]]]In the above example, the argument should be: -redirect_port tcp 192.168.0.2:6667 6667
-redirect_port tcp 192.168.0.3:80 80
This will redirect the proper tcp ports to the
LAN client machines.
The argument can be used to indicate port
ranges over individual ports. For example, tcp
192.168.0.2:2000-3000 2000-3000 would redirect
all connections received on ports 2000 to 3000 to ports 2000
to 3000 on client A.These options can be used when directly running
&man.natd.8;, placed within the
natd_flags="" option in
/etc/rc.conf,
or passed via a configuration file.For further configuration options, consult &man.natd.8;Address Redirectionaddress redirectionAddress redirection is useful if several IP addresses are
available, yet they must be on one machine. With this,
&man.natd.8; can assign each LAN client its own external IP address.
&man.natd.8; then rewrites outgoing packets from the LAN clients
with the proper external IP address and redirects
all traffic incoming on that particular IP address back to
the specific LAN client. This is also known as static NAT.
For example, the IP addresses 128.1.1.1,
128.1.1.2, and
128.1.1.3 belong to the natd gateway
machine. 128.1.1.1 can be used
as the natd gateway machine's external IP address, while
128.1.1.2 and
128.1.1.3 are forwarded back to LAN
clients A and B.The syntax is as follows:-redirect_address localIP publicIPlocalIPThe internal IP address of the LAN client.publicIPThe external IP address corresponding to the LAN client.In the example, this argument would read:-redirect_address 192.168.0.2 128.1.1.2
-redirect_address 192.168.0.3 128.1.1.3Like , these arguments are also placed within
the natd_flags="" option of /etc/rc.conf, or passed via a configuration file. With address
redirection, there is no need for port redirection since all data
received on a particular IP address is redirected.The external IP addresses on the natd machine must be active and aliased
to the external interface. Look at &man.rc.conf.5; to do so.Parallel Line IP (PLIP)PLIPParallel Line IPPLIPPLIP lets us run TCP/IP between parallel ports. It is
useful on machines without network cards, or to install on
laptops. In this section, we will discuss:Creating a parallel (laplink) cable.Connecting two computers with PLIP.Creating a Parallel CableYou can purchase a parallel cable at most computer supply
stores. If you cannot do that, or you just want to know how
it is done, the following table shows how to make one out of a normal parallel
printer cable.
Setting Up PLIPFirst, you have to get a laplink cable.
Then, confirm that both computers have a kernel with &man.lpt.4; driver
support:&prompt.root; grep lp /var/run/dmesg.boot
lpt0: <Printer> on ppbus0
lpt0: Interrupt-driven portThe parallel port must be an interrupt driven port, under
&os; 4.X, you should have a line similar to the
following in your kernel configuration file:device ppc0 at isa? irq 7Under &os; 5.X, the
/boot/device.hints file should contain the
following lines:hint.ppc.0.at="isa"
hint.ppc.0.irq="7"Then check if the kernel configuration file has a
device plip line or if the
plip.ko kernel module is loaded. In both
cases the parallel networking interface should appear when you
directly use the &man.ifconfig.8; command. Under
&os; 4.X like this:&prompt.root; ifconfig lp0
lp0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500and for &os; 5.X:&prompt.root; ifconfig plip0
plip0: flags=8810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500The device name used for parallel interface is
different between &os; 4.X
(lpX)
and &os; 5.X
(plipX).Plug in the laplink cable into the parallel interface on
both computers.Configure the network interface parameters on both
sites as root. For example, if you want connect
the host host1 running &os; 4.X with host2 running &os; 5.X: host1 <-----> host2
IP Address 10.0.0.1 10.0.0.2Configure the interface on host1 by doing:&prompt.root; ifconfig lp0 10.0.0.1 10.0.0.2Configure the interface on host2 by doing:&prompt.root; ifconfig plip0 10.0.0.2 10.0.0.1You now should have a working connection. Please read the
manual pages &man.lp.4; and &man.lpt.4; for more details.You should also add both hosts to
/etc/hosts:127.0.0.1 localhost.my.domain localhost
10.0.0.1 host1.my.domain host1
10.0.0.2 host2.my.domainTo confirm the connection works, go to each host and ping
the other. For example, on host1:&prompt.root; ifconfig lp0
lp0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 10.0.0.1 --> 10.0.0.2 netmask 0xff000000
&prompt.root; netstat -r
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
host2 host1 UH 0 0 lp0
&prompt.root; ping -c 4 host2
PING host2 (10.0.0.2): 56 data bytes
64 bytes from 10.0.0.2: icmp_seq=0 ttl=255 time=2.774 ms
64 bytes from 10.0.0.2: icmp_seq=1 ttl=255 time=2.530 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=255 time=2.556 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=255 time=2.714 ms
--- host2 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 msAaronKaplanOriginally Written by TomRhodesRestructured and Added by BradDavisExtended by IPv6IPv6 (also know as IPng IP next generation) is
the new version of the well known IP protocol (also know as
IPv4). Like the other current *BSD systems,
FreeBSD includes the KAME IPv6 reference implementation.
So your FreeBSD system comes with all you will need to experiment with IPv6.
This section focuses on getting IPv6 configured and running.In the early 1990s, people became aware of the rapidly
diminishing address space of IPv4. Given the expansion rate of the
Internet there were two major concerns:Running out of addresses. Today this is not so much of a concern
anymore since private address spaces
(10.0.0.0/8,
192.168.0.0/24,
etc.) and Network Address Translation (NAT) are
being employed.Router table entries were getting too large. This is
still a concern today.IPv6 deals with these and many other issues:128 bit address space. In other words theoretically there are
340,282,366,920,938,463,463,374,607,431,768,211,456 addresses
available. This means there are approximately
6.67 * 10^27 IPv6 addresses per square meter on our planet.Routers will only store network aggregation addresses in their routing
tables thus reducing the average space of a routing table to 8192
entries.There are also lots of other useful features of IPv6 such as:Address autoconfiguration (RFC2462)Anycast addresses (one-out-of many)Mandatory multicast addressesIPsec (IP security)Simplified header structureMobile IPIPv6-to-IPv4 transition mechanismsFor more information see:IPv6 overview at playground.sun.comKAME.net6bone.netBackground on IPv6 AddressesThere are different types of IPv6 addresses: Unicast, Anycast and
Multicast.Unicast addresses are the well known addresses. A packet sent
to a unicast address arrives exactly at the interface belonging to
the address.Anycast addresses are syntactically indistinguishable from unicast
addresses but they address a group of interfaces. The packet destined for
an anycast address will arrive at the nearest (in router metric)
interface. Anycast addresses may only be used by routers.Multicast addresses identify a group of interfaces. A packet destined
for a multicast address will arrive at all interfaces belonging to the
multicast group.The IPv4 broadcast address (usually xxx.xxx.xxx.255) is expressed
by multicast addresses in IPv6.
Reserved IPv6 addressesIPv6 addressPrefixlength (Bits)DescriptionNotes::128 bitsunspecifiedcf. 0.0.0.0 in
IPv4::1128 bitsloopback addresscf. 127.0.0.1 in
IPv4::00:xx:xx:xx:xx96 bitsembedded IPv4The lower 32 bits are the IPv4 address. Also
called IPv4 compatible IPv6
address::ff:xx:xx:xx:xx96 bitsIPv4 mapped IPv6 addressThe lower 32 bits are the IPv4 address.
For hosts which do not support IPv6.fe80:: - feb::10 bitslink-localcf. loopback address in IPv4fec0:: - fef::10 bitssite-localff::8 bitsmulticast001 (base
2)3 bitsglobal unicastAll global unicast addresses are assigned from
this pool. The first 3 bits are
001.
Reading IPv6 AddressesThe canonical form is represented as: x:x:x:x:x:x:x:x, each
x being a 16 Bit hex value. For example
FEBC:A574:382B:23C1:AA49:4592:4EFE:9982Often an address will have long substrings of all zeros
therefore one such substring per address can be abbreviated by ::.
Also up to three leading 0s per hexquad can be omitted.
For example fe80::1
corresponds to the canonical form
fe80:0000:0000:0000:0000:0000:0000:0001.A third form is to write the last 32 Bit part in the
well known (decimal) IPv4 style with dots .
as separators. For example
2002::10.0.0.1
corresponds to the (hexadecimal) canonical representation
2002:0000:0000:0000:0000:0000:0a00:0001
which in turn is equivalent to
writing 2002::a00:1.By now the reader should be able to understand the following:&prompt.root; ifconfigrl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
inet 10.0.0.10 netmask 0xffffff00 broadcast 10.0.0.255
inet6 fe80::200:21ff:fe03:8e1%rl0 prefixlen 64 scopeid 0x1
ether 00:00:21:03:08:e1
media: Ethernet autoselect (100baseTX )
status: activefe80::200:21ff:fe03:8e1%rl0
is an auto configured link-local address. It is generated from the MAC
address as part of the auto configuration.For further information on the structure of IPv6 addresses
see RFC3513.Getting ConnectedCurrently there are four ways to connect to other IPv6 hosts and networks:Join the experimental 6boneGetting an IPv6 network from your upstream provider. Talk to your
Internet provider for instructions.Tunnel via 6-to-4 (RFC3068)Use the net/freenet6 port if you are on a dial-up connection.Here we will talk on how to connect to the 6bone since it currently seems
to be the most popular way.First take a look at the 6bone site and find a 6bone connection nearest to
you. Write to the responsible person and with a little bit of luck you
will be given instructions on how to set up your connection. Usually this
involves setting up a GRE (gif) tunnel.Here is a typical example on setting up a &man.gif.4; tunnel:&prompt.root; ifconfig gif0 create
&prompt.root; ifconfig gif0
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
&prompt.root; ifconfig gif0 tunnel MY_IPv4_ADDRHIS_IPv4_ADDR
&prompt.root; ifconfig gif0 inet6 alias MY_ASSIGNED_IPv6_TUNNEL_ENDPOINT_ADDRReplace the capitalized words by the information you received from the
upstream 6bone node.This establishes the tunnel. Check if the tunnel is working by &man.ping6.8;
'ing ff02::1%gif0. You should receive two ping replies.In case you are intrigued by the address ff02:1%gif0, this is a
multicast address. %gif0 states that the multicast address at network
interface gif0 is to be used. Since we ping a multicast address the
other endpoint of the tunnel should reply as well.By now setting up a route to your 6bone uplink should be rather
straightforward:&prompt.root; route add -inet6 default -interface gif0
&prompt.root; ping6 -n MY_UPLINK&prompt.root; traceroute6 www.jp.FreeBSD.org
(3ffe:505:2008:1:2a0:24ff:fe57:e561) from 3ffe:8060:100::40:2, 30 hops max, 12 byte packets
1 atnet-meta6 14.147 ms 15.499 ms 24.319 ms
2 6bone-gw2-ATNET-NT.ipv6.tilab.com 103.408 ms 95.072 ms *
3 3ffe:1831:0:ffff::4 138.645 ms 134.437 ms 144.257 ms
4 3ffe:1810:0:6:290:27ff:fe79:7677 282.975 ms 278.666 ms 292.811 ms
5 3ffe:1800:0:ff00::4 400.131 ms 396.324 ms 394.769 ms
6 3ffe:1800:0:3:290:27ff:fe14:cdee 394.712 ms 397.19 ms 394.102 msThis output will differ from machine to machine. By now you should be
able to reach the IPv6 site www.kame.net
and see the dancing tortoise — that is if you have a IPv6 enabled browser such as
www/mozilla, Konqueror,
which is part of x11/kdebase3,
or www/epiphany.DNS in the IPv6 WorldThere used to be two types of DNS records for IPv6. The IETF
has declared A6 records obsolete. AAAA records are the standard
now.Using AAAA records is straightforward. Assign your hostname to the new
IPv6 address you just received by adding:MYHOSTNAME AAAA MYIPv6ADDRTo your primary zone DNS file. In case you do not serve your own
DNS zones ask your DNS provider.
Current versions of bind (version 8.3 and 9)
and dns/djbdns (with the IPv6 patch)
support AAAA records.Applying the needed changes to /etc/rc.confIPv6 Client SettingsThese settings will help you configure a machine that will be on
your LAN and act as a client, not a router. To have &man.rtsol.8;
autoconfigure your interface on boot all you need to add is:ipv6_enable="YES"To statically assign an IP address such as
2001:471:1f11:251:290:27ff:fee0:2093, to your
fxp0 interface, add:ipv6_ifconfig_fxp0="2001:471:1f11:251:290:27ff:fee0:2093"To assign a default router of
2001:471:1f11:251::1
add the following to /etc/rc.conf:ipv6_defaultrouter="2001:471:1f11:251::1"IPv6 Router/Gateway SettingsThis will help you take the directions that your tunnel provider,
such as the 6bone, has
given you and convert it into settings that will persist through reboots.
To restore your tunnel on startup use something like the following in
/etc/rc.conf:List the Generic Tunneling interfaces that will be configured, for
example gif0:gif_interfaces="gif0"To configure the interface with a local endpoint of
MY_IPv4_ADDR to a remote endpoint of
REMOTE_IPv4_ADDR:gifconfig_gif0="MY_IPv4_ADDR REMOTE_IPv4_ADDR"To apply the IPv6 address you have been assigned for use as your
IPv6 tunnel endpoint, add:ipv6_ifconfig_gif0="MY_ASSIGNED_IPv6_TUNNEL_ENDPOINT_ADDR"Then all you have to do is set the default route for IPv6. This is
the other side of the IPv6 tunnel:ipv6_defaultrouter="MY_IPv6_REMOTE_TUNNEL_ENDPOINT_ADDR"IPv6 Tunnel SettingsIf the server is to route IPv6 between the rest of your network
and the world, the following /etc/rc.conf
setting will also be needed:ipv6_gateway_enable="YES"Router Advertisement and Host Auto ConfigurationThis section will help you setup &man.rtadvd.8; to advertise the
IPv6 default route.To enable &man.rtadvd.8; you will need the following in your
/etc/rc.conf:rtadvd_enable="YES"It is important that you specify the interface on which to do
IPv6 router solicitation. For example to tell &man.rtadvd.8; to use
fxp0:rtadvd_interfaces="fxp0"Now we must create the configuration file,
/etc/rtadvd.conf. Here is an example:fxp0:\
:addrs#1:addr="2001:471:1f11:246::":prefixlen#64:tc=ether:Replace fxp0 with the interface you
are going to be using.Next, replace 2001:471:1f11:246::
with the prefix of your allocation.If you are dedicated a /64 subnet
you will not need to change anything else. Otherwise, you will need to
change the prefixlen# to the correct value.HartiBrandtContributed by Asynchronous Transfer Mode (ATM) on &os; 5.XConfiguring classical IP over ATM (PVCs)Classical IP over ATM (CLIP) is the
simplest method to use Asynchronous Transfer Mode (ATM)
with IP. It can be used with
switched connections (SVCs) and with permanent connections
(PVCs). This section describes how to set up a network based
on PVCs.Fully meshed configurationsThe first method to set up a CLIP with
PVCs is to connect each machine to each other machine in the
network via a dedicated PVC. While this is simple to
configure it tends to become impractical for a larger number
of machines. The example supposes that we have four
machines in the network, each connected to the ATM network
with an ATM adapter card. The first step is the planning of
the IP addresses and the ATM connections between the
machines. We use the following:HostIP AddresshostA192.168.173.1hostB192.168.173.2hostC192.168.173.3hostD192.168.173.4To build a fully meshed net we need one ATM connection
between each pair of machines:MachinesVPI.VCI couplehostA - hostB0.100hostA - hostC0.101hostA - hostD0.102hostB - hostC0.103hostB - hostD0.104hostC - hostD0.105The VPI and VCI values at each end of the connection may
of course differ, but for simplicity we assume that they are
the same. Next we need to configure the ATM interfaces on
each host:hostA&prompt.root; ifconfig hatm0 192.168.173.1 up
hostB&prompt.root; ifconfig hatm0 192.168.173.2 up
hostC&prompt.root; ifconfig hatm0 192.168.173.3 up
hostD&prompt.root; ifconfig hatm0 192.168.173.4 upassuming that the ATM interface is
hatm0 on all hosts. Now the PVCs
need to be configured on hostA (we assume that
they are already configured on the ATM switches, you need to
consult the manual for the switch on how to do this).hostA&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 100 llc/snap ubr
hostA&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 101 llc/snap ubr
hostA&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 102 llc/snap ubr
hostB&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 100 llc/snap ubr
hostB&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 103 llc/snap ubr
hostB&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 104 llc/snap ubr
hostC&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 101 llc/snap ubr
hostC&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 103 llc/snap ubr
hostC&prompt.root; atmconfig natm add 192.168.173.4 hatm0 0 105 llc/snap ubr
hostD&prompt.root; atmconfig natm add 192.168.173.1 hatm0 0 102 llc/snap ubr
hostD&prompt.root; atmconfig natm add 192.168.173.2 hatm0 0 104 llc/snap ubr
hostD&prompt.root; atmconfig natm add 192.168.173.3 hatm0 0 105 llc/snap ubrOf course other traffic contracts than UBR can be used
given the ATM adapter supports those. In this case the name
of the traffic contract is followed by the parameters of the
traffic. Help for the &man.atmconfig.8; tool can be
obtained with:&prompt.root; atmconfig help natm addor in the &man.atmconfig.8; manual page.The same configuration can also be done via
/etc/rc.conf.
For hostA this would look like:network_interfaces="lo0 hatm0"
ifconfig_hatm0="inet 192.168.173.1 up"
natm_static_routes="hostB hostC hostD"
route_hostB="192.168.173.2 hatm0 0 100 llc/snap ubr"
route_hostC="192.168.173.3 hatm0 0 101 llc/snap ubr"
route_hostD="192.168.173.4 hatm0 0 102 llc/snap ubr"The current state of all CLIP routes
can be obtained with:hostA&prompt.root; atmconfig natm show
diff --git a/en_US.ISO8859-1/books/handbook/book.sgml b/en_US.ISO8859-1/books/handbook/book.sgml
index 069a8afe5d..8e057f69d0 100644
--- a/en_US.ISO8859-1/books/handbook/book.sgml
+++ b/en_US.ISO8859-1/books/handbook/book.sgml
@@ -1,336 +1,338 @@
%books.ent;
%chapters;
%txtfiles;
+
%pgpkeys;
]>
FreeBSD HandbookThe FreeBSD Documentation ProjectFebruary 199919951996199719981999200020012002200320042005The FreeBSD Documentation Project
&bookinfo.legalnotice;
&tm-attrib.freebsd;
&tm-attrib.3com;
&tm-attrib.3ware;
&tm-attrib.arm;
&tm-attrib.adaptec;
&tm-attrib.adobe;
&tm-attrib.apple;
&tm-attrib.corel;
&tm-attrib.creative;
&tm-attrib.cvsup;
&tm-attrib.heidelberger;
&tm-attrib.ibm;
&tm-attrib.ieee;
&tm-attrib.intel;
&tm-attrib.intuit;
&tm-attrib.linux;
&tm-attrib.lsilogic;
&tm-attrib.m-systems;
&tm-attrib.macromedia;
&tm-attrib.microsoft;
&tm-attrib.netscape;
&tm-attrib.nexthop;
&tm-attrib.opengroup;
&tm-attrib.oracle;
&tm-attrib.powerquest;
&tm-attrib.realnetworks;
&tm-attrib.redhat;
&tm-attrib.sap;
&tm-attrib.sun;
&tm-attrib.symantec;
&tm-attrib.themathworks;
&tm-attrib.thomson;
&tm-attrib.usrobotics;
&tm-attrib.vmware;
&tm-attrib.waterloomaple;
&tm-attrib.wolframresearch;
&tm-attrib.xfree86;
&tm-attrib.xiph;
&tm-attrib.general;
Welcome to FreeBSD! This handbook covers the installation and day
to day use of FreeBSD &rel2.current;-RELEASE
and FreeBSD &rel.current;-RELEASE.
This manual is a work in progress and is the work
of many individuals. Many sections do not yet exist and some of those
that do exist need to be updated. If you are interested in helping
with this project, send email to the &a.doc;. The latest version of
this document is always available from the FreeBSD web site.
It may also be downloaded in a variety of formats and compression
options from the FreeBSD FTP
server or one of the numerous mirror sites. If you would prefer
to have a hard copy of the handbook, you can purchase one at the
FreeBSD Mall. You
may also want to search the
handbook.
&chap.preface;
Getting StartedThis part of the FreeBSD Handbook is for users and
administrators who are new to FreeBSD. These chapters:Introduce you to FreeBSD.Guide you through the installation process.Teach you &unix; basics and fundamentals.Show you how to install the wealth of third party
applications available for FreeBSD.Introduce you to X, the &unix; windowing system, and
detail how to configure a desktop environment that makes you
more productive.We have tried to keep the number of forward references in
the text to a minimum so that you can read this section of the
Handbook from front to back with the minimum page flipping
required.Common TasksNow that the basics have been covered, this part of the
FreeBSD Handbook will discuss some frequently used features of
FreeBSD. These chapters:Introduce you to popular and useful desktop
applications: browsers, productivity tools, document
viewers, etc.Introduce you to a number of multimedia tools
available for FreeBSD.Explain the process of building a customized FreeBSD
kernel, to enable extra functionality on your system.Describe the print system in detail, both for desktop
and network-connected printer setups.Show you how to run Linux applications on your FreeBSD
system.Some of these chapters recommend that you do some prior
reading, and this is noted in the synopsis at the beginning of
each chapter.System AdministrationThe remaining chapters of the FreeBSD Handbook cover all
aspects of FreeBSD system administration. Each chapter
starts by describing what you will learn as a result of reading
the chapter, and also details what you are expected to know
before tackling the material.These chapters are designed to be read when
you need the information. You do not have to read them in any
particular order, nor do you need to read all of them before you
can begin using FreeBSD.
+
Network CommunicationFreeBSD is one of the most widely deployed operating
systems for high performance network servers. The chapters in
this part cover:Serial communicationPPP and PPP over EthernetElectronic MailRunning Network ServersFirewallsOther Advanced Networking TopicsThese chapters are designed to be read when
you need the information. You do not have to read them in any
particular order, nor do you need to read all of them before you
can begin using FreeBSD in a network environment.Appendices
&chap.colophon;
diff --git a/en_US.ISO8859-1/books/handbook/chapters.ent b/en_US.ISO8859-1/books/handbook/chapters.ent
index 6585365fd0..81f08c8170 100644
--- a/en_US.ISO8859-1/books/handbook/chapters.ent
+++ b/en_US.ISO8859-1/books/handbook/chapters.ent
@@ -1,57 +1,58 @@
+