From owner-svn-doc-all@FreeBSD.ORG Thu Mar 6 18:39:21 2014 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5813DAA9; Thu, 6 Mar 2014 18:39:21 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 38B33A6E; Thu, 6 Mar 2014 18:39:21 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s26IdLcm039810; Thu, 6 Mar 2014 18:39:21 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s26IdLed039809; Thu, 6 Mar 2014 18:39:21 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201403061839.s26IdLed039809@svn.freebsd.org> From: Dru Lavigne Date: Thu, 6 Mar 2014 18:39:21 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44156 - head/en_US.ISO8859-1/books/handbook/advanced-networking X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 18:39:21 -0000 Author: dru Date: Thu Mar 6 18:39:20 2014 New Revision: 44156 URL: http://svnweb.freebsd.org/changeset/doc/44156 Log: Editorial pass through second 1/2 of Bluetooth chapter. Protocols section is still a bit dense. 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:32:15 2014 (r44155) +++ head/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.xml Thu Mar 6 18:39:20 2014 (r44156) @@ -2488,8 +2488,8 @@ hcsecd[16484]: Sending PIN_Code_Reply to Bluetooth Protocols - This section describes the various Bluetooth utilities, - their function, and available utilities. + This section provides an overview of the various Bluetooth protocols, + their function, and associated utilities. Logical Link Control and Adaptation Protocol @@ -2501,16 +2501,15 @@ hcsecd[16484]: Sending PIN_Code_Reply to <para>The Logical Link Control and Adaptation Protocol (<acronym>L2CAP</acronym>) provides connection-oriented and - connectionless data services to upper layer protocols with - protocol multiplexing capability and segmentation and - reassembly operation. <acronym>L2CAP</acronym> permits + 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. Each channel is + 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 @@ -2518,9 +2517,9 @@ hcsecd[16484]: Sending PIN_Code_Reply to directed to the appropriate higher level protocol. Multiple channels can share the same baseband connection.</para> - <para>A single netgraph node of type <emphasis>l2cap</emphasis> - is created for a single Bluetooth device. The - <acronym>L2CAP</acronym> node is normally connected to the + <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>. @@ -2574,10 +2573,9 @@ c2e8bc80 0 250 00:02:72:00:d4:1a <para>The <acronym>RFCOMM</acronym> protocol provides emulation of serial ports over the <acronym>L2CAP</acronym> protocol. - The protocol is based on the ETSI standard TS 07.10. <acronym>RFCOMM</acronym> is a simple transport protocol, with additional provisions for emulating the 9 circuits of - RS-232 (EIATIA-232-E) serial ports. <acronym>RFCOMM</acronym> + RS-232 (EIATIA-232-E) serial ports. It supports up to 60 simultaneous connections (<acronym>RFCOMM</acronym> channels) between two Bluetooth devices.</para> @@ -2693,8 +2691,8 @@ Bluetooth Profile Descriptor List: <screen>&prompt.root; <userinput>service sdpd start</userinput></screen> - <para>The local server application that wants to provide - Bluetooth service to the remote clients will register service + <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 @@ -2710,36 +2708,36 @@ Bluetooth Profile Descriptor List: <sect3> <title><acronym>OBEX</acronym> Object Push - (<acronym>OPUSH</acronym>) Profile + (OPUSH) OBEX - OBEX is a widely used protocol for + Object Exchange (OBEX) 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 PDAs, and for sending business cards or calendar entries between - cellular phones and other devices with PIM + cellular phones and other devices with Personal Information Manager (PIM) applications. The OBEX server and client are - implemented as a third-party package, - obexapp, which is available as + implemented by + obexapp, which can be installed using the comms/obexapp package or port. The OBEX client is used to push and/or - pull objects from the OBEX server. An - object can, for example, be a business card or an appointment. + pull objects from the OBEX server. An example + object is a business card or an appointment. The OBEX client can obtain the RFCOMM channel number from the remote device via SDP. This can be done by specifying the service name instead of the RFCOMM channel number. Supported service - names are: IrMC, FTRN, - and OPUSH. It is also possible to specify + names are: IrMC, FTRN, + and OPUSH. It is also possible to specify the RFCOMM channel as a number. Below is an example of an OBEX session where the device information object is pulled from the cellular phone, @@ -2781,7 +2779,7 @@ Success, response: OK, Success (0x20)In &os;, &man.rfcomm.sppd.1; implements SPP and a pseudo tty is used as a virtual serial port abstraction. The example below shows how to - connect to a remote device serial port service. A + connect to a remote device's serial port service. A RFCOMM channel does not have to be specified as &man.rfcomm.sppd.1; can obtain it from the remote device via SDP. To override this, @@ -2801,20 +2799,20 @@ rfcomm_sppd[94692]: Starting on /dev/tty Troubleshooting - Some older Bluetooth devices do not support role - switching. By default, when &os; is accepting a new + By default, when &os; is accepting a new connection, it tries to perform a role switch and become - master. Devices, which do not support this will not be able + 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. - There is a HCI option to disable role + However, there is a HCI option to disable role switching on the local side: &prompt.root; hccontrol -n ubt0hci write_node_role_switch 0 To display Bluetooth packets, use the third-party package - hcidump, which is available as a + hcidump, which can be installed using the comms/hcidump package or port. This utility is similar to &man.tcpdump.1; and can be used to display the contents of Bluetooth packets on