network-bluetooth.html

FreeBSD操作系统的详细使用手册

class="CITEREFENTRY"><span class="REFENTRYTITLE">ng_l2cap</span>(4)</span></a> manual
page.</p>

<p>A useful command is <a
href="http://www.FreeBSD.org/cgi/man.cgi?query=l2ping&sektion=8"><span
class="CITEREFENTRY"><span class="REFENTRYTITLE">l2ping</span>(8)</span></a>, which can
be used to ping other devices. Some Bluetooth implementations might not return all of the
data sent to them, so <var class="LITERAL">0 bytes</var> in the following example is
normal.</p>

<pre class="SCREEN">
<samp class="PROMPT">#</samp> <kbd class="USERINPUT">l2ping -a 00:80:37:29:19:a4</kbd>
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
</pre>

<p>The <a href="http://www.FreeBSD.org/cgi/man.cgi?query=l2control&sektion=8"><span
class="CITEREFENTRY"><span class="REFENTRYTITLE">l2control</span>(8)</span></a> utility
is used to perform various operations on L2CAP nodes. This example shows how to obtain
the list of logical connections (channels) and the list of baseband connections for the
local device:</p>

<pre class="SCREEN">
<samp class="PROMPT">%</samp> <kbd
class="USERINPUT">l2control -a 00:02:72:00:d4:1a read_channel_list</kbd>
L2CAP channels:
Remote BD_ADDR     SCID/ DCID   PSM  IMTU/ OMTU State
00:07:e0:00:0b:ca    66/   64     3   132/  672 OPEN
<samp class="PROMPT">%</samp> <kbd
class="USERINPUT">l2control -a 00:02:72:00:d4:1a read_connection_list</kbd>
L2CAP connections:
Remote BD_ADDR    Handle Flags Pending State
00:07:e0:00:0b:ca     41 O           0 OPEN
</pre>

<p>Another diagnostic tool is <a
href="http://www.FreeBSD.org/cgi/man.cgi?query=btsockstat&sektion=1"><span
class="CITEREFENTRY"><span class="REFENTRYTITLE">btsockstat</span>(1)</span></a>. It does
a job similar to as <a
href="http://www.FreeBSD.org/cgi/man.cgi?query=netstat&sektion=1"><span
class="CITEREFENTRY"><span class="REFENTRYTITLE">netstat</span>(1)</span></a> does, but
for Bluetooth network-related data structures. The example below shows the same logical
connection as <a
href="http://www.FreeBSD.org/cgi/man.cgi?query=l2control&sektion=8"><span
class="CITEREFENTRY"><span class="REFENTRYTITLE">l2control</span>(8)</span></a>
above.</p>

<pre class="SCREEN">
<samp class="PROMPT">%</samp> <kbd class="USERINPUT">btsockstat</kbd>
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
Active RFCOMM sessions
L2PCB    PCB      Flag MTU   Out-Q DLCs State
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
</pre>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="AEN36740" name="AEN36740">24.4.5 RFCOMM Protocol</a></h2>

<p>The RFCOMM protocol provides emulation of serial ports over the L2CAP protocol. The
protocol is based on the ETSI standard TS 07.10. RFCOMM is a simple transport protocol,
with additional provisions for emulating the 9 circuits of RS-232 (EIATIA-232-E) serial
ports. The RFCOMM protocol supports up to 60 simultaneous connections (RFCOMM channels)
between two Bluetooth devices.</p>

<p>For the purposes of RFCOMM, a complete communication path involves two applications
running on different devices (the communication endpoints) with a communication segment
between them. RFCOMM is intended to cover applications that make use of the serial ports
of the devices in which they reside. The communication segment is a Bluetooth link from
one device to another (direct connect).</p>

<p>RFCOMM 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. RFCOMM 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.</p>

<p>In FreeBSD the RFCOMM protocol is implemented at the Bluetooth sockets layer.</p>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="AEN36748" name="AEN36748">24.4.6 Pairing of Devices</a></h2>

<p>By default, Bluetooth communication is not authenticated, and any device can talk to
any other device. A Bluetooth device (for example, cellular phone) may choose to require
authentication to provide a particular service (for example, Dial-Up service). Bluetooth
authentication is normally done with <span class="emphasis"><i class="EMPHASIS">PIN
codes</i></span>. A PIN code is an ASCII string up to 16 characters in length. User is
required to enter the same PIN code on both devices. Once user has entered the PIN code,
both devices will generate a <span class="emphasis"><i class="EMPHASIS">link
key</i></span>. After that the link key can be stored either in the devices themselves or
in a persistent storage. Next time both devices will use previously generated link key.
The described above procedure is called <span class="emphasis"><i
class="EMPHASIS">pairing</i></span>. Note that if the link key is lost by any device then
pairing must be repeated.</p>

<p>The <a href="http://www.FreeBSD.org/cgi/man.cgi?query=hcsecd&sektion=8"><span
class="CITEREFENTRY"><span class="REFENTRYTITLE">hcsecd</span>(8)</span></a> daemon is
responsible for handling of all Bluetooth authentication requests. The default
configuration file is <tt class="FILENAME">/etc/bluetooth/hcsecd.conf</tt>. An example
section for a cellular phone with the PIN code arbitrarily set to ``1234'' is shown
below:</p>

