os/doc
3
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Add Bluetooth chapter for the FreeBSD handbook

Browse source 
Submitted by: Pav Lucistnik <pav@oook.cz>
Reviewed by: imp, hmp
Approved by: imp (mentor)
This commit is contained in:
Maksim Yevmenkin 2003-11-11 03:02:28 +00:00
parent bc42f4346d
commit 82efac4ad3
Notes: svn2git 2020-12-08 03:00:23 +00:00 
svn path=/head/; revision=18800
2 changed files with 572 additions and 0 deletions
en_US.ISO8859-1/books/handbook/advanced-networking
chapter.sgml
share/sgml
man-refs.ent

571
en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml
View file

@ -929,6 +929,576 @@ wi0: flags=8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt; mtu 1500
</sect2>
</sect1>
<sect1 id="network-bluetooth">
<sect1info>
<authorgroup>
<author>
<firstname>Pav</firstname>
<surname>Lucistnik</surname>
<contrib>Written by </contrib>
<affiliation>
<address><email>pav@oook.cz</email></address>
</affiliation>
</author>
</authorgroup>
</sect1info>
<title>Bluetooth</title>
<indexterm><primary>Bluetooth</primary></indexterm>
<sect2>
<title>Introduction</title>
<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 the other popular
wireless technology, Wi-Fi, Bluetooth offers higher level service
profiles, e.g. FTP-like file servers, file pushing, voice transport,
serial line emulation, and more.</para>
<para>The Bluetooth stack in &os; is implemented using the Netgraph
framework (see &man.netgraph.4;). A broad variety of Bluetooth USB
dongles is supported by the &man.ng.ubt.4; driver. The Broadcom BCM2033
chip based Bluetooth devices are supported via 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 via &man.sio.4;, &man.ng.h4.4;
and &man.hcseriald.8;. This chapter describes the use of the USB
Bluetooth dongle. Bluetooth support is available in &os; 5.0 and newer
systems.</para>
</sect2>
<sect2>
<title>Plugging in the Device</title>
<para>By default Bluetooth device drivers are available as kernel modules.
Before attaching a device, you will need to load the driver into the
kernel.</para>
<screen>&prompt.root; <userinput>kldload ng_ubt</userinput></screen>
<para>If the Bluetooth device is present in the system during system
startup, load the module from
<filename>/boot/loader.conf</filename>.</para>
<programlisting>ng_ubt_load="YES"</programlisting>
<para>Plug in your USB dongle. The output similar to the following will
appear on the console (or in syslog).</para>
<screen>ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2
ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2
ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3,
wMaxPacketSize=49, nframes=6, buffer size=294</screen>
<para>Copy
<filename>/usr/share/examples/netgraph/bluetooth/rc.bluetooth</filename>
into some convenient place, like <filename>/etc/rc.bluetooth</filename>.
This script is used to start and stop the Bluetooth stack. It is a good
idea to stop the stack before unplugging the device, but it is not
(usually) fatal. When starting the stack, you will receive output similar
to the following:</para>
<screen>&prompt.root; <userinput>/etc/rc.bluetooth start ubt0</userinput>
BD_ADDR: 00:02:72:00:d4:1a
Features: 0xff 0xff 0xf 00 00 00 00 00
&lt;3-Slot&gt; &lt;5-Slot&gt; &lt;Encryption&gt; &lt;Slot offset&gt;
&lt;Timing accuracy&gt; &lt;Switch&gt; &lt;Hold mode&gt; &lt;Sniff mode&gt;
&lt;Park mode&gt; &lt;RSSI&gt; &lt;Channel quality&gt; &lt;SCO link&gt;
&lt;HV2 packets&gt; &lt;HV3 packets&gt; &lt;u-law log&gt; &lt;A-law log&gt; &lt;CVSD&gt;
&lt;Paging scheme&gt; &lt;Power control&gt; &lt;Transparent SCO data&gt;
Max. ACL packet size: 192 bytes
Number of ACL packets: 8
Max. SCO packet size: 64 bytes
Number of SCO packets: 8</screen>
</sect2>
<indexterm><primary>HCI</primary></indexterm>
<sect2>
<title>Host Controller Interface (HCI)</title>
<para>Host Controller Interface (HCI) provides a command interface to the
baseband controller and link manager, and access to hardware status and
control registers. This interface provides a uniform method of accessing
the Bluetooth baseband capabilities. HCI layer on the Host exchanges
data and commands with the HCI firmware on the Bluetooth hardware.
The Host Controller Transport Layer (i.e. physical bus) driver provides
both HCI layers with the ability to exchange information with each
other.</para>
<para>A single Netgraph node of type <emphasis>hci</emphasis> is
created for a single Bluetooth device. The HCI node is normally
connected to the Bluetooth device driver node (downstream) and
the L2CAP node (upstream). All HCI operations must be performed
on the HCI node and not on the device driver node. Default name
for the HCI node is <quote>devicehci</quote>.
For more details refer to the &man.ng.hci.4; man page.</para>
<para>One of the most common tasks is discovery of Bluetooth devices in
RF proximity. This operation is called <emphasis>inquiry</emphasis>.
Inquiry and other HCI realated operations are done with the
&man.hccontrol.8; utility. The example below shows how to find out
which Bluetooth devices are in range. You should receive the list of
devices in a few seconds. Note that a remote device will only answer
the inquiry if it put into <emphasis>discoverable</emphasis>
mode.</para>
<screen>&prompt.user; <userinput>hccontrol -n ubt0hci inquiry</userinput>
Inquiry result, num_responses=1
Inquiry result #0
BD_ADDR: 00:80:37:29:19:a4
Page Scan Rep. Mode: 0x1
Page Scan Period Mode: 00
Page Scan Mode: 00
Class: 52:02:04
Clock offset: 0x78ef
Inquiry complete. Status: No error [00]</screen>
<para><literal>BD_ADDR</literal> is unique address of a Bluetooth
device, similar to MAC addresses of a network card. This address
is needed for further communication with a device. It is possible
to assign human readable name to a BD_ADDR.
The <filename>/etc/bluetooth/hosts</filename> file contains information
regarding the known Bluetooth hosts. The following example shows how
to obtain 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
Name: Pav's T39</screen>
<para>If you perform an inquiry on a remote Bluetooth device, it will
find your computer as <quote>your.host.name (ubt0)</quote>. The name
assigned to the local device can be changed at any time.</para>
<para>The Bluetooth system provides a point-to-point connection (only two
Bluetooth units involved), or a point-to-multipoint connection. In the
point-to-multipoint connection the connection is shared among several
Bluetooth devices. The following example shows how to obtain the list
of active baseband connections for the local device.</para>
<screen>&prompt.user; <userinput>hccontrol -n ubt0hci read_connection_list</userinput>
Remote BD_ADDR Handle Type Mode Role Encrypt Pending Queue State
00:80:37:29:19:a4 41 ACL 0 MAST NONE 0 0 OPEN</screen>
<para>A <emphasis>connection handle</emphasis> is useful when termination
of the baseband connection is required. Note, that it is normally not
required to do it by hand. The stack will automatically terminate
inactive baseband connections.</para>
<screen>&prompt.root; <userinput>hccontrol -n ubt0hci disconnect 41</userinput>
Connection handle: 41
Reason: Connection terminated by local host [0x16]</screen>
<para>Refer to <command>hccontrol help</command> for a complete listing
of available HCI commands. Most of the HCI commands do not require
superuser privileges.</para>
</sect2>
<indexterm><primary>L2CAP</primary></indexterm>
<sect2>
<title>Logical Link Control and Adaptation Protocol (L2CAP)</title>
<para>Logical Link Control and Adaptation Protocol (L2CAP) provides
connection-oriented and connectionless data services to upper layer
protocols with protocol multiplexing capability and segmentation and
reassembly operation. L2CAP permits higher level protocols and
applications to transmit and receive L2CAP data packets up to 64
kilobytes in length.</para>
<para>L2CAP is based around the concept of <emphasis>channels</emphasis>.
Channel is a logical connection on top of baseband connection. 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 L2CAP packet received on a channel is
directed to the appropriate higher level protocol. Multiple channels
can share the same baseband connection.</para>
<para>A single Netgraph node of type <emphasis>l2cap</emphasis> is
created for a single Bluetooth device. The L2CAP node is normally
connected to the Bluetooth HCI node (downstream) and Bluetooth sockets
nodes (upstream). Default name for the L2CAP node is
<quote>devicel2cap</quote>. For more details refer to the
&man.ng.l2cap.4; man page.</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 <emphasis>0 bytes</emphasis> 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 L2CAP 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>
L2CAP channels:
Remote BD_ADDR SCID/ DCID PSM IMTU/ OMTU State
00:07:e0:00:0b:ca 66/ 64 3 132/ 672 OPEN
&prompt.user; <userinput>l2control -a 00:02:72:00:d4:1a read_connection_list</userinput>
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 does a job
similar to as &man.netstat.1; does, 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>
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</screen>
</sect2>
<indexterm><primary>RFCOMM</primary></indexterm>
<sect2>
<title>RFCOMM Protocol</title>
<para>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.</para>
<para>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).</para>
<para>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.</para>
<para>In &os; the RFCOMM protocol is implemented at the Bluetooth sockets
layer.</para>
</sect2>
<indexterm><primary>pairing</primary></indexterm>
<sect2>
<title>Pairing of Devices</title>
<para>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 <emphasis>PIN codes</emphasis>.
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
<emphasis>link key</emphasis>. 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 <emphasis>pairing</emphasis>. Note that if
the link key is lost by any device then pairing must be repeated.</para>
<para>The &man.hcsecd.8; daemon is responsible for handling of all
Bluetooth authentication requests. The default configuration file is
<filename>/etc/bluetooth/hcsecd.conf</filename>. An example section for
a cellular phone with the PIN code arbitrarily set to
<quote>1234</quote> is shown below.</para>
<programlisting>device {
bdaddr 00:80:37:29:19:a4;
name "Pav's T39";
key nokey;
pin "1234";
}</programlisting>
<para>There is no limitation on PIN codes (except length). Some devices
(for example Bluetooth headsets) may have a fixed PIN code built in.
The <option>-d</option> switch forces the &man.hcsecd.8; 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 <filename>hcsecd.conf</filename>. Now your PC and the remote
device are paired. Alternatively, you can initiate pairing on the remote
device. Below in the sample <command>hcsecd</command> output.</para>
<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</programlisting>
</sect2>
<indexterm><primary>SDP</primary></indexterm>
<sect2>
<title>Service Discovery Protocol (SDP)</title>
<para>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.</para>
<para>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.</para>
<para>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
<emphasis>browsing</emphasis>.</para>
<para>Currently Bluetooth SDP server and client are implemented in a
third-party package <application>sdp-1.5</application> that can be
downloaded from
<ulink url="http://www.geocities.com/m_evmenkin/">here</ulink>. The
<application>sdptool</application> is a command line SDP client.
The following example shows how to perform a SDP browse query.</para>
<screen>&prompt.root; <userinput>sdptool browse 00:80:37:29:19:a4</userinput>
Browsing 00:80:37:29:19:A4 ...
Service Name: Dial-up Networking
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 1
Service Name: Fax
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 2
Service Name: Voice gateway
Service Class ID List:
"Headset Audio Gateway" (0x1112)
"Generic Audio" (0x1203)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 3
</screen>
<para>... 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.</para>
<screen>&prompt.root; <userinput>sdptool search --bdaddr 00:07:e0:00:0b:ca OPUSH</userinput></screen>
<para>Offering services on &os; to Bluetooth clients is done with the
<application>sdpd</application> server.</para>
<screen>&prompt.root; <userinput>sdpd</userinput></screen>
<para>The <application>sdptool</application> is also used to register
a service with the local SDP server. The example below shows how to
register the Network Access with PPP (LAN) service. Note that some
services require attributes (RFCOMM channel for example).</para>
<screen>&prompt.root; <userinput>sdptool add --channel=7 LAN</userinput></screen>
<para>The list of services registered with local SDP server can be
obtained by issuing SDP browse query to a <quote>special</quote>
BD_ADDR.</para>
<screen>&prompt.root; <userinput>sdptool browse ff:ff:ff:00:00:00</userinput></screen>
</sect2>
<sect2>
<title>Dial-Up Networking (DUN) and Network Access with PPP (LAN)
Profiles</title>
<para>The Dial-Up Networking (DUN) profile is mostly used with modems
and cellular phones. The scenarios covered by this profile are the
following:</para>
<itemizedlist>
<listitem><para>use of a cellular phone or modem by a computer as
a wireless modem for connecting to a dial-up internet access server,
or using other dial-up services;</para></listitem>
<listitem><para>use of a cellular phone or modem by a computer to
receive data calls.</para></listitem>
</itemizedlist>
<para>Network Access with PPP (LAN) profile can be used in the following
situations:</para>
<itemizedlist>
<listitem><para>LAN access for a single Bluetooth device;
</para></listitem>
<listitem><para>LAN access for multiple Bluetooth devices;
</para></listitem>
<listitem><para>PC to PC (using PPP networking over serial cable
emulation).</para></listitem>
</itemizedlist>
<para>In &os; both profiles are implemented with &man.ppp.8; and
&man.rfcomm.pppd.8; - a wrapper that converts RFCOMM Bluetooth
connection into something PPP can operate with. Before any profile
can be used, a new PPP label in <filename>/etc/ppp/ppp.conf</filename>
must be created. Consult &man.rfcomm.pppd.8; manual page for examples.
</para>
<para>In the following example &man.rfcomm.pppd.8; will be used to open
RFCOMM connection to remote device with BD_ADDR 00:80:37:29:19:a4 on
DUN RFCOMM channel. The actual RFCOMM channel number will be obtained
from the remote device via SDP. It is possible to specify RFCOMM channel
by hand, and in this case &man.rfcomm.pppd.8; will not perform SDP
query. Use <application>sdptool</application> to find out RFCOMM
channel on the remote device.</para>
<screen>&prompt.root; <userinput>rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup</userinput></screen>
<para>In order to provide Network Access with PPP (LAN) service
<application>sdpd</application> server must be running. It is also
required to register LAN service with the local SDP server. Note that
LAN service requires RFCOMM channel attribute. A new entry for LAN
clients must be created in <filename>/etc/ppp/ppp.conf</filename> file.
Consult &man.rfcomm.pppd.8; manual page for examples. Finally, RFCOMM
PPP server must be running and listening on the same RFCOMM channel
as registered with the local SDP server. The example below shows how
to start RFCOMM PPP server.</para>
<screen>&prompt.root; <userinput>rfcomm_pppd -s -C 7 -l rfcomm-server</userinput></screen>
</sect2>
<indexterm><primary>OBEX</primary></indexterm>
<sect2>
<title>OBEX Push (OPUSH) Profile</title>
<para>OBEX is a widely used protocol for simple file transfers between
mobile devices. It's main use is in infrared communication, where it is
used for generic file transfers between notebooks or Palm handhelds,
and for sending business cards or calendar entries between cellular
phones and other devices with PIM applications.</para>
<para>The OBEX server and client are implemented as a third-party package
<application>obexapp-1.0</application> that can be downloaded from
<ulink url="http://www.geocities.com/m_evmenkin/">here</ulink>.
The package requires the <application>openobex</application> library
(included) and the <filename role="package">devel/glib12</filename>
port. Note that <application>obexapp</application> does not require
root privileges to operate.</para>
<para>OBEX client is used to push and/or pull objects from the OBEX server.
An object can, for example, be a business card or an appointment.
The OBEX client can obtain RFCOMM channel number from the remote device
via SDP. This can be done by specifying service name instead of RFCOMM
channel number. Supported service names are: IrMC, FTRN and OPUSH.
It is possible to specify RFCOMM channel as a number. Below is an
example of an OBEX session, where device information object is pulled
from the cellular phone, and a new object (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>
obex&gt; get
get: remote file&gt; telecom/devinfo.txt
get: local file&gt; devinfo-t39.txt
Success, response: OK, Success (0x20)
obex&gt; put
put: local file&gt; new.vcf
put: remote file&gt; new.vcf
Success, response: OK, Success (0x20)
obex&gt; di
Success, response: OK, Success (0x20)</screen>
<para>In order to provide OBEX Push service,
<application>sdpd</application> server must be running. It is also
required to register OPUSH service with the local SDP server. Note that
OPUSH service requires RFCOMM channel attribute. 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,
OBEX server must be running and listening on the same RFCOMM channel
as registered with the local SDP server. The example below shows how
to start OBEX server.</para>
<screen>&prompt.root; <userinput>obexapp -s -C 10</userinput></screen>
</sect2>
<sect2>
<title>Serial Port (SP) Profile</title>
<para>The Serial Port (SP) profile allows Bluetooth device to perform
RS232 (or similar) serial cable emulation. The scenario covered by this
profile deals with legacy applications using Bluetooth as a cable
replacement, through a virtual serial port abstraction.</para>
<para>The &man.rfcomm.sppd.1; utility implements the Serial Port profile.
Pseudo tty is used as a virtual serial port abstraction. The example
below shows how to connect to a remote device Serial Port service.
Note that you do not have to specify RFCOMM channel -
&man.rfcomm.sppd.1; can obtain it from the remote device via SDP.
If you would like to override this, specify RFCOMM channel in the
command line.</para>
<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 pseudo tty can be used as serial port.</para>
<screen>&prompt.root; <userinput>cu -l ttyp6</userinput></screen>
</sect2>
<sect2>
<title>Troubleshooting</title>
<sect3>
<title>A remote device cannot connect</title>
<para>Some older Bluetooth devices do not support role switching.
By default, when &os; is accepting a new connection, it tries to
perform role switch and become a master. Devices, which do not
support this will not be able to connect. Note the role switching is
performed when a new connection is being established, so it is not
possible to ask the remote device if it does support role switching.
There is a HCI option to disable role switching on the local
side.</para>
<screen>&prompt.root; <userinput>hccontrol -n ubt0hci write_node_role_switch 0</userinput></screen>
</sect3>
<sect3>
<title>Something is going wrong, can I see what exactly is happening?</title>
<para>Yes, you can. Use the <application>hcidump-1.5</application>
third-party package that can be downloaded from
from <ulink url="http://www.geocities.com/m_evmenkin/">here</ulink>.
The <application>hcidump</application> utility is similar to
&man.tcpdump.1;. It can used to display the content of the Bluetooth
packets on the terminal and to dump the Bluetooth packets to a
file.</para>
</sect3>
</sect2>
</sect1>
<sect1 id="network-bridging">
<sect1info>
@ -6762,6 +7332,7 @@ gif0: flags=8010&lt;POINTOPOINT,MULTICAST&gt; mtu 1280
support AAAA records.</para>
</sect2>
</sect1>
</chapter>
<!--

1
share/sgml/man-refs.ent
View file

@ -3468,6 +3468,7 @@
<!ENTITY man.uaudio.4 "<citerefentry/<refentrytitle/uaudio/<manvolnum/4//">
<!ENTITY man.ubsa.4 "<citerefentry/<refentrytitle/ubsa/<manvolnum/4//">
<!ENTITY man.ubsec.4 "<citerefentry/<refentrytitle/ubsec/<manvolnum/4//">
<!ENTITY man.ubtbcmfw.4 "<citerefentry/<refentrytitle/ubtbcmfw/<manvolnum/4//">
<!ENTITY man.ucom.4 "<citerefentry/<refentrytitle/ucom/<manvolnum/4//">
<!ENTITY man.udbp.4 "<citerefentry/<refentrytitle/udbp/<manvolnum/4//">
<!ENTITY man.udp.4 "<citerefentry/<refentrytitle/udp/<manvolnum/4//">