svn commit: r44158 - head/en_US.ISO8859-1/books/handbook/advanced-networking

Dru Lavigne dru at FreeBSD.org
Thu Mar 6 19:16:24 UTC 2014


Author: dru
Date: Thu Mar  6 19:16:24 2014
New Revision: 44158
URL: http://svnweb.freebsd.org/changeset/doc/44158

Log:
  White space fix only. Translators can ignore.
  
  Sponsored by: iXsystems

Modified:
  head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml

Modified: head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml	Thu Mar  6 18:47:05 2014	(r44157)
+++ head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml	Thu Mar  6 19:16:24 2014	(r44158)
@@ -2216,19 +2216,18 @@ freebsdap       00:11:95:c3:0d:ac    1  
       <primary>Bluetooth</primary>
     </indexterm>
 
-      <para>Bluetooth 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 Wi-Fi wireless technology, Bluetooth offers
-	higher level service profiles, such as <acronym>FTP</acronym>-like file servers,
-	file pushing, voice transport, serial line emulation, and
-	more.</para>
-
-      <para>This section describes the use of a
-	<acronym>USB</acronym> Bluetooth dongle on a &os; system.  It
-	then describes the various Bluetooth protocols and
-	utilities.</para>
+    <para>Bluetooth 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 Wi-Fi wireless technology, Bluetooth offers
+      higher level service profiles, such as
+      <acronym>FTP</acronym>-like file servers, file pushing, voice
+      transport, serial line emulation, and more.</para>
+
+    <para>This section describes the use of a <acronym>USB</acronym>
+      Bluetooth dongle on a &os; system.  It then describes the
+      various Bluetooth protocols and utilities.</para>
 
     <sect2>
       <title>Loading Bluetooth Support</title>
@@ -2236,28 +2235,30 @@ freebsdap       00:11:95:c3:0d:ac    1  
       <para>The Bluetooth stack in &os; is implemented using the
 	&man.netgraph.4; framework.  A broad variety of Bluetooth
 	<acronym>USB</acronym> dongles is supported by &man.ng.ubt.4;.
-	Broadcom BCM2033 based Bluetooth devices are supported by
-	the &man.ubtbcmfw.4; and &man.ng.ubt.4; drivers.  The 3Com
+	Broadcom BCM2033 based Bluetooth devices are supported by 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 by &man.sio.4;, &man.ng.h4.4;, and
 	&man.hcseriald.8;.</para>
-	
+
       <para>Before attaching a device, determine which of the above
 	drivers it uses, then load the driver.  For example, if the
 	device uses the &man.ng.ubt.4; driver:</para>
 
       <screen>&prompt.root; <userinput>kldload ng_ubt</userinput></screen>
 
-      <para>If the Bluetooth device will be attached to the system during
-	system startup, the system can be configured to load the module at boot
-	time by adding the driver to
+      <para>If the Bluetooth device will be attached to the system
+	during system startup, the system can be configured to load
+	the module at boot time by adding the driver to
 	<filename>/boot/loader.conf</filename>:</para>
 
       <programlisting>ng_ubt_load="YES"</programlisting>
 
-      <para>Once the driver is loaded, plug in the <acronym>USB</acronym> dongle.  If the driver load was successful, output
-	similar to the following should appear on the console and in
+      <para>Once the driver is loaded, plug in the
+	<acronym>USB</acronym> dongle.  If the driver load was
+	successful, output similar to the following should appear on
+	the console and in
 	<filename>/var/log/messages</filename>:</para>
 
       <screen>ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2
@@ -2266,9 +2267,9 @@ ubt0: Interface 1 (alt.config 5) endpoin
       wMaxPacketSize=49, nframes=6, buffer size=294</screen>
 
       <para>To start and stop the Bluetooth stack, use its startup
-	script.  It is a good idea to stop the stack before
-	unplugging the device.  When starting the stack, the output
-	should be similar to the following:</para>
+	script.  It is a good idea to stop the stack before unplugging
+	the device.  When starting the stack, the output should be
+	similar to the following:</para>
 
       <screen>&prompt.root; <userinput>service bluetooth start ubt0</userinput>
 BD_ADDR: 00:02:72:00:d4:1a
