Source string Read only

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

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 10909