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