Date: Thu, 6 Mar 2014 19:16:24 +0000 (UTC) From: Dru Lavigne <dru@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44158 - head/en_US.ISO8859-1/books/handbook/advanced-networking Message-ID: <201403061916.s26JGOir057100@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: dru Date: Thu Mar 6 19:16:24 2014 New Revision: 44158 URL: http://svnweb.freebsd.org/changeset/doc/44158 Log: White space fix only. Translators can ignore. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml Thu Mar 6 18:47:05 2014 (r44157) +++ head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml Thu Mar 6 19:16:24 2014 (r44158) @@ -2216,19 +2216,18 @@ freebsdap 00:11:95:c3:0d:ac 1 <primary>Bluetooth</primary> </indexterm> - <para>Bluetooth is a wireless technology for creating personal - networks operating in the 2.4 GHz unlicensed band, with a - range of 10 meters. Networks are usually formed ad-hoc from - portable devices such as cellular phones, handhelds, and - laptops. Unlike Wi-Fi wireless technology, Bluetooth offers - higher level service profiles, such as <acronym>FTP</acronym>-like file servers, - file pushing, voice transport, serial line emulation, and - more.</para> - - <para>This section describes the use of a - <acronym>USB</acronym> Bluetooth dongle on a &os; system. It - then describes the various Bluetooth protocols and - utilities.</para> + <para>Bluetooth is a wireless technology for creating personal + networks operating in the 2.4 GHz unlicensed band, with a + range of 10 meters. Networks are usually formed ad-hoc from + portable devices such as cellular phones, handhelds, and + laptops. Unlike Wi-Fi wireless technology, Bluetooth offers + higher level service profiles, such as + <acronym>FTP</acronym>-like file servers, file pushing, voice + transport, serial line emulation, and more.</para> + + <para>This section describes the use of a <acronym>USB</acronym> + Bluetooth dongle on a &os; system. It then describes the + various Bluetooth protocols and utilities.</para> <sect2> <title>Loading Bluetooth Support</title> @@ -2236,28 +2235,30 @@ freebsdap 00:11:95:c3:0d:ac 1 <para>The Bluetooth stack in &os; is implemented using the &man.netgraph.4; framework. A broad variety of Bluetooth <acronym>USB</acronym> dongles is supported by &man.ng.ubt.4;. - Broadcom BCM2033 based Bluetooth devices are supported by - the &man.ubtbcmfw.4; and &man.ng.ubt.4; drivers. The 3Com + Broadcom BCM2033 based Bluetooth devices are supported by the + &man.ubtbcmfw.4; and &man.ng.ubt.4; drivers. The 3Com Bluetooth PC Card 3CRWB60-A is supported by the &man.ng.bt3c.4; driver. Serial and UART based Bluetooth devices are supported by &man.sio.4;, &man.ng.h4.4;, and &man.hcseriald.8;.</para> - + <para>Before attaching a device, determine which of the above drivers it uses, then load the driver. For example, if the device uses the &man.ng.ubt.4; driver:</para> <screen>&prompt.root; <userinput>kldload ng_ubt</userinput></screen> - <para>If the Bluetooth device will be attached to the system during - system startup, the system can be configured to load the module at boot - time by adding the driver to + <para>If the Bluetooth device will be attached to the system + during system startup, the system can be configured to load + the module at boot time by adding the driver to <filename>/boot/loader.conf</filename>:</para> <programlisting>ng_ubt_load="YES"</programlisting> - <para>Once the driver is loaded, plug in the <acronym>USB</acronym> dongle. If the driver load was successful, output - similar to the following should appear on the console and in + <para>Once the driver is loaded, plug in the + <acronym>USB</acronym> dongle. If the driver load was + successful, output similar to the following should appear on + the console and in <filename>/var/log/messages</filename>:</para> <screen>ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2 @@ -2266,9 +2267,9 @@ ubt0: Interface 1 (alt.config 5) endpoin wMaxPacketSize=49, nframes=6, buffer size=294</screen> <para>To start and stop the Bluetooth stack, use its startup - script. It is a good idea to stop the stack before - unplugging the device. When starting the stack, the output - should be similar to the following:</para> + script. It is a good idea to stop the stack before unplugging + the device. When starting the stack, the output should be + similar to the following:</para> <screen>&prompt.root; <userinput>service bluetooth start ubt0</userinput> BD_ADDR: 00:02:72:00:d4:1a @@ -2292,16 +2293,15 @@ Number of SCO packets: 8</screen> </indexterm> <para>The Host Controller Interface (<acronym>HCI</acronym>) - provides a uniform method for - accessing Bluetooth baseband capabilities. In &os;, a - netgraph <acronym>HCI</acronym> node - is created for each Bluetooth device. For more details, refer to - &man.ng.hci.4;.</para> + provides a uniform method for accessing Bluetooth baseband + capabilities. In &os;, a netgraph <acronym>HCI</acronym> node + is created for each Bluetooth device. For more details, refer + to &man.ng.hci.4;.</para> <para>One of the most common tasks is discovery of Bluetooth - devices within <acronym>RF</acronym> proximity. This operation is - called <emphasis>inquiry</emphasis>. Inquiry and other - <acronym>HCI</acronym> related operations are done using + devices within <acronym>RF</acronym> proximity. This + operation is called <emphasis>inquiry</emphasis>. Inquiry and + other <acronym>HCI</acronym> related operations are done using &man.hccontrol.8;. The example below shows how to find out which Bluetooth devices are in range. The list of devices should be displayed in a few seconds. Note that a remote @@ -2321,13 +2321,13 @@ Inquiry complete. Status: No error [00]< <para>The <literal>BD_ADDR</literal> is the unique address of a Bluetooth device, similar to the <acronym>MAC</acronym> - address of a network card. This address is needed for - further communication with a device and it is possible to - assign a human readable name to a BD_ADDR. Information - regarding the known Bluetooth hosts is contained in + address of a network card. This address is needed for further + communication with a device and it is possible to assign a + human readable name to a BD_ADDR. Information regarding the + known Bluetooth hosts is contained in <filename>/etc/bluetooth/hosts</filename>. The following - example shows how to obtain the human readable name that - was assigned to the remote device:</para> + example shows how to obtain the human readable name that was + assigned to the remote device:</para> <screen>&prompt.user; <userinput>hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4</userinput> BD_ADDR: 00:80:37:29:19:a4 @@ -2388,8 +2388,8 @@ Reason: Connection terminated by local h 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:</para> + <acronym>PIN</acronym> code set to <literal>1234</literal> is + shown below:</para> <programlisting>device { bdaddr 00:80:37:29:19:a4; @@ -2434,16 +2434,17 @@ hcsecd[16484]: Sending PIN_Code_Reply to <acronym>PPP</acronym> Profiles</title> <para>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.</para> + 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.</para> <para>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.</para> + 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.</para> <para>In &os;, these profiles are implemented with &man.ppp.8; and the &man.rfcomm.pppd.8; wrapper which converts a @@ -2453,20 +2454,22 @@ hcsecd[16484]: Sending PIN_Code_Reply to <filename>/etc/ppp/ppp.conf</filename>. Consult &man.rfcomm.pppd.8; for examples.</para> - <para>In this example, &man.rfcomm.pppd.8; 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:</para> + <para>In this example, &man.rfcomm.pppd.8; 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:</para> <screen>&prompt.root; <userinput>rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup</userinput></screen> - <para>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 &man.rfcomm.pppd.8; will - not perform the <acronym>SDP</acronym> query. Use - &man.sdpcontrol.8; to find out the <acronym>RFCOMM</acronym> - channel on the remote device.</para> + <para>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 &man.rfcomm.pppd.8; will not perform + the <acronym>SDP</acronym> query. Use &man.sdpcontrol.8; to + find out the <acronym>RFCOMM</acronym> channel on the remote + device.</para> <para>In order to provide network access with the <acronym>PPP</acronym> <acronym>LAN</acronym> service, @@ -2487,62 +2490,63 @@ hcsecd[16484]: Sending PIN_Code_Reply to <sect2> <title>Bluetooth Protocols</title> - - <para>This section provides an overview of the various Bluetooth protocols, - their function, and associated utilities.</para> - - <sect3> - <title>Logical Link Control and Adaptation Protocol - (<acronym>L2CAP</acronym>)</title> - <indexterm> - <primary>L2CAP</primary> - </indexterm> + <para>This section provides an overview of the various Bluetooth + protocols, their function, and associated utilities.</para> + + <sect3> + <title>Logical Link Control and Adaptation Protocol + (<acronym>L2CAP</acronym>)</title> + + <indexterm> + <primary>L2CAP</primary> + </indexterm> - <para>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.</para> - - <para><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.</para> - - <para>In &os;, 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 &man.ng.l2cap.4;.</para> - - <para>A useful command is &man.l2ping.8;, 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.</para> + <para>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.</para> + + <para><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.</para> + + <para>In &os;, 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 + &man.ng.l2cap.4;.</para> + + <para>A useful command is &man.l2ping.8;, 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.</para> - <screen>&prompt.root; <userinput>l2ping -a 00:80:37:29:19:a4</userinput> + <screen>&prompt.root; <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</screen> - <para>The &man.l2control.8; 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:</para> + <para>The &man.l2control.8; 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:</para> - <screen>&prompt.user; <userinput>l2control -a 00:02:72:00:d4:1a read_channel_list</userinput> + <screen>&prompt.user; <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 @@ -2551,12 +2555,13 @@ L2CAP connections: Remote BD_ADDR Handle Flags Pending State 00:07:e0:00:0b:ca 41 O 0 OPEN</screen> - <para>Another diagnostic tool is &man.btsockstat.1;. It is - similar to &man.netstat.1;, but for Bluetooth network-related - data structures. The example below shows the same logical - connection as &man.l2control.8; above.</para> + <para>Another diagnostic tool is &man.btsockstat.1;. It is + similar to &man.netstat.1;, but for Bluetooth + network-related data structures. The example below shows + the same logical connection as &man.l2control.8; + above.</para> - <screen>&prompt.user; <userinput>btsockstat</userinput> + <screen>&prompt.user; <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 @@ -2566,86 +2571,89 @@ c2afe900 c2b53380 1 127 0 Yes 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</screen> - </sect3> + </sect3> - <sect3> - <title>Radio Frequency Communication (<acronym>RFCOMM</acronym>)</title> + <sect3> + <title>Radio Frequency Communication + (<acronym>RFCOMM</acronym>)</title> - <para>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.</para> - - <para>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.</para> - - <para><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.</para> - - <para>In &os;, <acronym>RFCOMM</acronym> is implemented at the - Bluetooth sockets layer.</para> - </sect3> - - <sect3> - <title>Service Discovery Protocol - (<acronym>SDP</acronym>)</title> + <para>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.</para> + + <para>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.</para> + + <para><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.</para> - <indexterm> - <primary>SDP</primary> - </indexterm> + <para>In &os;, <acronym>RFCOMM</acronym> is implemented at the + Bluetooth sockets layer.</para> + </sect3> - <para>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.</para> - - <para><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.</para> - - <para>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>.</para> - - <para>The Bluetooth <acronym>SDP</acronym> server, &man.sdpd.8;, - and command line client, &man.sdpcontrol.8;, are included in - the standard &os; installation. The following example shows - how to perform a <acronym>SDP</acronym> browse query.</para> + <sect3> + <title>Service Discovery Protocol + (<acronym>SDP</acronym>)</title> - <screen>&prompt.user; <userinput>sdpcontrol -a 00:01:03:fc:6e:ec browse</userinput> + <indexterm> + <primary>SDP</primary> + </indexterm> + + <para>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.</para> + + <para><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.</para> + + <para>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>.</para> + + <para>The Bluetooth <acronym>SDP</acronym> server, + &man.sdpd.8;, and command line client, &man.sdpcontrol.8;, + are included in the standard &os; installation. The + following example shows how to perform a + <acronym>SDP</acronym> browse query.</para> + + <screen>&prompt.user; <userinput>sdpcontrol -a 00:01:03:fc:6e:ec browse</userinput> Record Handle: 00000000 Service Class ID List: Service Discovery Server (0x1000) @@ -2668,83 +2676,82 @@ Protocol Descriptor List: Bluetooth Profile Descriptor List: LAN Access Using PPP (0x1102) ver. 1.0</screen> - <para>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:</para> - - <screen>&prompt.user; <userinput>sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH</userinput></screen> - - <para>Offering services on &os; to Bluetooth clients is done - with the &man.sdpd.8; server. The following line can be added - to <filename>/etc/rc.conf</filename>:</para> - - <programlisting>sdpd_enable="YES"</programlisting> - - <para>Then the &man.sdpd.8; daemon can be - started with:</para> - - <screen>&prompt.root; <userinput>service sdpd start</userinput></screen> - - <para>The local server application that wants to provide a - Bluetooth service to remote clients will register the service - with the local <acronym>SDP</acronym> daemon. An example of - such an application is &man.rfcomm.pppd.8;. Once started, - it will register the Bluetooth LAN service with the local - <acronym>SDP</acronym> daemon.</para> - - <para>The list of services registered with the local - <acronym>SDP</acronym> server can be obtained by issuing a - <acronym>SDP</acronym> browse query via the local control - channel:</para> + <para>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:</para> + + <screen>&prompt.user; <userinput>sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH</userinput></screen> + + <para>Offering services on &os; to Bluetooth clients is done + with the &man.sdpd.8; server. The following line can be + added to <filename>/etc/rc.conf</filename>:</para> + + <programlisting>sdpd_enable="YES"</programlisting> + + <para>Then the &man.sdpd.8; daemon can be started with:</para> + + <screen>&prompt.root; <userinput>service sdpd start</userinput></screen> + + <para>The local server application that wants to provide a + Bluetooth service to remote clients will register the + service with the local <acronym>SDP</acronym> daemon. An + example of such an application is &man.rfcomm.pppd.8;. Once + started, it will register the Bluetooth LAN service with the + local <acronym>SDP</acronym> daemon.</para> + + <para>The list of services registered with the local + <acronym>SDP</acronym> server can be obtained by issuing a + <acronym>SDP</acronym> browse query via the local control + channel:</para> - <screen>&prompt.root; <userinput>sdpcontrol -l browse</userinput></screen> - </sect3> + <screen>&prompt.root; <userinput>sdpcontrol -l browse</userinput></screen> + </sect3> - <sect3> - <title><acronym>OBEX</acronym> Object Push - (<acronym>OPUSH</acronym>)</title> + <sect3> + <title><acronym>OBEX</acronym> Object Push + (<acronym>OPUSH</acronym>)</title> - <indexterm> - <primary>OBEX</primary> - </indexterm> + <indexterm> + <primary>OBEX</primary> + </indexterm> - <para>Object Exchange (<acronym>OBEX</acronym>) is a widely used protocol for - simple file transfers between mobile devices. Its main use - is in infrared communication, where it is used for generic - file transfers between notebooks or <acronym>PDA</acronym>s, - and for sending business cards or calendar entries between - cellular phones and other devices with Personal Information Manager (<acronym>PIM</acronym>) - applications.</para> - - <para>The <acronym>OBEX</acronym> server and client are - implemented by - <application>obexapp</application>, which can be installed using the - <package>comms/obexapp</package> package or - port.</para> - - <para>The <acronym>OBEX</acronym> client is used to push and/or - pull objects from the <acronym>OBEX</acronym> server. An example - object is a business card or an appointment. - The <acronym>OBEX</acronym> client can obtain the - <acronym>RFCOMM</acronym> channel number from the remote - device via <acronym>SDP</acronym>. This can be done by - specifying the service name instead of the - <acronym>RFCOMM</acronym> channel number. Supported service - names are: <literal>IrMC</literal>, <literal>FTRN</literal>, - and <literal>OPUSH</literal>. It is also possible to specify - the <acronym>RFCOMM</acronym> channel as a number. Below is - an example of an <acronym>OBEX</acronym> session where the - device information object is pulled from the cellular phone, - and a new object, the business card, is pushed into the - phone's directory.</para> + <para>Object Exchange (<acronym>OBEX</acronym>) is a widely + used protocol for simple file transfers between mobile + devices. Its main use is in infrared communication, where + it is used for generic file transfers between notebooks or + <acronym>PDA</acronym>s, and for sending business cards or + calendar entries between cellular phones and other devices + with Personal Information Manager (<acronym>PIM</acronym>) + applications.</para> + + <para>The <acronym>OBEX</acronym> server and client are + implemented by <application>obexapp</application>, which can + be installed using the <package>comms/obexapp</package> + package or port.</para> + + <para>The <acronym>OBEX</acronym> client is used to push + and/or pull objects from the <acronym>OBEX</acronym> server. + An example object is a business card or an appointment. + The <acronym>OBEX</acronym> client can obtain the + <acronym>RFCOMM</acronym> channel number from the remote + device via <acronym>SDP</acronym>. This can be done by + specifying the service name instead of the + <acronym>RFCOMM</acronym> channel number. Supported service + names are: <literal>IrMC</literal>, <literal>FTRN</literal>, + and <literal>OPUSH</literal>. It is also possible to + specify the <acronym>RFCOMM</acronym> channel as a number. + Below is an example of an <acronym>OBEX</acronym> session + where the device information object is pulled from the + cellular phone, and a new object, the business card, is + pushed into the phone's directory.</para> - <screen>&prompt.user; <userinput>obexapp -a 00:80:37:29:19:a4 -C IrMC</userinput> + <screen>&prompt.user; <userinput>obexapp -a 00:80:37:29:19:a4 -C IrMC</userinput> obex> get telecom/devinfo.txt devinfo-t39.txt Success, response: OK, Success (0x20) obex> put new.vcf @@ -2752,72 +2759,70 @@ Success, response: OK, Success (0x20) obex> di Success, response: OK, Success (0x20)</screen> - <para>In order to provide the <acronym>OPUSH</acronym> service, - &man.sdpd.8; must be running and a root folder, where all - incoming objects will be stored, must be created. The - default path to the root folder is - <filename>/var/spool/obex</filename>. Finally, start the - <acronym>OBEX</acronym> server on a valid - <acronym>RFCOMM</acronym> channel number. The - <acronym>OBEX</acronym> server will automatically register - the <acronym>OPUSH</acronym> service with the local - <acronym>SDP</acronym> daemon. The example below shows how - to start the <acronym>OBEX</acronym> server.</para> - - <screen>&prompt.root; <userinput>obexapp -s -C 10</userinput></screen> - </sect3> - - <sect3> - <title>Serial Port Profile (<acronym>SPP</acronym>)</title> - - <para>The Serial Port Profile (<acronym>SPP</acronym>) allows - Bluetooth devices to perform serial cable emulation. This - profile allows legacy applications to use Bluetooth as a - cable replacement, through a virtual serial port - abstraction.</para> - - <para>In &os;, &man.rfcomm.sppd.1; implements - <acronym>SPP</acronym> and a pseudo tty is used as a virtual - serial port abstraction. The example below shows how to - connect to a remote device's serial port service. A - <acronym>RFCOMM</acronym> channel does not have to be - specified as &man.rfcomm.sppd.1; can obtain it from the - remote device via <acronym>SDP</acronym>. To override this, - specify a <acronym>RFCOMM</acronym> channel on the command - line.</para> + <para>In order to provide the <acronym>OPUSH</acronym> + service, &man.sdpd.8; must be running and a root folder, + where all incoming objects will be stored, must be created. + The default path to the root folder is + <filename>/var/spool/obex</filename>. Finally, start the + <acronym>OBEX</acronym> server on a valid + <acronym>RFCOMM</acronym> channel number. The + <acronym>OBEX</acronym> server will automatically register + the <acronym>OPUSH</acronym> service with the local + <acronym>SDP</acronym> daemon. The example below shows how + to start the <acronym>OBEX</acronym> server.</para> + + <screen>&prompt.root; <userinput>obexapp -s -C 10</userinput></screen> + </sect3> + + <sect3> + <title>Serial Port Profile (<acronym>SPP</acronym>)</title> + + <para>The Serial Port Profile (<acronym>SPP</acronym>) allows + Bluetooth devices to perform serial cable emulation. This + profile allows legacy applications to use Bluetooth as a + cable replacement, through a virtual serial port + abstraction.</para> + + <para>In &os;, &man.rfcomm.sppd.1; implements + <acronym>SPP</acronym> and a pseudo tty is used as a virtual + serial port abstraction. The example below shows how to + connect to a remote device's serial port service. A + <acronym>RFCOMM</acronym> channel does not have to be + specified as &man.rfcomm.sppd.1; can obtain it from the + remote device via <acronym>SDP</acronym>. To override this, + specify a <acronym>RFCOMM</acronym> channel on the command + line.</para> - <screen>&prompt.root; <userinput>rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6</userinput> + <screen>&prompt.root; <userinput>rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6</userinput> rfcomm_sppd[94692]: Starting on /dev/ttyp6...</screen> - <para>Once connected, the pseudo tty can be used as serial - port:</para> + <para>Once connected, the pseudo tty can be used as serial + port:</para> - <screen>&prompt.root; <userinput>cu -l ttyp6</userinput></screen> - </sect3> - </sect2> + <screen>&prompt.root; <userinput>cu -l ttyp6</userinput></screen> + </sect3> + </sect2> <sect2> <title>Troubleshooting</title> - <para>By default, when &os; is accepting a new - connection, it tries to perform a role switch and become - master. Some older Bluetooth devices which do not support role - switching will not be able - to connect. Since role switching is performed when a - new connection is being established, it is not possible - to ask the remote device if it supports role switching. - However, there is a <acronym>HCI</acronym> option to disable role - switching on the local side:</para> - - <screen>&prompt.root; <userinput>hccontrol -n ubt0hci write_node_role_switch 0</userinput></screen> - - <para>To display Bluetooth packets, use the third-party package - <application>hcidump</application>, which can be installed using the - <package>comms/hcidump</package> package or - port. This utility is similar to &man.tcpdump.1; and can - be used to display the contents of Bluetooth packets on - the terminal and to dump the Bluetooth packets to a - file.</para> + <para>By default, when &os; is accepting a new connection, it + tries to perform a role switch and become master. Some older + Bluetooth devices which do not support role switching will not + be able to connect. Since role switching is performed when a + new connection is being established, it is not possible to ask + the remote device if it supports role switching. However, + there is a <acronym>HCI</acronym> option to disable role + switching on the local side:</para> + + <screen>&prompt.root; <userinput>hccontrol -n ubt0hci write_node_role_switch 0</userinput></screen> + + <para>To display Bluetooth packets, use the third-party package + <application>hcidump</application>, which can be installed + using the <package>comms/hcidump</package> package or port. + This utility is similar to &man.tcpdump.1; and can be used to + display the contents of Bluetooth packets on the terminal and + to dump the Bluetooth packets to a file.</para> </sect2> </sect1>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201403061916.s26JGOir057100>