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

Source string Read only

(itstool) path: sect2/screen
Context English State
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
Another diagnostic tool is <citerefentry><refentrytitle>btsockstat</refentrytitle><manvolnum>1</manvolnum></citerefentry>. It is similar to <citerefentry><refentrytitle>netstat</refentrytitle><manvolnum>1</manvolnum></citerefentry>, but for Bluetooth network-related data structures. The example below shows the same logical connection as <citerefentry><refentrytitle>l2control</refentrytitle><manvolnum>8</manvolnum></citerefentry> above.
<prompt>%</prompt> <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
Radio Frequency Communication (<acronym>RFCOMM</acronym>)
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.


No matching activity found.

Browse all component changes

Things to check

Multiple failing checks

Following checks are failing:
Unchanged translation: Chinese (Simplified) (zh_CN), Turkish (tr_TR), Portuguese (Brazil)


Source information

Source string comment
(itstool) path: sect2/screen
no-wrap, read-only
Source string location
String age
a year ago
Source string age
a year ago
Translation file
books/handbook.pot, string 10902