svn commit: r44156 - head/en_US.ISO8859-1/books/handbook/advanced-networking
Dru Lavigne
dru at FreeBSD.org
Thu Mar 6 18:39:21 UTC 2014
Author: dru
Date: Thu Mar 6 18:39:20 2014
New Revision: 44156
URL: http://svnweb.freebsd.org/changeset/doc/44156
Log:
Editorial pass through second 1/2 of Bluetooth chapter.
Protocols section is still a bit dense.
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:32:15 2014 (r44155)
+++ head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml Thu Mar 6 18:39:20 2014 (r44156)
@@ -2488,8 +2488,8 @@ hcsecd[16484]: Sending PIN_Code_Reply to
<sect2>
<title>Bluetooth Protocols</title>
- <para>This section describes the various Bluetooth utilities,
- their function, and available utilities.</para>
+ <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
@@ -2501,16 +2501,15 @@ hcsecd[16484]: Sending PIN_Code_Reply to
<para>The Logical Link Control and Adaptation Protocol
(<acronym>L2CAP</acronym>) provides connection-oriented and
- connectionless data services to upper layer protocols with
- protocol multiplexing capability and segmentation and
- reassembly operation. <acronym>L2CAP</acronym> permits
+ 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. Each channel is
+ 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
@@ -2518,9 +2517,9 @@ hcsecd[16484]: Sending PIN_Code_Reply to
directed to the appropriate higher level protocol. Multiple
channels can share the same baseband connection.</para>
- <para>A single netgraph node of type <emphasis>l2cap</emphasis>
- is created for a single Bluetooth device. The
- <acronym>L2CAP</acronym> node is normally connected to the
+ <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>.
@@ -2574,10 +2573,9 @@ c2e8bc80 0 250 00:02:72:00:d4:1a
<para>The <acronym>RFCOMM</acronym> protocol provides emulation
of serial ports over the <acronym>L2CAP</acronym> protocol.
- The protocol is based on the ETSI standard TS 07.10.
<acronym>RFCOMM</acronym> is a simple transport protocol,
with additional provisions for emulating the 9 circuits of
- RS-232 (EIATIA-232-E) serial ports. <acronym>RFCOMM</acronym>
+ RS-232 (EIATIA-232-E) serial ports. It
supports up to 60 simultaneous connections
(<acronym>RFCOMM</acronym> channels) between two Bluetooth
devices.</para>
@@ -2693,8 +2691,8 @@ Bluetooth Profile Descriptor List:
<screen>&prompt.root; <userinput>service sdpd start</userinput></screen>
- <para>The local server application that wants to provide
- Bluetooth service to the remote clients will register service
+ <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
@@ -2710,36 +2708,36 @@ Bluetooth Profile Descriptor List:
<sect3>
<title><acronym>OBEX</acronym> Object Push
- (<acronym>OPUSH</acronym>) Profile</title>
+ (<acronym>OPUSH</acronym>)</title>
<indexterm>
<primary>OBEX</primary>
</indexterm>
- <para><acronym>OBEX</acronym> is a widely used protocol for
+ <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 <acronym>PIM</acronym>
+ cellular phones and other devices with Personal Information Manager (<acronym>PIM</acronym>)
applications.</para>
<para>The <acronym>OBEX</acronym> server and client are
- implemented as a third-party package,
- <application>obexapp</application>, which is available as
+ 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
- object can, for example, be a business card or an appointment.
+ 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: <acronym>IrMC</acronym>, <acronym>FTRN</acronym>,
- and <acronym>OPUSH</acronym>. It is also possible to specify
+ 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,
@@ -2781,7 +2779,7 @@ Success, response: OK, Success (0x20)</s
<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 serial port service. A
+ 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,
@@ -2801,20 +2799,20 @@ rfcomm_sppd[94692]: Starting on /dev/tty
<sect2>
<title>Troubleshooting</title>
- <para>Some older Bluetooth devices do not support role
- switching. By default, when &os; is accepting a new
+ <para>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
+ 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.
- There is a <acronym>HCI</acronym> option to disable role
+ 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 is available as a
+ <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
More information about the svn-doc-all
mailing list