@@ -2292,16 +2293,15 @@ Number of SCO packets: 8</screen>
       </indexterm>
 
       <para>The Host Controller Interface (<acronym>HCI</acronym>)
-	provides a uniform method for
-	accessing Bluetooth baseband capabilities.  In &os;, a
-	netgraph <acronym>HCI</acronym> node
-	is created for each Bluetooth device.  For more details, refer to
-	&man.ng.hci.4;.</para>
+	provides a uniform method for accessing Bluetooth baseband
+	capabilities.  In &os;, a netgraph <acronym>HCI</acronym> node
+	is created for each Bluetooth device.  For more details, refer
+	to &man.ng.hci.4;.</para>
 
       <para>One of the most common tasks is discovery of Bluetooth
-	devices within <acronym>RF</acronym> proximity.  This operation is
-	called <emphasis>inquiry</emphasis>.  Inquiry and other
-	<acronym>HCI</acronym> related operations are done using
+	devices within <acronym>RF</acronym> proximity.  This
+	operation is called <emphasis>inquiry</emphasis>.  Inquiry and
+	other <acronym>HCI</acronym> related operations are done using
 	&man.hccontrol.8;.  The example below shows how to find out
 	which Bluetooth devices are in range.  The list of devices
 	should be displayed in a few seconds.  Note that a remote
@@ -2321,13 +2321,13 @@ Inquiry complete. Status: No error [00]<
 
       <para>The <literal>BD_ADDR</literal> is the unique address of a
 	Bluetooth device, similar to the <acronym>MAC</acronym>
-	address of a network card.  This address is needed for
-	further communication with a device and it is possible to
-	assign a human readable name to a BD_ADDR.  Information
-	regarding the known Bluetooth hosts is contained in
+	address of a network card.  This address is needed for further
+	communication with a device and it is possible to assign a
+	human readable name to a BD_ADDR.  Information regarding the
+	known Bluetooth hosts is contained in
 	<filename>/etc/bluetooth/hosts</filename>.  The following
-	example shows how to obtain the human readable name that
-	was assigned to the remote device:</para>
+	example shows how to obtain the human readable name that was
+	assigned to the remote device:</para>
 
       <screen>&prompt.user; <userinput>hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4</userinput>
 BD_ADDR: 00:80:37:29:19:a4
@@ -2388,8 +2388,8 @@ Reason: Connection terminated by local h
 	Bluetooth authentication requests.  The default configuration
 	file is <filename>/etc/bluetooth/hcsecd.conf</filename>.  An
 	example section for a cellular phone with the
