Source string Read only

(itstool) path: sect3/para
296/2960
Context English State
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>)
<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>.

Loading…

No matching activity found.

Browse all component changes

Glossary

English English
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect3/para
Flags
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 10910