From owner-svn-doc-all@FreeBSD.ORG Thu Mar 6 19:16:24 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 A13D9DB4; Thu, 6 Mar 2014 19:16:24 +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 8C496DE9; Thu, 6 Mar 2014 19:16:24 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.8/8.14.8) with ESMTP id s26JGOmF057101; Thu, 6 Mar 2014 19:16:24 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.8/8.14.8/Submit) id s26JGOir057100; Thu, 6 Mar 2014 19:16:24 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201403061916.s26JGOir057100@svn.freebsd.org> From: Dru Lavigne Date: Thu, 6 Mar 2014 19:16:24 +0000 (UTC) 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 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 19:16:24 -0000 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 Bluetooth - 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 FTP-like file servers, - file pushing, voice transport, serial line emulation, and - more. - - This section describes the use of a - USB Bluetooth dongle on a &os; system. It - then describes the various Bluetooth protocols and - utilities. + 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 + FTP-like file servers, file pushing, voice + transport, serial line emulation, and more. + + This section describes the use of a USB + Bluetooth dongle on a &os; system. It then describes the + various Bluetooth protocols and utilities. Loading Bluetooth Support @@ -2236,28 +2235,30 @@ freebsdap 00:11:95:c3:0d:ac 1 The Bluetooth stack in &os; is implemented using the &man.netgraph.4; framework. A broad variety of Bluetooth USB 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;. - + 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: &prompt.root; kldload ng_ubt - 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 + 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 /boot/loader.conf: ng_ubt_load="YES" - Once the driver is loaded, plug in the USB dongle. If the driver load was successful, output - similar to the following should appear on the console and in + Once the driver is loaded, plug in the + USB dongle. If the driver load was + successful, output similar to the following should appear on + the console and in /var/log/messages: 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 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: + 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: &prompt.root; service bluetooth start ubt0 BD_ADDR: 00:02:72:00:d4:1a @@ -2292,16 +2293,15 @@ Number of SCO packets: 8 The Host Controller Interface (HCI) - provides a uniform method for - accessing Bluetooth baseband capabilities. In &os;, a - netgraph HCI node - is created for each Bluetooth device. For more details, refer to - &man.ng.hci.4;. + provides a uniform method for accessing Bluetooth baseband + capabilities. In &os;, a netgraph HCI node + is created for each Bluetooth device. For more details, refer + to &man.ng.hci.4;. One of the most common tasks is discovery of Bluetooth - devices within RF proximity. This operation is - called inquiry. Inquiry and other - HCI related operations are done using + devices within RF proximity. This + operation is called inquiry. Inquiry and + other HCI 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]< The BD_ADDR is the unique address of a Bluetooth device, similar to the MAC - 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 /etc/bluetooth/hosts. The following - example shows how to obtain the human readable name that - was assigned to the remote device: + example shows how to obtain the human readable name that was + assigned to the remote device: &prompt.user; hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4 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 /etc/bluetooth/hcsecd.conf. An example section for a cellular phone with the - PIN code set to - 1234 is shown below: + PIN code set to 1234 is + shown below: device { bdaddr 00:80:37:29:19:a4; @@ -2434,16 +2434,17 @@ hcsecd[16484]: Sending PIN_Code_Reply to PPP Profiles A Dial-Up Networking (DUN) 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. + 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 PPP profile can - be used to provide LAN access for a single Bluetooth - device or multiple Bluetooth devices. It can also provide - PC to PC connection using PPP - networking over serial cable emulation. + be used to provide LAN access for a single + Bluetooth device or multiple Bluetooth devices. It can also + provide PC to PC + connection using PPP networking over serial + cable emulation. 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 /etc/ppp/ppp.conf. Consult &man.rfcomm.pppd.8; for examples. - In this example, &man.rfcomm.pppd.8; is used - to open a connection to a remote - device with a BD_ADDR of 00:80:37:29:19:a4 - on a DUN RFCOMM channel: + In this example, &man.rfcomm.pppd.8; is used to open a + connection to a remote device with a + BD_ADDR of + 00:80:37:29:19:a4 on a + DUN RFCOMM + channel: &prompt.root; rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup - The actual channel number will be - obtained from the remote device using the SDP protocol. - It is possible to specify the RFCOMM - channel by hand, and in this case &man.rfcomm.pppd.8; will - not perform the SDP query. Use - &man.sdpcontrol.8; to find out the RFCOMM - channel on the remote device. + The actual channel number will be obtained from the remote + device using the SDP protocol. It is + possible to specify the RFCOMM channel by + hand, and in this case &man.rfcomm.pppd.8; will not perform + the SDP query. Use &man.sdpcontrol.8; to + find out the RFCOMM channel on the remote + device. In order to provide network access with the PPP LAN service, @@ -2487,62 +2490,63 @@ hcsecd[16484]: Sending PIN_Code_Reply to 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>) - - L2CAP - + This section provides an overview of the various Bluetooth + protocols, their function, and associated utilities. + + + Logical Link Control and Adaptation Protocol + (<acronym>L2CAP</acronym>) + + + L2CAP + - The Logical Link Control and Adaptation Protocol - (L2CAP) provides connection-oriented and - connectionless data services to upper layer protocols. - L2CAP permits - higher level protocols and applications to transmit and - receive L2CAP data packets up to 64 - kilobytes in length. - - L2CAP is based around the concept of - channels. 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 - L2CAP packet received on a channel is - directed to the appropriate higher level protocol. Multiple - channels can share the same baseband connection. - - In &os;, a netgraph L2CAP node - is created for each Bluetooth device. This - node is normally connected to the - downstream Bluetooth HCI node and upstream - Bluetooth socket nodes. The default name for the - L2CAP node is devicel2cap. - For more details refer to &man.ng.l2cap.4;. - - 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 0 - bytes in the following example is normal. + The Logical Link Control and Adaptation Protocol + (L2CAP) provides connection-oriented and + connectionless data services to upper layer protocols. + L2CAP permits higher level protocols and + applications to transmit and receive + L2CAP data packets up to 64 kilobytes in + length. + + L2CAP is based around the concept of + channels. 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 L2CAP packet received on + a channel is directed to the appropriate higher level + protocol. Multiple channels can share the same baseband + connection. + + In &os;, a netgraph L2CAP node is + created for each Bluetooth device. This node is normally + connected to the downstream Bluetooth HCI + node and upstream Bluetooth socket nodes. The default name + for the L2CAP node is + devicel2cap. For more details refer to + &man.ng.l2cap.4;. + + 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 0 + bytes in the following example is normal. - &prompt.root; l2ping -a 00:80:37:29:19:a4 + &prompt.root; l2ping -a 00:80:37:29:19:a4 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 &man.l2control.8; utility is used to perform various - operations on L2CAP nodes. This example - shows how to obtain the list of logical connections (channels) - and the list of baseband connections for the local - device: + The &man.l2control.8; utility is used to perform various + operations on L2CAP nodes. This example + shows how to obtain the list of logical connections + (channels) and the list of baseband connections for the + local device: - &prompt.user; l2control -a 00:02:72:00:d4:1a read_channel_list + &prompt.user; l2control -a 00:02:72:00:d4:1a read_channel_list 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 - 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. + 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. - &prompt.user; btsockstat + &prompt.user; btsockstat 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 - + - - Radio Frequency Communication (<acronym>RFCOMM</acronym>) + + Radio Frequency Communication + (<acronym>RFCOMM</acronym>) - The RFCOMM protocol provides emulation - of serial ports over the L2CAP protocol. - RFCOMM 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 - (RFCOMM channels) between two Bluetooth - devices. - - For the purposes of RFCOMM, a complete - communication path involves two applications running on the - communication endpoints with a communication segment between - them. RFCOMM 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. - - RFCOMM 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. - RFCOMM 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 &os;, RFCOMM is implemented at the - Bluetooth sockets layer. - - - - Service Discovery Protocol - (<acronym>SDP</acronym>) + The RFCOMM protocol provides + emulation of serial ports over the L2CAP + protocol. RFCOMM 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 + (RFCOMM channels) between two Bluetooth + devices. + + For the purposes of RFCOMM, a + complete communication path involves two applications + running on the communication endpoints with a communication + segment between them. RFCOMM 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. + + RFCOMM 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. + RFCOMM 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. - - SDP - + In &os;, RFCOMM is implemented at the + Bluetooth sockets layer. + - The Service Discovery Protocol (SDP) - 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. - - SDP involves communication between a - SDP server and a SDP - 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 SDP server - by issuing a SDP 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. - SDP provides a mechanism for discovering - services and their attributes, but it does not provide a - mechanism for utilizing those services. - - Normally, a SDP 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 - SDP server's service records without any - prior information about the services. This process of - looking for any offered services is called - browsing. - - The Bluetooth SDP 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 SDP browse query. + + Service Discovery Protocol + (<acronym>SDP</acronym>) - &prompt.user; sdpcontrol -a 00:01:03:fc:6e:ec browse + + SDP + + + The Service Discovery Protocol (SDP) + 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. + + SDP involves communication between a + SDP server and a SDP + 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 SDP + server by issuing a SDP 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. + SDP provides a mechanism for discovering + services and their attributes, but it does not provide a + mechanism for utilizing those services. + + Normally, a SDP 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 + SDP server's service records without any + prior information about the services. This process of + looking for any offered services is called + browsing. + + The Bluetooth SDP 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 + SDP browse query. + + &prompt.user; sdpcontrol -a 00:01:03:fc:6e:ec browse 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 - Note that each service has a list of attributes, such - as the RFCOMM 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 - OBEX Object Push - (OPUSH) service: - - &prompt.user; sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH - - Offering services on &os; to Bluetooth clients is done - with the &man.sdpd.8; server. The following line can be added - to /etc/rc.conf: - - sdpd_enable="YES" - - Then the &man.sdpd.8; daemon can be - started with: - - &prompt.root; service sdpd start - - The local server application that wants to provide a - Bluetooth service to remote clients will register the service - with the local SDP daemon. An example of - such an application is &man.rfcomm.pppd.8;. Once started, - it will register the Bluetooth LAN service with the local - SDP daemon. - - The list of services registered with the local - SDP server can be obtained by issuing a - SDP browse query via the local control - channel: + Note that each service has a list of attributes, such + as the RFCOMM 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 + OBEX Object Push + (OPUSH) service: + + &prompt.user; sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH + + Offering services on &os; to Bluetooth clients is done + with the &man.sdpd.8; server. The following line can be + added to /etc/rc.conf: + + sdpd_enable="YES" + + Then the &man.sdpd.8; daemon can be started with: + + &prompt.root; service sdpd start + + The local server application that wants to provide a + Bluetooth service to remote clients will register the + service with the local SDP daemon. An + example of such an application is &man.rfcomm.pppd.8;. Once + started, it will register the Bluetooth LAN service with the + local SDP daemon. + + The list of services registered with the local + SDP server can be obtained by issuing a + SDP browse query via the local control + channel: - &prompt.root; sdpcontrol -l browse - + &prompt.root; sdpcontrol -l browse + - - <acronym>OBEX</acronym> Object Push - (<acronym>OPUSH</acronym>) + + <acronym>OBEX</acronym> Object Push + (<acronym>OPUSH</acronym>) - - OBEX - + + OBEX + - 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 Personal Information Manager (PIM) - applications. - - The OBEX server and client are - 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 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 - 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, - and a new object, the business card, is pushed into the - phone's directory. + 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 Personal Information Manager (PIM) + applications. + + The OBEX server and client are + 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 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 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, and a new object, the business card, is + pushed into the phone's directory. - &prompt.user; obexapp -a 00:80:37:29:19:a4 -C IrMC + &prompt.user; obexapp -a 00:80:37:29:19:a4 -C IrMC 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) - In order to provide the OPUSH 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 - /var/spool/obex. Finally, start the - OBEX server on a valid - RFCOMM channel number. The - OBEX server will automatically register - the OPUSH service with the local - SDP daemon. The example below shows how - to start the OBEX server. - - &prompt.root; obexapp -s -C 10 - - - - Serial Port Profile (<acronym>SPP</acronym>) - - The Serial Port Profile (SPP) 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. - - 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'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, - specify a RFCOMM channel on the command - line. + In order to provide the OPUSH + 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 + /var/spool/obex. Finally, start the + OBEX server on a valid + RFCOMM channel number. The + OBEX server will automatically register + the OPUSH service with the local + SDP daemon. The example below shows how + to start the OBEX server. + + &prompt.root; obexapp -s -C 10 + + + + Serial Port Profile (<acronym>SPP</acronym>) + + The Serial Port Profile (SPP) 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. + + 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'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, + specify a RFCOMM channel on the command + line. - &prompt.root; rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6 + &prompt.root; rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6 rfcomm_sppd[94692]: Starting on /dev/ttyp6... - Once connected, the pseudo tty can be used as serial - port: + Once connected, the pseudo tty can be used as serial + port: - &prompt.root; cu -l ttyp6 - - + &prompt.root; cu -l ttyp6 + + Troubleshooting - 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 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 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 - the terminal and to dump the Bluetooth packets to a - file. + 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 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 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 the terminal and + to dump the Bluetooth packets to a file.