-	<acronym>PIN</acronym> code set to
-	<literal>1234</literal> is shown below:</para>
+	<acronym>PIN</acronym> code set to <literal>1234</literal> is
+	shown below:</para>
 
       <programlisting>device {
         bdaddr  00:80:37:29:19:a4;
@@ -2434,16 +2434,17 @@ hcsecd[16484]: Sending PIN_Code_Reply to
 	<acronym>PPP</acronym> Profiles</title>
 
       <para>A Dial-Up Networking (<acronym>DUN</acronym>) profile can
-	be used to configure a cellular phone as a
-	    wireless modem for connecting to a dial-up Internet access
-	    server.  It can also be used to configure a computer to
-	    receive data calls from a cellular phone.</para>
+	be used to configure a cellular phone as a wireless modem for
+	connecting to a dial-up Internet access server.  It can also
+	be used to configure a computer to receive data calls from a
+	cellular phone.</para>
 
       <para>Network access with a <acronym>PPP</acronym> profile can
-	be used to provide <acronym>LAN</acronym> access for a single Bluetooth
-	    device or multiple Bluetooth devices.  It can also provide
-	<acronym>PC</acronym> to <acronym>PC</acronym> connection using <acronym>PPP</acronym>
-	    networking over serial cable emulation.</para>
+	be used to provide <acronym>LAN</acronym> access for a single
+	Bluetooth device or multiple Bluetooth devices.  It can also
+	provide <acronym>PC</acronym> to <acronym>PC</acronym>
+	connection using <acronym>PPP</acronym> networking over serial
+	cable emulation.</para>
 
       <para>In &os;, these profiles are implemented with &man.ppp.8;
 	and the &man.rfcomm.pppd.8; wrapper which converts a
@@ -2453,20 +2454,22 @@ hcsecd[16484]: Sending PIN_Code_Reply to
 	<filename>/etc/ppp/ppp.conf</filename>.  Consult
 	&man.rfcomm.pppd.8; for examples.</para>
 
-      <para>In this example, &man.rfcomm.pppd.8; is used
-	to open a connection to a remote
-	device with a <literal>BD_ADDR</literal> of <literal>00:80:37:29:19:a4</literal>
-	on a <acronym>DUN</acronym> <acronym>RFCOMM</acronym> channel:</para>
+      <para>In this example, &man.rfcomm.pppd.8; is used to open a
+	connection to a remote device with a
+	<literal>BD_ADDR</literal> of
+	<literal>00:80:37:29:19:a4</literal> on a
+	<acronym>DUN</acronym> <acronym>RFCOMM</acronym>
+	channel:</para>
 
       <screen>&prompt.root; <userinput>rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup</userinput></screen>
 
-      <para>The actual channel number will be
-	obtained from the remote device using the <acronym>SDP</acronym> protocol.
-	It is possible to specify the <acronym>RFCOMM</acronym>
-	channel by hand, and in this case &man.rfcomm.pppd.8; will
-	not perform the <acronym>SDP</acronym> query.  Use
-	&man.sdpcontrol.8; to find out the <acronym>RFCOMM</acronym>
-	channel on the remote device.</para>
+      <para>The actual channel number will be obtained from the remote
+	device using the <acronym>SDP</acronym> protocol.  It is
+	possible to specify the <acronym>RFCOMM</acronym> channel by
+	hand, and in this case &man.rfcomm.pppd.8; will not perform
+	the <acronym>SDP</acronym> query.  Use &man.sdpcontrol.8; to
+	find out the <acronym>RFCOMM</acronym> channel on the remote
+	device.</para>
 
       <para>In order to provide network access with the
 	<acronym>PPP</acronym> <acronym>LAN</acronym> service,
@@ -2487,62 +2490,63 @@ hcsecd[16484]: Sending PIN_Code_Reply to
 
     <sect2>
       <title>Bluetooth Protocols</title>
-      
-      <para>This section provides an overview of the various Bluetooth protocols,
-	their function, and associated utilities.</para>
-   
-    <sect3>
-      <title>Logical Link Control and Adaptation Protocol
-	(<acronym>L2CAP</acronym>)</title>
 
-      <indexterm>
-	<primary>L2CAP</primary>
-      </indexterm>
+      <para>This section provides an overview of the various Bluetooth
+	protocols, their function, and associated utilities.</para>
+
+      <sect3>
+	<title>Logical Link Control and Adaptation Protocol
+	  (<acronym>L2CAP</acronym>)</title>
+
+	<indexterm>
+	  <primary>L2CAP</primary>
+	</indexterm>
 
-      <para>The Logical Link Control and Adaptation Protocol
-	(<acronym>L2CAP</acronym>) provides connection-oriented and
-	connectionless data services to upper layer protocols.
-	<acronym>L2CAP</acronym> permits
-	higher level protocols and applications to transmit and
-	receive <acronym>L2CAP</acronym> data packets up to 64
-	kilobytes in length.</para>
-
-      <para><acronym>L2CAP</acronym> is based around the concept of
-	<emphasis>channels</emphasis>.  A channel is a logical
-	connection on top of a baseband connection, where 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
-	<acronym>L2CAP</acronym> packet received on a channel is
-	directed to the appropriate higher level protocol.  Multiple
-	channels can share the same baseband connection.</para>
-
-      <para>In &os;, a netgraph <acronym>L2CAP</acronym> node
-	is created for each Bluetooth device.  This
-	node is normally connected to the
-	downstream Bluetooth <acronym>HCI</acronym> node and upstream
-	Bluetooth socket nodes.  The default name for the
-	<acronym>L2CAP</acronym> node is <quote>devicel2cap</quote>.
-	For more details refer to &man.ng.l2cap.4;.</para>
-
-      <para>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 <literal>0
-	  bytes</literal> in the following example is normal.</para>
+	<para>The Logical Link Control and Adaptation Protocol
+	  (<acronym>L2CAP</acronym>) provides connection-oriented and
+	  connectionless data services to upper layer protocols.
+	  <acronym>L2CAP</acronym> permits higher level protocols and
+	  applications to transmit and receive
+	  <acronym>L2CAP</acronym> data packets up to 64 kilobytes in
+	  length.</para>
+
+	<para><acronym>L2CAP</acronym> is based around the concept of
+	  <emphasis>channels</emphasis>.  A channel is a logical
+	  connection on top of a baseband connection, where 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 <acronym>L2CAP</acronym> packet received on
+	  a channel is directed to the appropriate higher level
+	  protocol.  Multiple channels can share the same baseband
+	  connection.</para>
+
+	<para>In &os;, a netgraph <acronym>L2CAP</acronym> node is
+	  created for each Bluetooth device.  This node is normally
+	  connected to the downstream Bluetooth <acronym>HCI</acronym>
+	  node and upstream Bluetooth socket nodes.  The default name
+	  for the <acronym>L2CAP</acronym> node is
+	  <quote>devicel2cap</quote>.  For more details refer to
+	  &man.ng.l2cap.4;.</para>
+
+	<para>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 <literal>0
+	    bytes</literal> in the following example is normal.</para>
 
-      <screen>&prompt.root; <userinput>l2ping -a 00:80:37:29:19:a4</userinput>
+	<screen>&prompt.root; <userinput>l2ping -a 00:80:37:29:19:a4</userinput>
 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=0</screen>
 
-      <para>The &man.l2control.8; utility is used to perform various
-	operations on <acronym>L2CAP</acronym> nodes.  This example
-	shows how to obtain the list of logical connections (channels)
-	and the list of baseband connections for the local
-	device:</para>
+	<para>The &man.l2control.8; utility is used to perform various
+	  operations on <acronym>L2CAP</acronym> nodes.  This example
+	  shows how to obtain the list of logical connections
+	  (channels) and the list of baseband connections for the
+	  local device:</para>
 
-      <screen>&prompt.user; <userinput>l2control -a 00:02:72:00:d4:1a read_channel_list</userinput>
+	<screen>&prompt.user; <userinput>l2control -a 00:02:72:00:d4:1a read_channel_list</userinput>
 L2CAP channels:
 Remote BD_ADDR     SCID/ DCID   PSM  IMTU/ OMTU State
 00:07:e0:00:0b:ca    66/   64     3   132/  672 OPEN
@@ -2551,12 +2555,13 @@ L2CAP connections:
 Remote BD_ADDR    Handle Flags Pending State
 00:07:e0:00:0b:ca     41 O           0 OPEN</screen>
 
-      <para>Another diagnostic tool is &man.btsockstat.1;.  It is
-	similar to &man.netstat.1;, but for Bluetooth network-related
-	data structures.  The example below shows the same logical
-	connection as &man.l2control.8; above.</para>
+	<para>Another diagnostic tool is &man.btsockstat.1;.  It is
+	  similar to &man.netstat.1;, but for Bluetooth
+	  network-related data structures.  The example below shows
+	  the same logical connection as &man.l2control.8;
+	  above.</para>
 
-      <screen>&prompt.user; <userinput>btsockstat</userinput>
+	<screen>&prompt.user; <userinput>btsockstat</userinput>
 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
@@ -2566,86 +2571,89 @@ c2afe900 c2b53380 1    127   0     Yes  
 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    OPEN</screen>
-    </sect3>
+      </sect3>
 
-    <sect3>
-      <title>Radio Frequency Communication (<acronym>RFCOMM</acronym>)</title>
+      <sect3>
+	<title>Radio Frequency Communication
+	  (<acronym>RFCOMM</acronym>)</title>
 
-      <para>The <acronym>RFCOMM</acronym> protocol provides emulation
-	of serial ports over the <acronym>L2CAP</acronym> protocol.
-	<acronym>RFCOMM</acronym> is a simple transport protocol,
-	with additional provisions for emulating the 9 circuits of
-	RS-232 (EIATIA-232-E) serial ports.  It
-	supports up to 60 simultaneous connections
-	(<acronym>RFCOMM</acronym> channels) between two Bluetooth
-	devices.</para>
-
-      <para>For the purposes of <acronym>RFCOMM</acronym>, a complete
-	communication path involves two applications running on the
-	communication endpoints with a communication segment between
-	them.  <acronym>RFCOMM</acronym> is intended to cover
-	applications that make use of the serial ports of the devices
-	in which they reside.  The communication segment is a direct
-	connect Bluetooth link from one device to another.</para>
-
-      <para><acronym>RFCOMM</acronym> 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.
-	<acronym>RFCOMM</acronym> 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.</para>
-
-      <para>In &os;, <acronym>RFCOMM</acronym> is implemented at the
-	Bluetooth sockets layer.</para>
-    </sect3>
-
-    <sect3>
-      <title>Service Discovery Protocol
-	(<acronym>SDP</acronym>)</title>
+	<para>The <acronym>RFCOMM</acronym> protocol provides
+	  emulation of serial ports over the <acronym>L2CAP</acronym>
+	  protocol.  <acronym>RFCOMM</acronym> is a simple transport
+	  protocol, with additional provisions for emulating the 9
+	  circuits of RS-232 (EIATIA-232-E) serial ports.  It
+	  supports up to 60 simultaneous connections
+	  (<acronym>RFCOMM</acronym> channels) between two Bluetooth
+	  devices.</para>
+
+	<para>For the purposes of <acronym>RFCOMM</acronym>, a
+	  complete communication path involves two applications
+	  running on the communication endpoints with a communication
+	  segment between them.  <acronym>RFCOMM</acronym> is intended
+	  to cover applications that make use of the serial ports of
+	  the devices in which they reside.  The communication segment
+	  is a direct connect Bluetooth link from one device to
+	  another.</para>
+
+	<para><acronym>RFCOMM</acronym> 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.
+	  <acronym>RFCOMM</acronym> 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.</para>
 
-      <indexterm>
-	<primary>SDP</primary>
-      </indexterm>
+	<para>In &os;, <acronym>RFCOMM</acronym> is implemented at the
+	  Bluetooth sockets layer.</para>
+      </sect3>
 
-      <para>The Service Discovery Protocol (<acronym>SDP</acronym>)
-	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.</para>
-
-      <para><acronym>SDP</acronym> involves communication between a
-	<acronym>SDP</acronym> server and a <acronym>SDP</acronym>
-	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 <acronym>SDP</acronym> server
-	by issuing a <acronym>SDP</acronym> 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.
-	<acronym>SDP</acronym> provides a mechanism for discovering
-	services and their attributes, but it does not provide a
-	mechanism for utilizing those services.</para>
-
-      <para>Normally, a <acronym>SDP</acronym> 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
-	<acronym>SDP</acronym> server's service records without any
-	prior information about the services.  This process of
-	looking for any offered services is called
-	<emphasis>browsing</emphasis>.</para>
-
-      <para>The Bluetooth <acronym>SDP</acronym> 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 <acronym>SDP</acronym> browse query.</para>
+      <sect3>
+	<title>Service Discovery Protocol
+	  (<acronym>SDP</acronym>)</title>
 
-      <screen>&prompt.user; <userinput>sdpcontrol -a 00:01:03:fc:6e:ec browse</userinput>
+	<indexterm>
+	  <primary>SDP</primary>
+	</indexterm>
+
+	<para>The Service Discovery Protocol (<acronym>SDP</acronym>)
+	  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.</para>
+
+	<para><acronym>SDP</acronym> involves communication between a
+	  <acronym>SDP</acronym> server and a <acronym>SDP</acronym>
+	  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 <acronym>SDP</acronym>
+	  server by issuing a <acronym>SDP</acronym> 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.
+	  <acronym>SDP</acronym> provides a mechanism for discovering
+	  services and their attributes, but it does not provide a
+	  mechanism for utilizing those services.</para>
+
+	<para>Normally, a <acronym>SDP</acronym> 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
+	  <acronym>SDP</acronym> server's service records without any
+	  prior information about the services.  This process of
+	  looking for any offered services is called
+	  <emphasis>browsing</emphasis>.</para>
+
+	<para>The Bluetooth <acronym>SDP</acronym> 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
+	  <acronym>SDP</acronym> browse query.</para>
+
+	<screen>&prompt.user; <userinput>sdpcontrol -a 00:01:03:fc:6e:ec browse</userinput>
 Record Handle: 00000000
 Service Class ID List:
         Service Discovery Server (0x1000)
@@ -2668,83 +2676,82 @@ Protocol Descriptor List:
 Bluetooth Profile Descriptor List:
         LAN Access Using PPP (0x1102) ver. 1.0</screen>
 
-      <para>Note that each service has a list of attributes, such
-	as the <acronym>RFCOMM</acronym> channel.  Depending on the
-	service, the user might need to make 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
-	<acronym>OBEX</acronym> Object Push
-	(<acronym>OPUSH</acronym>) service:</para>
-
-      <screen>&prompt.user; <userinput>sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH</userinput></screen>
-
-      <para>Offering services on &os; to Bluetooth clients is done
-	with the &man.sdpd.8; server.  The following line can be added
-	to <filename>/etc/rc.conf</filename>:</para>
-
-      <programlisting>sdpd_enable="YES"</programlisting>
-
-      <para>Then the &man.sdpd.8; daemon can be
-	started with:</para>
-
-      <screen>&prompt.root; <userinput>service sdpd start</userinput></screen>
-
-      <para>The local server application that wants to provide a
-	Bluetooth service to remote clients will register the service
-	with the local <acronym>SDP</acronym> daemon.  An example of
-	such an application is &man.rfcomm.pppd.8;.  Once started,
-	it will register the Bluetooth LAN service with the local
-	<acronym>SDP</acronym> daemon.</para>
-
-      <para>The list of services registered with the local
-	<acronym>SDP</acronym> server can be obtained by issuing a
-	<acronym>SDP</acronym> browse query via the local control
-	channel:</para>
+	<para>Note that each service has a list of attributes, such
+	  as the <acronym>RFCOMM</acronym> channel.  Depending on the
+	  service, the user might need to make 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
+	  <acronym>OBEX</acronym> Object Push
+	  (<acronym>OPUSH</acronym>) service:</para>
+
+	<screen>&prompt.user; <userinput>sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH</userinput></screen>
+
+	<para>Offering services on &os; to Bluetooth clients is done
+	  with the &man.sdpd.8; server.  The following line can be
+	  added to <filename>/etc/rc.conf</filename>:</para>
+
+	<programlisting>sdpd_enable="YES"</programlisting>
+
+	<para>Then the &man.sdpd.8; daemon can be started with:</para>
+
+	<screen>&prompt.root; <userinput>service sdpd start</userinput></screen>
+
+	<para>The local server application that wants to provide a
+	  Bluetooth service to remote clients will register the
+	  service with the local <acronym>SDP</acronym> daemon.  An
+	  example of such an application is &man.rfcomm.pppd.8;.  Once
+	  started, it will register the Bluetooth LAN service with the
+	  local <acronym>SDP</acronym> daemon.</para>
+
+	<para>The list of services registered with the local
+	  <acronym>SDP</acronym> server can be obtained by issuing a
+	  <acronym>SDP</acronym> browse query via the local control
+	  channel:</para>
 
-      <screen>&prompt.root; <userinput>sdpcontrol -l browse</userinput></screen>
-    </sect3>
+	<screen>&prompt.root; <userinput>sdpcontrol -l browse</userinput></screen>
+      </sect3>
 
-    <sect3>
-      <title><acronym>OBEX</acronym> Object Push
-	(<acronym>OPUSH</acronym>)</title>
+      <sect3>
+	<title><acronym>OBEX</acronym> Object Push
+	  (<acronym>OPUSH</acronym>)</title>
 
-      <indexterm>
-	<primary>OBEX</primary>
-      </indexterm>
+	<indexterm>
+	  <primary>OBEX</primary>
+	</indexterm>
 
-      <para>Object Exchange (<acronym>OBEX</acronym>) 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 <acronym>PDA</acronym>s,
-	and for sending business cards or calendar entries between
-	cellular phones and other devices with Personal Information Manager (<acronym>PIM</acronym>)
-	applications.</para>
-
-      <para>The <acronym>OBEX</acronym> server and client are
-	implemented by
-	<application>obexapp</application>, which can be installed using the
-	<package>comms/obexapp</package> package or
-	port.</para>
-
-      <para>The <acronym>OBEX</acronym> client is used to push and/or
-	pull objects from the <acronym>OBEX</acronym> server.  An example
-	object is a business card or an appointment.
-	The <acronym>OBEX</acronym> client can obtain the
-	<acronym>RFCOMM</acronym> channel number from the remote
-	device via <acronym>SDP</acronym>.  This can be done by
-	specifying the service name instead of the
-	<acronym>RFCOMM</acronym> channel number.  Supported service
-	names are: <literal>IrMC</literal>, <literal>FTRN</literal>,
-	and <literal>OPUSH</literal>.  It is also possible to specify
-	the <acronym>RFCOMM</acronym> channel as a number.  Below is
-	an example of an <acronym>OBEX</acronym> session where the
-	device information object is pulled from the cellular phone,
-	and a new object, the business card, is pushed into the
-	phone's directory.</para>
+	<para>Object Exchange (<acronym>OBEX</acronym>) 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
+	  <acronym>PDA</acronym>s, and for sending business cards or
+	  calendar entries between cellular phones and other devices
+	  with Personal Information Manager (<acronym>PIM</acronym>)
+	  applications.</para>
+
+	<para>The <acronym>OBEX</acronym> server and client are
+	  implemented by <application>obexapp</application>, which can
+	  be installed using the <package>comms/obexapp</package>
+	  package or port.</para>
+
+	<para>The <acronym>OBEX</acronym> client is used to push
+	  and/or pull objects from the <acronym>OBEX</acronym> server.
+	  An example object is a business card or an appointment.
+	  The <acronym>OBEX</acronym> client can obtain the
+	  <acronym>RFCOMM</acronym> channel number from the remote
+	  device via <acronym>SDP</acronym>.  This can be done by
+	  specifying the service name instead of the
+	  <acronym>RFCOMM</acronym> channel number.  Supported service
+	  names are: <literal>IrMC</literal>, <literal>FTRN</literal>,
+	  and <literal>OPUSH</literal>.  It is also possible to
+	  specify the <acronym>RFCOMM</acronym> channel as a number.
+	  Below is an example of an <acronym>OBEX</acronym> session
+	  where the device information object is pulled from the
+	  cellular phone, and a new object, the business card, is
+	  pushed into the phone's directory.</para>
 
-      <screen>&prompt.user; <userinput>obexapp -a 00:80:37:29:19:a4 -C IrMC</userinput>
+	<screen>&prompt.user; <userinput>obexapp -a 00:80:37:29:19:a4 -C IrMC</userinput>
 obex> get telecom/devinfo.txt devinfo-t39.txt
 Success, response: OK, Success (0x20)
 obex> put new.vcf
@@ -2752,72 +2759,70 @@ Success, response: OK, Success (0x20)
 obex> di
 Success, response: OK, Success (0x20)</screen>
 
-      <para>In order to provide the <acronym>OPUSH</acronym> service,
-	&man.sdpd.8; must be running and a root folder, where all
-	incoming objects will be stored, must be created.  The
-	default path to the root folder is
-	<filename>/var/spool/obex</filename>.  Finally, start the
-	<acronym>OBEX</acronym> server on a valid
-	<acronym>RFCOMM</acronym> channel number.  The
-	<acronym>OBEX</acronym> server will automatically register
-	the <acronym>OPUSH</acronym> service with the local
-	<acronym>SDP</acronym> daemon.  The example below shows how
-	to start the <acronym>OBEX</acronym> server.</para>
-
-      <screen>&prompt.root; <userinput>obexapp -s -C 10</userinput></screen>
-    </sect3>
-
-    <sect3>
-      <title>Serial Port Profile (<acronym>SPP</acronym>)</title>
-
-      <para>The Serial Port Profile (<acronym>SPP</acronym>) allows
-	Bluetooth devices to perform serial cable emulation.  This
-	profile allows legacy applications to use Bluetooth as a
-	cable replacement, through a virtual serial port
-	abstraction.</para>
-
-      <para>In &os;, &man.rfcomm.sppd.1; implements
-	<acronym>SPP</acronym> and a pseudo tty is used as a virtual
-	serial port abstraction.  The example below shows how to
-	connect to a remote device's serial port service.  A
-	<acronym>RFCOMM</acronym> channel does not have to be
-	specified as &man.rfcomm.sppd.1; can obtain it from the
-	remote device via <acronym>SDP</acronym>.  To override this,
-	specify a <acronym>RFCOMM</acronym> channel on the command
-	line.</para>
+	<para>In order to provide the <acronym>OPUSH</acronym>
+	  service, &man.sdpd.8; must be running and a root folder,
+	  where all incoming objects will be stored, must be created.
+	  The default path to the root folder is
+	  <filename>/var/spool/obex</filename>.  Finally, start the
+	  <acronym>OBEX</acronym> server on a valid
+	  <acronym>RFCOMM</acronym> channel number.  The
+	  <acronym>OBEX</acronym> server will automatically register
+	  the <acronym>OPUSH</acronym> service with the local
+	  <acronym>SDP</acronym> daemon.  The example below shows how
+	  to start the <acronym>OBEX</acronym> server.</para>
+
+	<screen>&prompt.root; <userinput>obexapp -s -C 10</userinput></screen>
+      </sect3>
+
+      <sect3>
+	<title>Serial Port Profile (<acronym>SPP</acronym>)</title>
+
+	<para>The Serial Port Profile (<acronym>SPP</acronym>) allows
+	  Bluetooth devices to perform serial cable emulation.  This
+	  profile allows legacy applications to use Bluetooth as a
+	  cable replacement, through a virtual serial port
+	  abstraction.</para>
+
+	<para>In &os;, &man.rfcomm.sppd.1; implements
+	  <acronym>SPP</acronym> and a pseudo tty is used as a virtual
+	  serial port abstraction.  The example below shows how to
+	  connect to a remote device's serial port service.  A
+	  <acronym>RFCOMM</acronym> channel does not have to be
+	  specified as &man.rfcomm.sppd.1; can obtain it from the
+	  remote device via <acronym>SDP</acronym>.  To override this,
+	  specify a <acronym>RFCOMM</acronym> channel on the command
+	  line.</para>
 
-      <screen>&prompt.root; <userinput>rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6</userinput>
+	<screen>&prompt.root; <userinput>rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6</userinput>
 rfcomm_sppd[94692]: Starting on /dev/ttyp6...</screen>
 
-      <para>Once connected, the pseudo tty can be used as serial
-	port:</para>
+	<para>Once connected, the pseudo tty can be used as serial
+	  port:</para>
 
-      <screen>&prompt.root; <userinput>cu -l ttyp6</userinput></screen>
-    </sect3>
-  </sect2>
+	<screen>&prompt.root; <userinput>cu -l ttyp6</userinput></screen>
+      </sect3>
+    </sect2>
 
     <sect2>
       <title>Troubleshooting</title>
 
-	<para>By default, when &os; is accepting a new
-	  connection, it tries to perform a role switch and become
-	  master.  Some older Bluetooth devices which do not support role
-	  switching will not be able
-	  to connect.  Since role switching is performed when a
-	  new connection is being established, it is not possible
-	  to ask the remote device if it supports role switching.
-	  However, there is a <acronym>HCI</acronym> option to disable role
-	  switching on the local side:</para>
-
-	<screen>&prompt.root; <userinput>hccontrol -n ubt0hci write_node_role_switch 0</userinput></screen>
-
-	<para>To display Bluetooth packets, use the third-party package
-	  <application>hcidump</application>, which can be installed using the
-	  <package>comms/hcidump</package> package or
-	  port.  This utility is similar to &man.tcpdump.1; and can
-	  be used to display the contents of Bluetooth packets on
-	  the terminal and to dump the Bluetooth packets to a
-	  file.</para>
+      <para>By default, when &os; is accepting a new connection, it
+	tries to perform a role switch and become master.  Some older
+	Bluetooth devices which do not support role switching will not
+	be able to connect.  Since role switching is performed when a
+	new connection is being established, it is not possible to ask
+	the remote device if it supports role switching.  However,
+	there is a <acronym>HCI</acronym> option to disable role
+	switching on the local side:</para>
+
+      <screen>&prompt.root; <userinput>hccontrol -n ubt0hci write_node_role_switch 0</userinput></screen>
+
+      <para>To display Bluetooth packets, use the third-party package
+	<application>hcidump</application>, which can be installed
+	using the <package>comms/hcidump</package> package or port.
+	This utility is similar to &man.tcpdump.1; and can be used to
+	display the contents of Bluetooth packets on the terminal and
+	to dump the Bluetooth packets to a file.</para>
     </sect2>
   </sect1>
 


More information about the svn-doc-all mailing list