<pre class="PROGRAMLISTING">
device {
        bdaddr  00:80:37:29:19:a4;
        name    "Pav's T39";
        key     nokey;
        pin     "1234";
      }
</pre>

<p>There is no limitation on PIN codes (except length). Some devices (for example
Bluetooth headsets) may have a fixed PIN code built in. The <var class="OPTION">-d</var>
switch forces the <a
href="http://www.FreeBSD.org/cgi/man.cgi?query=hcsecd&sektion=8"><span
class="CITEREFENTRY"><span class="REFENTRYTITLE">hcsecd</span>(8)</span></a> daemon to
stay in the foreground, so it is easy to see what is happening. Set the remote device to
receive pairing and initiate the Bluetooth connection to the remote device. The remote
device should say that pairing was accepted, and request the PIN code. Enter the same PIN
code as you have in <tt class="FILENAME">hcsecd.conf</tt>. Now your PC and the remote
device are paired. Alternatively, you can initiate pairing on the remote device. The
following is a sample of the <b class="APPLICATION">hcsecd</b> daemon output:</p>

<pre class="PROGRAMLISTING">
hcsecd[16484]: Got Link_Key_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4
hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', link key doesn't exist
hcsecd[16484]: Sending Link_Key_Negative_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4
hcsecd[16484]: Got PIN_Code_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4
hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', PIN code exists
hcsecd[16484]: Sending PIN_Code_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4
</pre>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="AEN36771" name="AEN36771">24.4.7 Service Discovery Protocol
(SDP)</a></h2>

<p>The Service Discovery Protocol (SDP) 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.</p>

<p>SDP involves communication between a SDP server and a SDP 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 SDP server by issuing a SDP
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. SDP provides a mechanism for discovering services and their attributes, but
it does not provide a mechanism for utilizing those services.</p>

<p>Normally, a SDP 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 SDP server's service records without any a priori
information about the services. This process of looking for any offered services is
called <span class="emphasis"><i class="EMPHASIS">browsing</i></span>.</p>

<p>The Bluetooth SDP server <a
href="http://www.FreeBSD.org/cgi/man.cgi?query=sdpd&sektion=8"><span
class="CITEREFENTRY"><span class="REFENTRYTITLE">sdpd</span>(8)</span></a> and command
line client <a href="http://www.FreeBSD.org/cgi/man.cgi?query=sdpcontrol&sektion=8"><span
class="CITEREFENTRY"><span class="REFENTRYTITLE">sdpcontrol</span>(8)</span></a> are
included in the standard FreeBSD installation. The following example shows how to perform
a SDP browse query.</p>

<pre class="SCREEN">
<samp class="PROMPT">%</samp> <kbd
class="USERINPUT">sdpcontrol -a 00:01:03:fc:6e:ec browse</kbd>
Record Handle: 00000000
Service Class ID List:
        Service Discovery Server (0x1000)
Protocol Descriptor List:
        L2CAP (0x0100)
                Protocol specific parameter #1: u/int/uuid16 1
                Protocol specific parameter #2: u/int/uuid16 1

Record Handle: 0x00000001
Service Class ID List:
        Browse Group Descriptor (0x1001)

Record Handle: 0x00000002
Service Class ID List:
        LAN Access Using PPP (0x1102)
Protocol Descriptor List:
        L2CAP (0x0100)
        RFCOMM (0x0003)
                Protocol specific parameter #1: u/int8/bool 1
Bluetooth Profile Descriptor List:
        LAN Access Using PPP (0x1102) ver. 1.0
</pre>

<p>... and so on. Note that each service has a list of attributes (RFCOMM channel for
example). Depending on the service you might need to make a 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 OBEX Object Push (OPUSH) service:</p>

<pre class="SCREEN">
<samp class="PROMPT">%</samp> <kbd
class="USERINPUT">sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH</kbd>
</pre>

<p>Offering services on FreeBSD to Bluetooth clients is done with the <a
href="http://www.FreeBSD.org/cgi/man.cgi?query=sdpd&sektion=8"><span
class="CITEREFENTRY"><span class="REFENTRYTITLE">sdpd</span>(8)</span></a> server:</p>

<pre class="SCREEN">
<samp class="PROMPT">#</samp> <kbd class="USERINPUT">sdpd</kbd>
</pre>

<p>The local server application that wants to provide Bluetooth service to the remote
clients will register service with the local SDP daemon. The example of such application
is <a href="http://www.FreeBSD.org/cgi/man.cgi?query=rfcomm_pppd&sektion=8"><span
class="CITEREFENTRY"><span class="REFENTRYTITLE">rfcomm_pppd</span>(8)</span></a>. Once
started it will register Bluetooth LAN service with the local SDP daemon.</p>

<p>The list of services registered with the local SDP server can be obtained by issuing
SDP browse query via local control channel:</p>

<pre class="SCREEN">
<samp class="PROMPT">#</samp> <kbd class="USERINPUT">sdpcontrol -l browse</kbd>
</pre>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="AEN36806" name="AEN36806">24.4.8 Dial-Up Networking (DUN) and