Source string Read only

(itstool) path: sect3/screen
415/4150
Context English State
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>)
<primary>L2CAP</primary>
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:
Remote BD_ADDR SCID/ DCID PSM IMTU/ OMTU State
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.
For the purposes of <acronym>RFCOMM</acronym>, a complete communication path involves two applications running on the communication endpoints with a communication segment between them. <acronym>RFCOMM</acronym> is intended to cover applications that make use of the serial ports of the devices in which they reside. The communication segment is a direct connect Bluetooth link from one device to another.
<acronym>RFCOMM</acronym> 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. <acronym>RFCOMM</acronym> 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.
In FreeBSD, <acronym>RFCOMM</acronym> is implemented at the Bluetooth sockets layer.
Service Discovery Protocol (<acronym>SDP</acronym>)
<primary>SDP</primary>
The Service Discovery Protocol (<acronym>SDP</acronym>) 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.
<acronym>SDP</acronym> involves communication between a <acronym>SDP</acronym> server and a <acronym>SDP</acronym> 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 <acronym>SDP</acronym> server by issuing a <acronym>SDP</acronym> 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. <acronym>SDP</acronym> provides a mechanism for discovering services and their attributes, but it does not provide a mechanism for utilizing those services.
Normally, a <acronym>SDP</acronym> 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 <acronym>SDP</acronym> server's service records without any prior information about the services. This process of looking for any offered services is called <emphasis>browsing</emphasis>.
The Bluetooth <acronym>SDP</acronym> server, <citerefentry><refentrytitle>sdpd</refentrytitle><manvolnum>8</manvolnum></citerefentry>, and command line client, <citerefentry><refentrytitle>sdpcontrol</refentrytitle><manvolnum>8</manvolnum></citerefentry>, are included in the standard FreeBSD installation. The following example shows how to perform a <acronym>SDP</acronym> browse query.
<prompt>%</prompt> <userinput>sdpcontrol -a 00:01:03:fc:6e:ec browse</userinput>
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
Note that each service has a list of attributes, such as the <acronym>RFCOMM</acronym> channel. Depending on the service, the user might need to make 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 <acronym>OBEX</acronym> Object Push (<acronym>OPUSH</acronym>) service:

Loading…

No matching activity found.

Browse all component changes

Things to check

Multiple failing checks

The translations in several languages have failing checks

Reset

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect3/screen
Flags
no-wrap, read-only
Source string location
book.translate.xml:65535
String age
a year ago
Source string age
a year ago
Translation file
books/handbook.pot, string 10913