White space fix only. Translators can ignore.
Sponsored by: iXsystems
This commit is contained in:
Dru Lavigne
parent
e89cf0fcff
commit
56d58ccd7a
Notes:
svn2git
2020-12-08 03:00:23 +00:00
svn path=/head/; revision=44158
1 changed files with 295 additions and 290 deletions
|
|
@ -2216,19 +2216,18 @@ freebsdap 00:11:95:c3:0d:ac 1 54M 22:1 100 EPS</screen>
|
|||
<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>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>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 54M 22:1 100 EPS</screen>
|
|||
<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) endpoints: isoc-in=0x83, isoc-out=0x3,
|
|||
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]</screen>
|
|||
|
||||
<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 host [0x16]</screen>
|
|||
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 'ubt0hci' for remote bdaddr 0:80:37:29:
|
|||
<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 'ubt0hci' for remote bdaddr 0:80:37:29:
|
|||
<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 'ubt0hci' for remote bdaddr 0:80:37:29:
|
|||
|
||||
<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>
|
||||
|
||||
<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>
|
||||
<sect3>
|
||||
<title>Logical Link Control and Adaptation Protocol
|
||||
(<acronym>L2CAP</acronym>)</title>
|
||||
|
||||
<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>
|
||||
<indexterm>
|
||||
<primary>L2CAP</primary>
|
||||
</indexterm>
|
||||
|
||||
<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>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>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><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>
|
||||
|
||||
<screen>&prompt.root; <userinput>l2ping -a 00:80:37:29:19:a4</userinput>
|
||||
<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>
|
||||
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 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 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>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>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><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>
|
||||
<para>In &os;, <acronym>RFCOMM</acronym> is implemented at the
|
||||
Bluetooth sockets layer.</para>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Service Discovery Protocol
|
||||
(<acronym>SDP</acronym>)</title>
|
||||
<sect3>
|
||||
<title>Service Discovery Protocol
|
||||
(<acronym>SDP</acronym>)</title>
|
||||
|
||||
<indexterm>
|
||||
<primary>SDP</primary>
|
||||
</indexterm>
|
||||
<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>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><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>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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<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>
|
||||
<programlisting>sdpd_enable="YES"</programlisting>
|
||||
|
||||
<para>Then the &man.sdpd.8; daemon can be
|
||||
started with:</para>
|
||||
<para>Then the &man.sdpd.8; daemon can be started with:</para>
|
||||
|
||||
<screen>&prompt.root; <userinput>service sdpd start</userinput></screen>
|
||||
<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 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>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>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> 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>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>
|
||||
<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>
|
||||
<screen>&prompt.root; <userinput>obexapp -s -C 10</userinput></screen>
|
||||
</sect3>
|
||||
|
||||
<sect3>
|
||||
<title>Serial Port Profile (<acronym>SPP</acronym>)</title>
|
||||
<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>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 &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>
|
||||
<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>
|
||||
<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>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>
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue