The translation is temporarily closed for contributions due to maintenance, please come back later.

Source string Read only

(itstool) path: sect2/para
Context English State
<prompt>#</prompt> <userinput>hccontrol -n ubt0hci disconnect 41</userinput>
Connection handle: 41
Reason: Connection terminated by local host [0x16]
Type <command>hccontrol help</command> for a complete listing of available <acronym>HCI</acronym> commands. Most of the <acronym>HCI</acronym> commands do not require superuser privileges.
Device Pairing
By default, Bluetooth communication is not authenticated, and any device can talk to any other device. A Bluetooth device, such as a cellular phone, may choose to require authentication to provide a particular service. Bluetooth authentication is normally done with a <emphasis><acronym>PIN</acronym> code</emphasis>, an ASCII string up to 16 characters in length. The user is required to enter the same <acronym>PIN</acronym> code on both devices. Once the user has entered the <acronym>PIN</acronym> code, both devices will generate a <emphasis>link key</emphasis>. After that, the link key can be stored either in the devices or in a persistent storage. Next time, both devices will use the previously generated link key. This procedure is called <emphasis>pairing</emphasis>. Note that if the link key is lost by either device, the pairing must be repeated.
The <citerefentry><refentrytitle>hcsecd</refentrytitle><manvolnum>8</manvolnum></citerefentry> daemon is responsible for handling 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:
device {
bdaddr 00:80:37:29:19:a4;
name "Pav's T39";
key nokey;
pin "1234";
The only limitation on <acronym>PIN</acronym> codes is length. Some devices, such as Bluetooth headsets, may have a fixed <acronym>PIN</acronym> code built in. The <option>-d</option> switch forces <citerefentry><refentrytitle>hcsecd</refentrytitle><manvolnum>8</manvolnum></citerefentry> 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 indicate that pairing was accepted and request the <acronym>PIN</acronym> code. Enter the same <acronym>PIN</acronym> code listed in <filename>hcsecd.conf</filename>. Now the computer and the remote device are paired. Alternatively, pairing can be initiated on the remote device.
The following line can be added to <filename>/etc/rc.conf</filename> to configure <citerefentry><refentrytitle>hcsecd</refentrytitle><manvolnum>8</manvolnum></citerefentry> to start automatically on system start:
The following is a sample of the <citerefentry><refentrytitle>hcsecd</refentrytitle><manvolnum>8</manvolnum></citerefentry> daemon output:
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
Network Access with <acronym>PPP</acronym> Profiles
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.
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.
In FreeBSD, these profiles are implemented with <citerefentry><refentrytitle>ppp</refentrytitle><manvolnum>8</manvolnum></citerefentry> and the <citerefentry><refentrytitle>rfcomm_pppd</refentrytitle><manvolnum>8</manvolnum></citerefentry> wrapper which converts a Bluetooth connection into something <acronym>PPP</acronym> can use. Before a profile can be used, a new <acronym>PPP</acronym> label must be created in <filename>/etc/ppp/ppp.conf</filename>. Consult <citerefentry><refentrytitle>rfcomm_pppd</refentrytitle><manvolnum>8</manvolnum></citerefentry> for examples.
In this example, <citerefentry><refentrytitle>rfcomm_pppd</refentrytitle><manvolnum>8</manvolnum></citerefentry> 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:
<prompt>#</prompt> <userinput>rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup</userinput>
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 <citerefentry><refentrytitle>rfcomm_pppd</refentrytitle><manvolnum>8</manvolnum></citerefentry> will not perform the <acronym>SDP</acronym> query. Use <citerefentry><refentrytitle>sdpcontrol</refentrytitle><manvolnum>8</manvolnum></citerefentry> to find out the <acronym>RFCOMM</acronym> channel on the remote device.
In order to provide network access with the <acronym>PPP</acronym> <acronym>LAN</acronym> service, <citerefentry><refentrytitle>sdpd</refentrytitle><manvolnum>8</manvolnum></citerefentry> must be running and a new entry for <acronym>LAN</acronym> clients must be created in <filename>/etc/ppp/ppp.conf</filename>. Consult <citerefentry><refentrytitle>rfcomm_pppd</refentrytitle><manvolnum>8</manvolnum></citerefentry> for examples. Finally, start the <acronym>RFCOMM</acronym> <acronym>PPP</acronym> server on a valid <acronym>RFCOMM</acronym> channel number. The <acronym>RFCOMM</acronym> <acronym>PPP</acronym> server will automatically register the Bluetooth <acronym>LAN</acronym> service with the local <acronym>SDP</acronym> daemon. The example below shows how to start the <acronym>RFCOMM</acronym> <acronym>PPP</acronym> server.
<prompt>#</prompt> <userinput>rfcomm_pppd -s -C 7 -l rfcomm-server</userinput>
Bluetooth Protocols
This section provides an overview of the various Bluetooth protocols, their function, and associated utilities.
Logical Link Control and Adaptation Protocol (<acronym>L2CAP</acronym>)
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.
<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.
In FreeBSD, 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 <citerefentry><refentrytitle>ng_l2cap</refentrytitle><manvolnum>4</manvolnum></citerefentry>.
A useful command is <citerefentry><refentrytitle>l2ping</refentrytitle><manvolnum>8</manvolnum></citerefentry>, 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.
<prompt>#</prompt> <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
The <citerefentry><refentrytitle>l2control</refentrytitle><manvolnum>8</manvolnum></citerefentry> 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:
<prompt>%</prompt> <userinput>l2control -a 00:02:72:00:d4:1a read_channel_list</userinput>
L2CAP channels:
00:07:e0:00:0b:ca 66/ 64 3 132/ 672 OPEN
<prompt>%</prompt> <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


No matching activity found.

Browse all component changes

Things to check

Multiple failing checks

Following checks are failing:
XML markup: Chinese (Simplified) (zh_CN), Turkish (tr_TR)
Has been translated: Turkish (tr_TR)


Source information

Source string comment
(itstool) path: sect2/para
Source string location
String age
a year ago
Source string age
a year ago
Translation file
books/handbook.pot, string 10898