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>
|
<primary>Bluetooth</primary>
|
||||||
</indexterm>
|
</indexterm>
|
||||||
|
|
||||||
<para>Bluetooth is a wireless technology for creating personal
|
<para>Bluetooth is a wireless technology for creating personal
|
||||||
networks operating in the 2.4 GHz unlicensed band, with a
|
networks operating in the 2.4 GHz unlicensed band, with a
|
||||||
range of 10 meters. Networks are usually formed ad-hoc from
|
range of 10 meters. Networks are usually formed ad-hoc from
|
||||||
portable devices such as cellular phones, handhelds, and
|
portable devices such as cellular phones, handhelds, and
|
||||||
laptops. Unlike Wi-Fi wireless technology, Bluetooth offers
|
laptops. Unlike Wi-Fi wireless technology, Bluetooth offers
|
||||||
higher level service profiles, such as <acronym>FTP</acronym>-like file servers,
|
higher level service profiles, such as
|
||||||
file pushing, voice transport, serial line emulation, and
|
<acronym>FTP</acronym>-like file servers, file pushing, voice
|
||||||
more.</para>
|
transport, serial line emulation, and more.</para>
|
||||||
|
|
||||||
<para>This section describes the use of a
|
<para>This section describes the use of a <acronym>USB</acronym>
|
||||||
<acronym>USB</acronym> Bluetooth dongle on a &os; system. It
|
Bluetooth dongle on a &os; system. It then describes the
|
||||||
then describes the various Bluetooth protocols and
|
various Bluetooth protocols and utilities.</para>
|
||||||
utilities.</para>
|
|
||||||
|
|
||||||
<sect2>
|
<sect2>
|
||||||
<title>Loading Bluetooth Support</title>
|
<title>Loading Bluetooth Support</title>
|
||||||
|
|
@ -2236,8 +2235,8 @@ freebsdap 00:11:95:c3:0d:ac 1 54M 22:1 100 EPS</screen>
|
||||||
<para>The Bluetooth stack in &os; is implemented using the
|
<para>The Bluetooth stack in &os; is implemented using the
|
||||||
&man.netgraph.4; framework. A broad variety of Bluetooth
|
&man.netgraph.4; framework. A broad variety of Bluetooth
|
||||||
<acronym>USB</acronym> dongles is supported by &man.ng.ubt.4;.
|
<acronym>USB</acronym> dongles is supported by &man.ng.ubt.4;.
|
||||||
Broadcom BCM2033 based Bluetooth devices are supported by
|
Broadcom BCM2033 based Bluetooth devices are supported by the
|
||||||
the &man.ubtbcmfw.4; and &man.ng.ubt.4; drivers. The 3Com
|
&man.ubtbcmfw.4; and &man.ng.ubt.4; drivers. The 3Com
|
||||||
Bluetooth PC Card 3CRWB60-A is supported by the
|
Bluetooth PC Card 3CRWB60-A is supported by the
|
||||||
&man.ng.bt3c.4; driver. Serial and UART based Bluetooth
|
&man.ng.bt3c.4; driver. Serial and UART based Bluetooth
|
||||||
devices are supported by &man.sio.4;, &man.ng.h4.4;, and
|
devices are supported by &man.sio.4;, &man.ng.h4.4;, and
|
||||||
|
|
@ -2249,15 +2248,17 @@ freebsdap 00:11:95:c3:0d:ac 1 54M 22:1 100 EPS</screen>
|
||||||
|
|
||||||
<screen>&prompt.root; <userinput>kldload ng_ubt</userinput></screen>
|
<screen>&prompt.root; <userinput>kldload ng_ubt</userinput></screen>
|
||||||
|
|
||||||
<para>If the Bluetooth device will be attached to the system during
|
<para>If the Bluetooth device will be attached to the system
|
||||||
system startup, the system can be configured to load the module at boot
|
during system startup, the system can be configured to load
|
||||||
time by adding the driver to
|
the module at boot time by adding the driver to
|
||||||
<filename>/boot/loader.conf</filename>:</para>
|
<filename>/boot/loader.conf</filename>:</para>
|
||||||
|
|
||||||
<programlisting>ng_ubt_load="YES"</programlisting>
|
<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
|
<para>Once the driver is loaded, plug in the
|
||||||
similar to the following should appear on the console and in
|
<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>
|
<filename>/var/log/messages</filename>:</para>
|
||||||
|
|
||||||
<screen>ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2
|
<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>
|
wMaxPacketSize=49, nframes=6, buffer size=294</screen>
|
||||||
|
|
||||||
<para>To start and stop the Bluetooth stack, use its startup
|
<para>To start and stop the Bluetooth stack, use its startup
|
||||||
script. It is a good idea to stop the stack before
|
script. It is a good idea to stop the stack before unplugging
|
||||||
unplugging the device. When starting the stack, the output
|
the device. When starting the stack, the output should be
|
||||||
should be similar to the following:</para>
|
similar to the following:</para>
|
||||||
|
|
||||||
<screen>&prompt.root; <userinput>service bluetooth start ubt0</userinput>
|
<screen>&prompt.root; <userinput>service bluetooth start ubt0</userinput>
|
||||||
BD_ADDR: 00:02:72:00:d4:1a
|
BD_ADDR: 00:02:72:00:d4:1a
|
||||||
|
|
@ -2292,16 +2293,15 @@ Number of SCO packets: 8</screen>
|
||||||
</indexterm>
|
</indexterm>
|
||||||
|
|
||||||
<para>The Host Controller Interface (<acronym>HCI</acronym>)
|
<para>The Host Controller Interface (<acronym>HCI</acronym>)
|
||||||
provides a uniform method for
|
provides a uniform method for accessing Bluetooth baseband
|
||||||
accessing Bluetooth baseband capabilities. In &os;, a
|
capabilities. In &os;, a netgraph <acronym>HCI</acronym> node
|
||||||
netgraph <acronym>HCI</acronym> node
|
is created for each Bluetooth device. For more details, refer
|
||||||
is created for each Bluetooth device. For more details, refer to
|
to &man.ng.hci.4;.</para>
|
||||||
&man.ng.hci.4;.</para>
|
|
||||||
|
|
||||||
<para>One of the most common tasks is discovery of Bluetooth
|
<para>One of the most common tasks is discovery of Bluetooth
|
||||||
devices within <acronym>RF</acronym> proximity. This operation is
|
devices within <acronym>RF</acronym> proximity. This
|
||||||
called <emphasis>inquiry</emphasis>. Inquiry and other
|
operation is called <emphasis>inquiry</emphasis>. Inquiry and
|
||||||
<acronym>HCI</acronym> related operations are done using
|
other <acronym>HCI</acronym> related operations are done using
|
||||||
&man.hccontrol.8;. The example below shows how to find out
|
&man.hccontrol.8;. The example below shows how to find out
|
||||||
which Bluetooth devices are in range. The list of devices
|
which Bluetooth devices are in range. The list of devices
|
||||||
should be displayed in a few seconds. Note that a remote
|
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
|
<para>The <literal>BD_ADDR</literal> is the unique address of a
|
||||||
Bluetooth device, similar to the <acronym>MAC</acronym>
|
Bluetooth device, similar to the <acronym>MAC</acronym>
|
||||||
address of a network card. This address is needed for
|
address of a network card. This address is needed for further
|
||||||
further communication with a device and it is possible to
|
communication with a device and it is possible to assign a
|
||||||
assign a human readable name to a BD_ADDR. Information
|
human readable name to a BD_ADDR. Information regarding the
|
||||||
regarding the known Bluetooth hosts is contained in
|
known Bluetooth hosts is contained in
|
||||||
<filename>/etc/bluetooth/hosts</filename>. The following
|
<filename>/etc/bluetooth/hosts</filename>. The following
|
||||||
example shows how to obtain the human readable name that
|
example shows how to obtain the human readable name that was
|
||||||
was assigned to the remote device:</para>
|
assigned to the remote device:</para>
|
||||||
|
|
||||||
<screen>&prompt.user; <userinput>hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4</userinput>
|
<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
|
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
|
Bluetooth authentication requests. The default configuration
|
||||||
file is <filename>/etc/bluetooth/hcsecd.conf</filename>. An
|
file is <filename>/etc/bluetooth/hcsecd.conf</filename>. An
|
||||||
example section for a cellular phone with the
|
example section for a cellular phone with the
|
||||||
<acronym>PIN</acronym> code set to
|
<acronym>PIN</acronym> code set to <literal>1234</literal> is
|
||||||
<literal>1234</literal> is shown below:</para>
|
shown below:</para>
|
||||||
|
|
||||||
<programlisting>device {
|
<programlisting>device {
|
||||||
bdaddr 00:80:37:29:19:a4;
|
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>
|
<acronym>PPP</acronym> Profiles</title>
|
||||||
|
|
||||||
<para>A Dial-Up Networking (<acronym>DUN</acronym>) profile can
|
<para>A Dial-Up Networking (<acronym>DUN</acronym>) profile can
|
||||||
be used to configure a cellular phone as a
|
be used to configure a cellular phone as a wireless modem for
|
||||||
wireless modem for connecting to a dial-up Internet access
|
connecting to a dial-up Internet access server. It can also
|
||||||
server. It can also be used to configure a computer to
|
be used to configure a computer to receive data calls from a
|
||||||
receive data calls from a cellular phone.</para>
|
cellular phone.</para>
|
||||||
|
|
||||||
<para>Network access with a <acronym>PPP</acronym> profile can
|
<para>Network access with a <acronym>PPP</acronym> profile can
|
||||||
be used to provide <acronym>LAN</acronym> access for a single Bluetooth
|
be used to provide <acronym>LAN</acronym> access for a single
|
||||||
device or multiple Bluetooth devices. It can also provide
|
Bluetooth device or multiple Bluetooth devices. It can also
|
||||||
<acronym>PC</acronym> to <acronym>PC</acronym> connection using <acronym>PPP</acronym>
|
provide <acronym>PC</acronym> to <acronym>PC</acronym>
|
||||||
networking over serial cable emulation.</para>
|
connection using <acronym>PPP</acronym> networking over serial
|
||||||
|
cable emulation.</para>
|
||||||
|
|
||||||
<para>In &os;, these profiles are implemented with &man.ppp.8;
|
<para>In &os;, these profiles are implemented with &man.ppp.8;
|
||||||
and the &man.rfcomm.pppd.8; wrapper which converts a
|
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
|
<filename>/etc/ppp/ppp.conf</filename>. Consult
|
||||||
&man.rfcomm.pppd.8; for examples.</para>
|
&man.rfcomm.pppd.8; for examples.</para>
|
||||||
|
|
||||||
<para>In this example, &man.rfcomm.pppd.8; is used
|
<para>In this example, &man.rfcomm.pppd.8; is used to open a
|
||||||
to open a connection to a remote
|
connection to a remote device with a
|
||||||
device with a <literal>BD_ADDR</literal> of <literal>00:80:37:29:19:a4</literal>
|
<literal>BD_ADDR</literal> of
|
||||||
on a <acronym>DUN</acronym> <acronym>RFCOMM</acronym> channel:</para>
|
<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>
|
<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
|
<para>The actual channel number will be obtained from the remote
|
||||||
obtained from the remote device using the <acronym>SDP</acronym> protocol.
|
device using the <acronym>SDP</acronym> protocol. It is
|
||||||
It is possible to specify the <acronym>RFCOMM</acronym>
|
possible to specify the <acronym>RFCOMM</acronym> channel by
|
||||||
channel by hand, and in this case &man.rfcomm.pppd.8; will
|
hand, and in this case &man.rfcomm.pppd.8; will not perform
|
||||||
not perform the <acronym>SDP</acronym> query. Use
|
the <acronym>SDP</acronym> query. Use &man.sdpcontrol.8; to
|
||||||
&man.sdpcontrol.8; to find out the <acronym>RFCOMM</acronym>
|
find out the <acronym>RFCOMM</acronym> channel on the remote
|
||||||
channel on the remote device.</para>
|
device.</para>
|
||||||
|
|
||||||
<para>In order to provide network access with the
|
<para>In order to provide network access with the
|
||||||
<acronym>PPP</acronym> <acronym>LAN</acronym> service,
|
<acronym>PPP</acronym> <acronym>LAN</acronym> service,
|
||||||
|
|
@ -2488,61 +2491,62 @@ hcsecd[16484]: Sending PIN_Code_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:
|
||||||
<sect2>
|
<sect2>
|
||||||
<title>Bluetooth Protocols</title>
|
<title>Bluetooth Protocols</title>
|
||||||
|
|
||||||
<para>This section provides an overview of the various Bluetooth protocols,
|
<para>This section provides an overview of the various Bluetooth
|
||||||
their function, and associated utilities.</para>
|
protocols, their function, and associated utilities.</para>
|
||||||
|
|
||||||
<sect3>
|
<sect3>
|
||||||
<title>Logical Link Control and Adaptation Protocol
|
<title>Logical Link Control and Adaptation Protocol
|
||||||
(<acronym>L2CAP</acronym>)</title>
|
(<acronym>L2CAP</acronym>)</title>
|
||||||
|
|
||||||
<indexterm>
|
<indexterm>
|
||||||
<primary>L2CAP</primary>
|
<primary>L2CAP</primary>
|
||||||
</indexterm>
|
</indexterm>
|
||||||
|
|
||||||
<para>The Logical Link Control and Adaptation Protocol
|
<para>The Logical Link Control and Adaptation Protocol
|
||||||
(<acronym>L2CAP</acronym>) provides connection-oriented and
|
(<acronym>L2CAP</acronym>) provides connection-oriented and
|
||||||
connectionless data services to upper layer protocols.
|
connectionless data services to upper layer protocols.
|
||||||
<acronym>L2CAP</acronym> permits
|
<acronym>L2CAP</acronym> permits higher level protocols and
|
||||||
higher level protocols and applications to transmit and
|
applications to transmit and receive
|
||||||
receive <acronym>L2CAP</acronym> data packets up to 64
|
<acronym>L2CAP</acronym> data packets up to 64 kilobytes in
|
||||||
kilobytes in length.</para>
|
length.</para>
|
||||||
|
|
||||||
<para><acronym>L2CAP</acronym> is based around the concept of
|
<para><acronym>L2CAP</acronym> is based around the concept of
|
||||||
<emphasis>channels</emphasis>. A channel is a logical
|
<emphasis>channels</emphasis>. A channel is a logical
|
||||||
connection on top of a baseband connection, where each channel is
|
connection on top of a baseband connection, where each
|
||||||
bound to a single protocol in a many-to-one fashion. Multiple
|
channel is bound to a single protocol in a many-to-one
|
||||||
channels can be bound to the same protocol, but a channel
|
fashion. Multiple channels can be bound to the same
|
||||||
cannot be bound to multiple protocols. Each
|
protocol, but a channel cannot be bound to multiple
|
||||||
<acronym>L2CAP</acronym> packet received on a channel is
|
protocols. Each <acronym>L2CAP</acronym> packet received on
|
||||||
directed to the appropriate higher level protocol. Multiple
|
a channel is directed to the appropriate higher level
|
||||||
channels can share the same baseband connection.</para>
|
protocol. Multiple channels can share the same baseband
|
||||||
|
connection.</para>
|
||||||
|
|
||||||
<para>In &os;, a netgraph <acronym>L2CAP</acronym> node
|
<para>In &os;, a netgraph <acronym>L2CAP</acronym> node is
|
||||||
is created for each Bluetooth device. This
|
created for each Bluetooth device. This node is normally
|
||||||
node is normally connected to the
|
connected to the downstream Bluetooth <acronym>HCI</acronym>
|
||||||
downstream Bluetooth <acronym>HCI</acronym> node and upstream
|
node and upstream Bluetooth socket nodes. The default name
|
||||||
Bluetooth socket nodes. The default name for the
|
for the <acronym>L2CAP</acronym> node is
|
||||||
<acronym>L2CAP</acronym> node is <quote>devicel2cap</quote>.
|
<quote>devicel2cap</quote>. For more details refer to
|
||||||
For more details refer to &man.ng.l2cap.4;.</para>
|
&man.ng.l2cap.4;.</para>
|
||||||
|
|
||||||
<para>A useful command is &man.l2ping.8;, which can be used to
|
<para>A useful command is &man.l2ping.8;, which can be used to
|
||||||
ping other devices. Some Bluetooth implementations might not
|
ping other devices. Some Bluetooth implementations might
|
||||||
return all of the data sent to them, so <literal>0
|
not return all of the data sent to them, so <literal>0
|
||||||
bytes</literal> in the following example is normal.</para>
|
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=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=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=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>
|
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
|
<para>The &man.l2control.8; utility is used to perform various
|
||||||
operations on <acronym>L2CAP</acronym> nodes. This example
|
operations on <acronym>L2CAP</acronym> nodes. This example
|
||||||
shows how to obtain the list of logical connections (channels)
|
shows how to obtain the list of logical connections
|
||||||
and the list of baseband connections for the local
|
(channels) and the list of baseband connections for the
|
||||||
device:</para>
|
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:
|
L2CAP channels:
|
||||||
Remote BD_ADDR SCID/ DCID PSM IMTU/ OMTU State
|
Remote BD_ADDR SCID/ DCID PSM IMTU/ OMTU State
|
||||||
00:07:e0:00:0b:ca 66/ 64 3 132/ 672 OPEN
|
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
|
Remote BD_ADDR Handle Flags Pending State
|
||||||
00:07:e0:00:0b:ca 41 O 0 OPEN</screen>
|
00:07:e0:00:0b:ca 41 O 0 OPEN</screen>
|
||||||
|
|
||||||
<para>Another diagnostic tool is &man.btsockstat.1;. It is
|
<para>Another diagnostic tool is &man.btsockstat.1;. It is
|
||||||
similar to &man.netstat.1;, but for Bluetooth network-related
|
similar to &man.netstat.1;, but for Bluetooth
|
||||||
data structures. The example below shows the same logical
|
network-related data structures. The example below shows
|
||||||
connection as &man.l2control.8; above.</para>
|
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
|
Active L2CAP sockets
|
||||||
PCB Recv-Q Send-Q Local address/PSM Foreign address CID State
|
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
|
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
|
Active RFCOMM sockets
|
||||||
PCB Recv-Q Send-Q Local address Foreign address Chan DLCI State
|
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>
|
c2e8bc80 0 250 00:02:72:00:d4:1a 00:07:e0:00:0b:ca 3 6 OPEN</screen>
|
||||||
</sect3>
|
</sect3>
|
||||||
|
|
||||||
<sect3>
|
<sect3>
|
||||||
<title>Radio Frequency Communication (<acronym>RFCOMM</acronym>)</title>
|
<title>Radio Frequency Communication
|
||||||
|
(<acronym>RFCOMM</acronym>)</title>
|
||||||
|
|
||||||
<para>The <acronym>RFCOMM</acronym> protocol provides emulation
|
<para>The <acronym>RFCOMM</acronym> protocol provides
|
||||||
of serial ports over the <acronym>L2CAP</acronym> protocol.
|
emulation of serial ports over the <acronym>L2CAP</acronym>
|
||||||
<acronym>RFCOMM</acronym> is a simple transport protocol,
|
protocol. <acronym>RFCOMM</acronym> is a simple transport
|
||||||
with additional provisions for emulating the 9 circuits of
|
protocol, with additional provisions for emulating the 9
|
||||||
RS-232 (EIATIA-232-E) serial ports. It
|
circuits of RS-232 (EIATIA-232-E) serial ports. It
|
||||||
supports up to 60 simultaneous connections
|
supports up to 60 simultaneous connections
|
||||||
(<acronym>RFCOMM</acronym> channels) between two Bluetooth
|
(<acronym>RFCOMM</acronym> channels) between two Bluetooth
|
||||||
devices.</para>
|
devices.</para>
|
||||||
|
|
||||||
<para>For the purposes of <acronym>RFCOMM</acronym>, a complete
|
<para>For the purposes of <acronym>RFCOMM</acronym>, a
|
||||||
communication path involves two applications running on the
|
complete communication path involves two applications
|
||||||
communication endpoints with a communication segment between
|
running on the communication endpoints with a communication
|
||||||
them. <acronym>RFCOMM</acronym> is intended to cover
|
segment between them. <acronym>RFCOMM</acronym> is intended
|
||||||
applications that make use of the serial ports of the devices
|
to cover applications that make use of the serial ports of
|
||||||
in which they reside. The communication segment is a direct
|
the devices in which they reside. The communication segment
|
||||||
connect Bluetooth link from one device to another.</para>
|
is a direct connect Bluetooth link from one device to
|
||||||
|
another.</para>
|
||||||
|
|
||||||
<para><acronym>RFCOMM</acronym> is only concerned with the
|
<para><acronym>RFCOMM</acronym> is only concerned with the
|
||||||
connection between the devices in the direct connect case,
|
connection between the devices in the direct connect case,
|
||||||
or between the device and a modem in the network case.
|
or between the device and a modem in the network case.
|
||||||
<acronym>RFCOMM</acronym> can support other configurations,
|
<acronym>RFCOMM</acronym> can support other configurations,
|
||||||
such as modules that communicate via Bluetooth wireless
|
such as modules that communicate via Bluetooth wireless
|
||||||
technology on one side and provide a wired interface on the
|
technology on one side and provide a wired interface on the
|
||||||
other side.</para>
|
other side.</para>
|
||||||
|
|
||||||
<para>In &os;, <acronym>RFCOMM</acronym> is implemented at the
|
<para>In &os;, <acronym>RFCOMM</acronym> is implemented at the
|
||||||
Bluetooth sockets layer.</para>
|
Bluetooth sockets layer.</para>
|
||||||
</sect3>
|
</sect3>
|
||||||
|
|
||||||
<sect3>
|
<sect3>
|
||||||
<title>Service Discovery Protocol
|
<title>Service Discovery Protocol
|
||||||
(<acronym>SDP</acronym>)</title>
|
(<acronym>SDP</acronym>)</title>
|
||||||
|
|
||||||
<indexterm>
|
<indexterm>
|
||||||
<primary>SDP</primary>
|
<primary>SDP</primary>
|
||||||
</indexterm>
|
</indexterm>
|
||||||
|
|
||||||
<para>The Service Discovery Protocol (<acronym>SDP</acronym>)
|
<para>The Service Discovery Protocol (<acronym>SDP</acronym>)
|
||||||
provides the means for client applications to discover the
|
provides the means for client applications to discover the
|
||||||
existence of services provided by server applications as well
|
existence of services provided by server applications as
|
||||||
as the attributes of those services. The attributes of a
|
well as the attributes of those services. The attributes of
|
||||||
service include the type or class of service offered and the
|
a service include the type or class of service offered and
|
||||||
mechanism or protocol information needed to utilize the
|
the mechanism or protocol information needed to utilize the
|
||||||
service.</para>
|
service.</para>
|
||||||
|
|
||||||
<para><acronym>SDP</acronym> involves communication between a
|
<para><acronym>SDP</acronym> involves communication between a
|
||||||
<acronym>SDP</acronym> server and a <acronym>SDP</acronym>
|
<acronym>SDP</acronym> server and a <acronym>SDP</acronym>
|
||||||
client. The server maintains a list of service records that
|
client. The server maintains a list of service records that
|
||||||
describe the characteristics of services associated with the
|
describe the characteristics of services associated with the
|
||||||
server. Each service record contains information about a
|
server. Each service record contains information about a
|
||||||
single service. A client may retrieve information from a
|
single service. A client may retrieve information from a
|
||||||
service record maintained by the <acronym>SDP</acronym> server
|
service record maintained by the <acronym>SDP</acronym>
|
||||||
by issuing a <acronym>SDP</acronym> request. If the client,
|
server by issuing a <acronym>SDP</acronym> request. If the
|
||||||
or an application associated with the client, decides to use
|
client, or an application associated with the client,
|
||||||
a service, it must open a separate connection to the service
|
decides to use a service, it must open a separate connection
|
||||||
provider in order to utilize the service.
|
to the service provider in order to utilize the service.
|
||||||
<acronym>SDP</acronym> provides a mechanism for discovering
|
<acronym>SDP</acronym> provides a mechanism for discovering
|
||||||
services and their attributes, but it does not provide a
|
services and their attributes, but it does not provide a
|
||||||
mechanism for utilizing those services.</para>
|
mechanism for utilizing those services.</para>
|
||||||
|
|
||||||
<para>Normally, a <acronym>SDP</acronym> client searches for
|
<para>Normally, a <acronym>SDP</acronym> client searches for
|
||||||
services based on some desired characteristics of the
|
services based on some desired characteristics of the
|
||||||
services. However, there are times when it is desirable to
|
services. However, there are times when it is desirable to
|
||||||
discover which types of services are described by an
|
discover which types of services are described by an
|
||||||
<acronym>SDP</acronym> server's service records without any
|
<acronym>SDP</acronym> server's service records without any
|
||||||
prior information about the services. This process of
|
prior information about the services. This process of
|
||||||
looking for any offered services is called
|
looking for any offered services is called
|
||||||
<emphasis>browsing</emphasis>.</para>
|
<emphasis>browsing</emphasis>.</para>
|
||||||
|
|
||||||
<para>The Bluetooth <acronym>SDP</acronym> server, &man.sdpd.8;,
|
<para>The Bluetooth <acronym>SDP</acronym> server,
|
||||||
and command line client, &man.sdpcontrol.8;, are included in
|
&man.sdpd.8;, and command line client, &man.sdpcontrol.8;,
|
||||||
the standard &os; installation. The following example shows
|
are included in the standard &os; installation. The
|
||||||
how to perform a <acronym>SDP</acronym> browse query.</para>
|
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
|
Record Handle: 00000000
|
||||||
Service Class ID List:
|
Service Class ID List:
|
||||||
Service Discovery Server (0x1000)
|
Service Discovery Server (0x1000)
|
||||||
|
|
@ -2668,83 +2676,82 @@ Protocol Descriptor List:
|
||||||
Bluetooth Profile Descriptor List:
|
Bluetooth Profile Descriptor List:
|
||||||
LAN Access Using PPP (0x1102) ver. 1.0</screen>
|
LAN Access Using PPP (0x1102) ver. 1.0</screen>
|
||||||
|
|
||||||
<para>Note that each service has a list of attributes, such
|
<para>Note that each service has a list of attributes, such
|
||||||
as the <acronym>RFCOMM</acronym> channel. Depending on the
|
as the <acronym>RFCOMM</acronym> channel. Depending on the
|
||||||
service, the user might need to make note of some of the
|
service, the user might need to make note of some of the
|
||||||
attributes. Some Bluetooth implementations do not support
|
attributes. Some Bluetooth implementations do not support
|
||||||
service browsing and may return an empty list. In this case,
|
service browsing and may return an empty list. In this
|
||||||
it is possible to search for the specific service. The
|
case, it is possible to search for the specific service.
|
||||||
example below shows how to search for the
|
The example below shows how to search for the
|
||||||
<acronym>OBEX</acronym> Object Push
|
<acronym>OBEX</acronym> Object Push
|
||||||
(<acronym>OPUSH</acronym>) service:</para>
|
(<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
|
<para>Offering services on &os; to Bluetooth clients is done
|
||||||
with the &man.sdpd.8; server. The following line can be added
|
with the &man.sdpd.8; server. The following line can be
|
||||||
to <filename>/etc/rc.conf</filename>:</para>
|
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
|
<para>Then the &man.sdpd.8; daemon can be started with:</para>
|
||||||
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
|
<para>The local server application that wants to provide a
|
||||||
Bluetooth service to remote clients will register the service
|
Bluetooth service to remote clients will register the
|
||||||
with the local <acronym>SDP</acronym> daemon. An example of
|
service with the local <acronym>SDP</acronym> daemon. An
|
||||||
such an application is &man.rfcomm.pppd.8;. Once started,
|
example of such an application is &man.rfcomm.pppd.8;. Once
|
||||||
it will register the Bluetooth LAN service with the local
|
started, it will register the Bluetooth LAN service with the
|
||||||
<acronym>SDP</acronym> daemon.</para>
|
local <acronym>SDP</acronym> daemon.</para>
|
||||||
|
|
||||||
<para>The list of services registered with the local
|
<para>The list of services registered with the local
|
||||||
<acronym>SDP</acronym> server can be obtained by issuing a
|
<acronym>SDP</acronym> server can be obtained by issuing a
|
||||||
<acronym>SDP</acronym> browse query via the local control
|
<acronym>SDP</acronym> browse query via the local control
|
||||||
channel:</para>
|
channel:</para>
|
||||||
|
|
||||||
<screen>&prompt.root; <userinput>sdpcontrol -l browse</userinput></screen>
|
<screen>&prompt.root; <userinput>sdpcontrol -l browse</userinput></screen>
|
||||||
</sect3>
|
</sect3>
|
||||||
|
|
||||||
<sect3>
|
<sect3>
|
||||||
<title><acronym>OBEX</acronym> Object Push
|
<title><acronym>OBEX</acronym> Object Push
|
||||||
(<acronym>OPUSH</acronym>)</title>
|
(<acronym>OPUSH</acronym>)</title>
|
||||||
|
|
||||||
<indexterm>
|
<indexterm>
|
||||||
<primary>OBEX</primary>
|
<primary>OBEX</primary>
|
||||||
</indexterm>
|
</indexterm>
|
||||||
|
|
||||||
<para>Object Exchange (<acronym>OBEX</acronym>) is a widely used protocol for
|
<para>Object Exchange (<acronym>OBEX</acronym>) is a widely
|
||||||
simple file transfers between mobile devices. Its main use
|
used protocol for simple file transfers between mobile
|
||||||
is in infrared communication, where it is used for generic
|
devices. Its main use is in infrared communication, where
|
||||||
file transfers between notebooks or <acronym>PDA</acronym>s,
|
it is used for generic file transfers between notebooks or
|
||||||
and for sending business cards or calendar entries between
|
<acronym>PDA</acronym>s, and for sending business cards or
|
||||||
cellular phones and other devices with Personal Information Manager (<acronym>PIM</acronym>)
|
calendar entries between cellular phones and other devices
|
||||||
applications.</para>
|
with Personal Information Manager (<acronym>PIM</acronym>)
|
||||||
|
applications.</para>
|
||||||
|
|
||||||
<para>The <acronym>OBEX</acronym> server and client are
|
<para>The <acronym>OBEX</acronym> server and client are
|
||||||
implemented by
|
implemented by <application>obexapp</application>, which can
|
||||||
<application>obexapp</application>, which can be installed using the
|
be installed using the <package>comms/obexapp</package>
|
||||||
<package>comms/obexapp</package> package or
|
package or port.</para>
|
||||||
port.</para>
|
|
||||||
|
|
||||||
<para>The <acronym>OBEX</acronym> client is used to push and/or
|
<para>The <acronym>OBEX</acronym> client is used to push
|
||||||
pull objects from the <acronym>OBEX</acronym> server. An example
|
and/or pull objects from the <acronym>OBEX</acronym> server.
|
||||||
object is a business card or an appointment.
|
An example object is a business card or an appointment.
|
||||||
The <acronym>OBEX</acronym> client can obtain the
|
The <acronym>OBEX</acronym> client can obtain the
|
||||||
<acronym>RFCOMM</acronym> channel number from the remote
|
<acronym>RFCOMM</acronym> channel number from the remote
|
||||||
device via <acronym>SDP</acronym>. This can be done by
|
device via <acronym>SDP</acronym>. This can be done by
|
||||||
specifying the service name instead of the
|
specifying the service name instead of the
|
||||||
<acronym>RFCOMM</acronym> channel number. Supported service
|
<acronym>RFCOMM</acronym> channel number. Supported service
|
||||||
names are: <literal>IrMC</literal>, <literal>FTRN</literal>,
|
names are: <literal>IrMC</literal>, <literal>FTRN</literal>,
|
||||||
and <literal>OPUSH</literal>. It is also possible to specify
|
and <literal>OPUSH</literal>. It is also possible to
|
||||||
the <acronym>RFCOMM</acronym> channel as a number. Below is
|
specify the <acronym>RFCOMM</acronym> channel as a number.
|
||||||
an example of an <acronym>OBEX</acronym> session where the
|
Below is an example of an <acronym>OBEX</acronym> session
|
||||||
device information object is pulled from the cellular phone,
|
where the device information object is pulled from the
|
||||||
and a new object, the business card, is pushed into the
|
cellular phone, and a new object, the business card, is
|
||||||
phone's directory.</para>
|
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
|
obex> get telecom/devinfo.txt devinfo-t39.txt
|
||||||
Success, response: OK, Success (0x20)
|
Success, response: OK, Success (0x20)
|
||||||
obex> put new.vcf
|
obex> put new.vcf
|
||||||
|
|
@ -2752,72 +2759,70 @@ Success, response: OK, Success (0x20)
|
||||||
obex> di
|
obex> di
|
||||||
Success, response: OK, Success (0x20)</screen>
|
Success, response: OK, Success (0x20)</screen>
|
||||||
|
|
||||||
<para>In order to provide the <acronym>OPUSH</acronym> service,
|
<para>In order to provide the <acronym>OPUSH</acronym>
|
||||||
&man.sdpd.8; must be running and a root folder, where all
|
service, &man.sdpd.8; must be running and a root folder,
|
||||||
incoming objects will be stored, must be created. The
|
where all incoming objects will be stored, must be created.
|
||||||
default path to the root folder is
|
The default path to the root folder is
|
||||||
<filename>/var/spool/obex</filename>. Finally, start the
|
<filename>/var/spool/obex</filename>. Finally, start the
|
||||||
<acronym>OBEX</acronym> server on a valid
|
<acronym>OBEX</acronym> server on a valid
|
||||||
<acronym>RFCOMM</acronym> channel number. The
|
<acronym>RFCOMM</acronym> channel number. The
|
||||||
<acronym>OBEX</acronym> server will automatically register
|
<acronym>OBEX</acronym> server will automatically register
|
||||||
the <acronym>OPUSH</acronym> service with the local
|
the <acronym>OPUSH</acronym> service with the local
|
||||||
<acronym>SDP</acronym> daemon. The example below shows how
|
<acronym>SDP</acronym> daemon. The example below shows how
|
||||||
to start the <acronym>OBEX</acronym> server.</para>
|
to start the <acronym>OBEX</acronym> server.</para>
|
||||||
|
|
||||||
<screen>&prompt.root; <userinput>obexapp -s -C 10</userinput></screen>
|
<screen>&prompt.root; <userinput>obexapp -s -C 10</userinput></screen>
|
||||||
</sect3>
|
</sect3>
|
||||||
|
|
||||||
<sect3>
|
<sect3>
|
||||||
<title>Serial Port Profile (<acronym>SPP</acronym>)</title>
|
<title>Serial Port Profile (<acronym>SPP</acronym>)</title>
|
||||||
|
|
||||||
<para>The Serial Port Profile (<acronym>SPP</acronym>) allows
|
<para>The Serial Port Profile (<acronym>SPP</acronym>) allows
|
||||||
Bluetooth devices to perform serial cable emulation. This
|
Bluetooth devices to perform serial cable emulation. This
|
||||||
profile allows legacy applications to use Bluetooth as a
|
profile allows legacy applications to use Bluetooth as a
|
||||||
cable replacement, through a virtual serial port
|
cable replacement, through a virtual serial port
|
||||||
abstraction.</para>
|
abstraction.</para>
|
||||||
|
|
||||||
<para>In &os;, &man.rfcomm.sppd.1; implements
|
<para>In &os;, &man.rfcomm.sppd.1; implements
|
||||||
<acronym>SPP</acronym> and a pseudo tty is used as a virtual
|
<acronym>SPP</acronym> and a pseudo tty is used as a virtual
|
||||||
serial port abstraction. The example below shows how to
|
serial port abstraction. The example below shows how to
|
||||||
connect to a remote device's serial port service. A
|
connect to a remote device's serial port service. A
|
||||||
<acronym>RFCOMM</acronym> channel does not have to be
|
<acronym>RFCOMM</acronym> channel does not have to be
|
||||||
specified as &man.rfcomm.sppd.1; can obtain it from the
|
specified as &man.rfcomm.sppd.1; can obtain it from the
|
||||||
remote device via <acronym>SDP</acronym>. To override this,
|
remote device via <acronym>SDP</acronym>. To override this,
|
||||||
specify a <acronym>RFCOMM</acronym> channel on the command
|
specify a <acronym>RFCOMM</acronym> channel on the command
|
||||||
line.</para>
|
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>
|
rfcomm_sppd[94692]: Starting on /dev/ttyp6...</screen>
|
||||||
|
|
||||||
<para>Once connected, the pseudo tty can be used as serial
|
<para>Once connected, the pseudo tty can be used as serial
|
||||||
port:</para>
|
port:</para>
|
||||||
|
|
||||||
<screen>&prompt.root; <userinput>cu -l ttyp6</userinput></screen>
|
<screen>&prompt.root; <userinput>cu -l ttyp6</userinput></screen>
|
||||||
</sect3>
|
</sect3>
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
<sect2>
|
<sect2>
|
||||||
<title>Troubleshooting</title>
|
<title>Troubleshooting</title>
|
||||||
|
|
||||||
<para>By default, when &os; is accepting a new
|
<para>By default, when &os; is accepting a new connection, it
|
||||||
connection, it tries to perform a role switch and become
|
tries to perform a role switch and become master. Some older
|
||||||
master. Some older Bluetooth devices which do not support role
|
Bluetooth devices which do not support role switching will not
|
||||||
switching will not be able
|
be able to connect. Since role switching is performed when a
|
||||||
to connect. Since role switching is performed when a
|
new connection is being established, it is not possible to ask
|
||||||
new connection is being established, it is not possible
|
the remote device if it supports role switching. However,
|
||||||
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>
|
||||||
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
|
<para>To display Bluetooth packets, use the third-party package
|
||||||
<application>hcidump</application>, which can be installed using the
|
<application>hcidump</application>, which can be installed
|
||||||
<package>comms/hcidump</package> package or
|
using the <package>comms/hcidump</package> package or port.
|
||||||
port. This utility is similar to &man.tcpdump.1; and can
|
This utility is similar to &man.tcpdump.1; and can be used to
|
||||||
be used to display the contents of Bluetooth packets on
|
display the contents of Bluetooth packets on the terminal and
|
||||||
the terminal and to dump the Bluetooth packets to a
|
to dump the Bluetooth packets to a file.</para>
|
||||||
file.</para>
|
|
||||||
</sect2>
|
</sect2>
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue