docs/52514, Bluetooth Handbook Chapter
Pav Lucistnik
pav at oook.cz
Sun Jun 1 11:50:20 UTC 2003
The following reply was made to PR docs/52514; it has been noted by GNATS.
From: Pav Lucistnik <pav at oook.cz>
To: Hiten Pandya <hmp at FreeBSD.ORG>
Cc: bug-followup at FreeBSD.ORG
Subject: Re: docs/52514, Bluetooth Handbook Chapter
Date: 01 Jun 2003 13:43:49 +0200
--=-xhrw/zZeuo+fqFQCDfUF
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
V ne, 01. 06. 2003 v 08:17, Hiten Pandya napsal:
> Hello Pav.
>
> Thanks for this nice documentation what it is needed most. Here are
> some comments on your Bluetooth documentation:
>
> First of all, this chapter should be in the ``Desktop'' section, just as
> Murray pointed out.
I must disagree here. Look at the Desktop chapter, it contains some tips
on commonly used applications on FreeBSD. Technical section like
Bluetooth does not fit there, it's completely something different.
Bluetooth best fits to Advanced Networking chapter IMHO, it belongs
where Wi-Fi already is.
> Some <indexterms> would help:
>
> Bluetooth, Wi-Fi, Ad-hoc etc.
>
> You should provide <indexterms> for the various acronyms and
> abbreviations used throughout this chapter. It will make it
> easier to find information in the printed version of the
> Handbook.
Ok, added indexterms for Bluetooth, pairing, HCI, L2CAP, SDP and Obex.
Wi-Fi have it's own Handbook section, Ad-hoc is Wi-Fi terminus.
> + <sect2>
> + <title>Introduction</title>
> + <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 like mobile
> + phones, handhelds and laptops. Unlike the other popular wireless
> + technology, Wi-Fi, Bluetooth offers higher level service profiles,
>
> This could probably be:
> "Unlike its counterpart, <acronym>Wi-Fi</acronym>," ...
I don't think that Bluetooth is a counterpart of Wi-Fi. It's companion,
or supplement. These two technologies are not competitors.
> + <para>The Bluetooth stack in FreeBSD is implemented using Netgraph.
> + A Broad variety of USB dongles is supported by the &man.ng.ubt.4; driver.
>
> The Bluetooth stack in FreeBSD is implemented using the Netgraph
> facility (see &man.netgraph.4;). A broad variety of USB dongles ...
Ok, used.
> + The 3Com PC Card 3CRWB60-A is supported by the &man.ng.bt3c.4; driver.
> + Serial and UART based Bluetooth devices are supported via
> + &man.ng.h4.4; and &man.hcseriald.8;. This chapter describes using
> + a USB Bluetooth dongle. Bluetooth support is available only on
> + FreeBSD 5.0 and newer systems.</para>
>
> Bluetooth support is available in FreeBSD 5.0 and newer
> systems ...
Ok, used.
> (Also, you must note somewhere that the core Netgraph module is
> required if its loaded via a KLD.
Used will never load modules by hand, with only exception of device
driver if user wants the device be recognized during boot. All module
loading, bluetooth stack and netgraph, is done with rc.bluetooth script.
Users are encouraged to use this script.
> You should also explan the
> various Bluetooth kernel configuration options, and how to
> utilise them)
There aren't any. Bluetooth is meant to be build as modules, I'm not
sure if compiling it into kernel is supported. It's similar as with
soundcard drivers. And you don't need to add anything to your GENERIC to
build these modules.
> + <sect2>
> + <title>HCI and Inquiry</title>
> +
> + <para>Now it is time to discover some nearby bluetooth devices.
>
> s/bluetooth/Bluetooth/
Ok, changed them all.
> + Discovering devices and many other interesting tasks is done with
>
> "Interesting taks like discovering devices, and such are done with..."
Ok, that sounds better. I dropped "interesting" as it's not really that
interesting, they are low level stuff that user should never have to use
directly.
> + <para>BD_ADDR is the unique address of a bluetooth device, similar to MAC
>
> <literal>BD_ADDR</literal>
Ok, changed.
> + <title>Pairing of Devices</title>
> +
> + <para>By default, Bluetooth communication is not authorized and any device
>
> Isn't ``authenticatied'' a better word instead of ``authorized''?
> Because at start of the chapter, you said its unlicensed, and
> available for personal networks; which makes ``authorized''
> sound a little obfuscated, IMHO.
Yes, when you think about it, you're right. Changed to "authenticated".
> +
> + <para>You can choose any PIN you like. Note that some devices, like
> + headsets, have a fixed PIN built in. Start <command>hcsecd -d</command>.
> + The <option>-d</option> switch forces the daemon to stay in the
> + terminal and not fork to the background, so we can see what is happening.
> + Set the remote device to receive pairing and initiate the HCI connection
> + to the remote device. The remote device should say that pairing was
> + accepted, and let you enter the PIN. Enter the same PIN as you have in your
> + <filename>hcsecd.conf</filename>. Now your PC and remote device are paired.
> + Alternatively, you can initiate pairing on the remote device.
> + This will appear in the <command>hcsecd</command> output:</para>
>
> Use &man.hcsecd.8; ?
I already have this one paragraph before. What's the policy in
situations like this, when the name of a command repeats many times in a
short section of the text - should we use man entities everywhere, or
should we use it only in the first appearance and leave rest alone?
> + <sect2>
> + <title>Service Discovery Protocol (SDP)</title>
> + <para>If you want to know which services a Bluetooth device offers, and
> + on which RFCOMM channels, build <application>libbluetooth</application>
> + and <application>sdp-1.0rc3</application> from <ulink
> + url="http://www.geocities.com/m_evmenkin/">Maksim Evmenkin's
>
> Erm, hmm. According to his emails to me. His surname is ``Yevmenkin.''
*sigh* I'm sorry. The surprising part is that this text got his approval
and he haven't complained/noticed. Also his geocities account is
"Evmenkin" ... Changed it all to "Yevmenkin".
> + <sect2>
> + <title>Dial-up Networking (DUN) and Local Area Network (LAN)</title>
> +
> + <para>Bluetooth can be used for connecting to the Internet, either over
> + PPP (mobile phones) or the local network (access points). The Dial-up Networking
> + profile on FreeBSD is implemented with &man.ppp.8; and
>
> Use &os;, instead of FreeBSD. This should be done everywhere.
I don't see this done in other sections of advanced-networking.sgml, is
it new policy? Replaced everywhere in my section.
> + to something ppp can operate with. Create ppp labels in
>
> s/ppp/PPP/, wherever ``ppp'' is used.
Changed.
> + <sect3>
> + <title>Something is going wrong, can I see what exactly is happening?</title>
> + <para>Yes, you can. Use the <application>hcidump</application> tool
> &man.hcidump.<sect> (I don't recall its section number)
hcidump(1) but I can't use this entity, because hcidump is not part of
FreeBSD, it's third party application, and thus the man page reference
will leads to nowhere.
> + from <ulink url="http://www.geocities.com/m_evmenkin/">Maksim Evmenkin's
> + snapshot</ulink>, which works much like &man.tcpdump.1;. You can
> + use it to display the content of Bluetooth packets on the terminal
> + and to record Bluetooth communication for later analyzation.</para>
> + </sect3>
>
> Lastly, you should use formal structure instead of ``Question and
> Answer'' type structure for this (Troubleshooting) section. We
> are trying to cut down on QA sections in the Handbook, last time
> I checked.
How should it look like? I have no idea. Can you point me to some
example elsewhere in the Handbook? Thanks.
Updated patch is attached.
--
Pav Lucistnik <pav at oook.cz>
Buh je realny, pokud nebyl deklarovan jako integer.
--=-xhrw/zZeuo+fqFQCDfUF
Content-Disposition: attachment; filename=patch
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; name=patch; charset=ISO-8859-2
--- original.sgml Sun May 25 12:34:18 2003
+++ chapter.sgml Sun Jun 1 13:31:56 2003
@@ -6732,6 +6732,395 @@
support AAAA records.</para>
</sect2>
</sect1>
+
+ <sect1 id=3D"network-bluetooth">
+ <sect1info>
+ <authorgroup>
+ <author>
+ <firstname>Pav</firstname>
+ <surname>Lucistnik</surname>
+ <contrib>Written by </contrib>
+ <affiliation>
+ <address><email>pav at oook.cz</email></address>
+ </affiliation>
+ </author>
+ </authorgroup>
+ </sect1info>
+ <title>Bluetooth</title>
+ =20
+ <indexterm><primary>Bluetooth</primary></indexterm>
+ <sect2>
+ <title>Introduction</title>
+ <para>Bluetooth is a wireless technology for creating personal netwo=
rks
+ operating in the 2.4 GHz unlicensed band, with a range of 10 meter=
s.
+ Networks are usually formed ad-hoc from portable devices like mobi=
le
+ phones, handhelds and laptops. Unlike the other popular wireless
+ technology, Wi-Fi, Bluetooth offers higher level service profiles,
+ e.g. FTP-like file servers, file pushing, voice transport, serial
+ line emulation and more.</para>
+ =20
+ <para>The Bluetooth stack in &os; is implemented using the Netgraph
+ facility (see &man.netgraph.4;).
+ A Broad variety of USB dongles is supported by the &man.ng.ubt.4; =
driver.
+ The 3Com PC Card 3CRWB60-A is supported by the &man.ng.bt3c.4; dri=
ver.
+ Serial and UART based Bluetooth devices are supported via
+ &man.ng.h4.4; and &man.hcseriald.8;. This chapter describes using
+ a USB Bluetooth dongle. Bluetooth support is available
+ in &os; 5.0 and newer systems.</para>
+ </sect2>
+ =20
+ <sect2>
+ <title>Plugging in the Device</title>
+ <para>Device drivers are by default available as kernel modules.
+ Before attaching a device, you need to load the driver into the
+ kernel:</para>
+ =20
+ <screen>&prompt.root; <userinput>kldload ng_ubt</userinput></screen>
+ =20
+ <para>If the Bluetooth device is present in the system during system
+ startup, load the module from <filename>/boot/loader.conf</filenam=
e>:</para>
+ =20
+ <programlisting>ng_ubt_load=3D"YES"</programlisting>
+ =20
+ <para>Plug in your USB dongle. Similar output will appear on the co=
nsole
+ (or in syslog):</para>
+ =20
+ <screen>ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2
+ubt0: Interface 0 endpoints: interrupt=3D0x81, bulk-in=3D0x82, bulk-out=3D=
0x2
+ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=3D0x83, isoc-out=3D0x3=
;
+ wMaxPacketSize=3D49; nframes=3D6, buffer size=3D294</screen>
+ =20
+ <para>Copy <filename>/usr/src/share/examples/netgraph/bluetooth/rc.b=
luetooth</filename>
+ to some convenient place, like <filename>/etc/rc.bluetooth</filena=
me>.
+ This script is used to start and stop the Bluetooth stack. It is =
a good idea
+ to stop the stack before unplugging the device, but it is not (usu=
ally)
+ fatal. When starting the stack, you will receive output similar t=
o this:</para>
+ =20
+ <screen>&prompt.root; <userinput>/etc/rc.bluetooth start ubt0</useri=
nput>
+BD_ADDR: 00:02:72:00:d4:1a
+Features: 0xff 0xff 0xf 00 00 00 00 00=20
+<3-Slot> <5-Slot> <Encryption> <Slot offset>
+<Timing accuracy> <Switch> <Hold mode> <Sniff mode>=
;
+<Park mode> <RSSI> <Channel quality> <SCO link>
+<HV2 packets> <HV3 packets> <u-law log> <A-law log>=
; <CVSD>
+<Paging scheme> <Power control> <Transparent SCO data>=20
+Max. ACL packet size: 192 bytes
+Number of ACL packets: 8
+Max. SCO packet size: 64 bytes
+Number of SCO packets: 8</screen>
+ =20
+ </sect2>
+ =20
+ <indexterm><primary>HCI</primary></indexterm>
+ <sect2>
+ <title>HCI and Inquiry</title>
+
+ <para>Now it is time to discover some nearby Bluetooth devices.
+ Tasks like discovering devices, and such are done with
+ the &man.hccontrol.8; utility. You will receive a list of discove=
rable
+ devices in a few seconds:</para>
+
+ <screen>&prompt.user; <userinput>hccontrol -n ubt0hci inquiry</useri=
nput>
+Inquiry result, num_responses=3D1
+Inquiry result #0
+ BD_ADDR: 00:80:37:29:19:a4
+ Page Scan Rep. Mode: 0x1
+ Page Scan Period Mode: 00
+ Page Scan Mode: 00
+ Class: 52:02:04
+ Clock offset: 0x78ef
+Inquiry complete. Status: No error [00]</screen>
+
+ <para><literal>BD_ADDR</literal> is the unique address of a Bluetoot=
h device, similar to MAC
+ addresses of network cards. This address is needed for further
+ communication with a device. Let us try to read the device's name=
:</para>
+
+ <screen>&prompt.user; <userinput>hccontrol -n ubt0hci remote_name_re=
quest 00:80:37:29:19:a4 0 0 0</userinput>
+BD_ADDR: 00:80:37:29:19:a4
+Name: Pav's T39</screen>
+
+ <para>If you perform a discovery on a different Bluetooth device, it=
will find
+ your computer as <quote>your.host.name (ubt0)</quote>.</para>
+
+ <para>You can list active baseband connections:</para>
+
+ <screen>&prompt.user; <userinput>hccontrol -n ubt0hci read_connectio=
n_list</userinput>
+Remote BD_ADDR Handle Type Mode Role Encrypt Pending Queue State
+00:80:37:29:19:a4 41 ACL 0 MAST NONE 0 0 OPEN</screen=
>
+
+ <para>Handle is useful for manually disconnecting a connection:</par=
a>
+
+ <screen>&prompt.root; <userinput>hccontrol -n ubt0hci disconnect 41<=
/userinput>
+Connection handle: 41
+Reason: Connection terminated by local host [0x16]</screen>
+
+ <para>Refer to <command>hccontrol help</command> for a complete list=
ing of
+ available commands. Note that the majority of commands does not r=
equire
+ superuser privileges.</para>
+ =20
+ </sect2>
+ =20
+ <indexterm><primary>L2CAP</primary></indexterm>
+ <sect2>
+ <title>L2CAP</title>
+
+ <para>L2CAP is a higher level of connection in Bluetooth standards.
+ A useful command is &man.l2ping.8;, which can be used to ping
+ other devices. Some devices might not return all of the data
+ send to them, so <emphasis>0 bytes</emphasis> as in this example
+ is a normal state.</para>
+
+ <screen>&prompt.root; <userinput>l2ping -a 00:80:37:29:19:a4</userin=
put>
+0 bytes from 0:80:37:29:19:a4 seq_no=3D0 time=3D48.633 ms result=3D0=20
+0 bytes from 0:80:37:29:19:a4 seq_no=3D1 time=3D37.551 ms result=3D0=20
+0 bytes from 0:80:37:29:19:a4 seq_no=3D2 time=3D28.324 ms result=3D0=20
+0 bytes from 0:80:37:29:19:a4 seq_no=3D3 time=3D46.150 ms result=3D0</scre=
en>
+
+ <para>The &man.l2control.8; utility is used to configure L2CAP nodes
+ and read their state. This example shows file transfer to a Palm
+ handheld:</para>
+
+ <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
+&prompt.user; <userinput>l2control -a 00:02:72:00:d4:1a read_connection_li=
st</userinput>
+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 does a simi=
lar
+ job as &man.netstat.1; does, but for Bluetooth sockets, logical
+ connections on top of baseband connections. The example output sh=
ows
+ the same connection as l2control above:</para>
+
+ <screen>&prompt.user; <userinput>btsockstat</userinput>
+Active L2CAP sockets
+PCB Recv-Q Send-Q Local address/PSM Foreign address CID Sta=
te
+c2afe900 0 0 00:02:72:00:d4:1a/3 00:07:e0:00:0b:ca 66 OPE=
N
+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<=
/screen>
+
+ </sect2>
+ =20
+ <indexterm><primary>pairing</primary></indexterm>
+ <sect2>
+ <title>Pairing of Devices</title>
+
+ <para>By default, Bluetooth communication is not authenticated and a=
ny device
+ can talk to any other device. Some devices, like mobile phones, r=
equire
+ authentication for some functionality, like Internet connections. =
This
+ is done with PIN numbers - you enter the same (up to 16 digits lon=
g)
+ number on both devices. This operation is called <emphasis>pairin=
g</emphasis>.
+ The daemon that answers pairing requests is &man.hcsecd.8;. Copy
+ <filename>/usr/src/usr.sbin/bluetooth/hcsecd/hcsecd.conf</filename=
>
+ to <filename>/usr/local/etc</filename> and edit it. The following=
is an
+ example section for a mobile phone, with the PIN arbitrarily set to 1234:=
</para>
+
+ <programlisting>device {
+ bdaddr 00:80:37:29:19:a4;
+ name "Pav's T39";
+ key nokey;
+ pin "1234";
+ }</programlisting>
+
+ <para>You can choose any PIN you like. Note that some devices, like
+ headsets, have a fixed PIN built in. Start <command>hcsecd -d</co=
mmand>.
+ The <option>-d</option> switch forces the daemon to stay in the
+ terminal and not fork to the background, so we can see what is hap=
pening.
+ Set the remote device to receive pairing and initiate the HCI conn=
ection
+ to the remote device. The remote device should say that pairing w=
as
+ accepted, and let you enter the PIN. Enter the same PIN as you ha=
ve in your
+ <filename>hcsecd.conf</filename>. Now your PC and remote device a=
re paired.
+ Alternatively, you can initiate pairing on the remote device.
+ This will appear in the <command>hcsecd</command> output:</para>
+
+<programlisting>hcsecd[16484]: Got Link_Key_Request event from 'ubt0hci', =
remote bdaddr 0:80:37:29:19:a4
+hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name =
'Pav's T39', link key doesn't exist
+hcsecd[16484]: Sending Link_Key_Negative_Reply to 'ubt0hci' for remote bda=
ddr 0:80:37:29:19:a4
+hcsecd[16484]: Got PIN_Code_Request event from 'ubt0hci', remote bdaddr 0:=
80:37:29:19:a4
+hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name =
'Pav's T39', PIN code exists
+hcsecd[16484]: Sending PIN_Code_Reply to 'ubt0hci' for remote bdaddr 0:80:=
37:29:19:a4</programlisting>
+
+ </sect2>
+ =20
+ <indexterm><primary>SDP</primary></indexterm>
+ <sect2>
+ <title>Service Discovery Protocol (SDP)</title>
+ <para>If you want to know which services a Bluetooth device offers, =
and
+ on which RFCOMM channels, build <application>libbluetooth</applica=
tion>
+ and <application>sdp-1.0rc3</application> from <ulink
+ url=3D"http://www.geocities.com/m_evmenkin/">Maksim Yevmenkin's
+ snapshot</ulink>. Then, run <application>sdptool</application> an=
d
+ observe (the output is snipped a bit, as this tool is quite talky)=
:</para>
+
+ <screen>&prompt.root; <userinput>sdptool browse 00:80:37:29:19:a4</u=
serinput>
+Browsing 00:80:37:29:19:A4 ...
+Service Name: Dial-up Networking
+Protocol Descriptor List:
+ "L2CAP" (0x0100)
+ "RFCOMM" (0x0003)
+ Channel: 1
+
+Service Name: Fax
+Protocol Descriptor List:
+ "L2CAP" (0x0100)
+ "RFCOMM" (0x0003)
+ Channel: 2
+
+Service Name: Voice gateway
+Service Class ID List:
+ "Headset Audio Gateway" (0x1112)
+ "Generic Audio" (0x1203)
+Protocol Descriptor List:=20
+ "L2CAP" (0x0100)
+ "RFCOMM" (0x0003)
+ Channel: 3
+</screen>
+
+ <para>... and so on. You will need the channel number later for usi=
ng
+ a given service. Some devices do not support browsing, they retur=
n
+ an empty list, but you can try searching for a specific service.</=
para>
+
+ <screen>&prompt.root; <userinput>sdptool search --bdaddr 00:07:e0:00=
:0b:ca OPUSH</userinput></screen>
+ =20
+ <para>Offering services on &os; to other devices is done using the
+ <application>sdpd</application> server.</para>
+ <screen>&prompt.root; <userinput>sdpd</userinput></screen>
+ =20
+ <para>Registering a given Bluetooth service to a RFCOMM channel numb=
er:</para>
+ <screen>&prompt.root; <userinput>sdptool add --channel=3D7 LAN</user=
input></screen>
+ =20
+ <para>Checking services offered by our computer:</para>
+ <screen>&prompt.root; <userinput>sdptool browse ff:ff:ff:00:00:00</u=
serinput></screen>
+ </sect2>
+
+ <sect2>
+ <title>Dial-up Networking (DUN) and Local Area Network (LAN)</title>
+
+ <para>Bluetooth can be used for connecting to the Internet, either o=
ver
+ PPP (mobile phones) or the local network (access points). The Dia=
l-up Networking
+ profile on &os; is implemented with &man.ppp.8; and
+ &man.rfcomm.pppd.8;, a wrapper that converts RFCOMM Bluetooth conn=
ections
+ to something PPP can operate with. Create PPP labels in
+ <filename>/etc/ppp/ppp.conf</filename>, examples from the &man.rfc=
omm.pppd.8;
+ manual page can be used.</para>
+ =20
+ <para>Connecting to the Internet through a mobile phone (DUN profile=
). First, find
+ out the correct RFCOMM channel on the remote device using
+ <application>sdptool</application>. Then, use &man.rfcomm.pppd.8;=
:</para>
+
+ <screen>&prompt.root; <userinput>rfcomm_pppd -a 00:80:37:29:19:a4 -c=
-C 1 -l rfcomm-dialup</userinput></screen>
+ =20
+ <para>Running a Bluetooth access point on &os;. First, register a
+ RFCOMM channel for LAN service on the local <application>sdpd</app=
lication>.
+ Then, start the PPP server. Use <literal>BD_ADDR</literal> of the=
local Bluetooth device and
+ the channel number registered with <application>sdpd</application>=
.</para>
+ =20
+ <screen>&prompt.root; <userinput>rfcomm_pppd -a 00:02:72:00:d4:1a -s=
-C 7 -l rfcomm-server</userinput></screen>
+ =20
+ </sect2>
+
+ <indexterm><primary>OBEX</primary></indexterm>
+ <sect2>
+ <title>OBEX Push (OPUSH)</title>
+ <para>OBEX is a widely used protocol for simple file transfers betwe=
en
+ mobile devices. It's main use is in infrared communication, where=
it is
+ used for generic file transfers between notebooks or Palm handheld=
s,
+ and for sending business cards or calendar entries between mobile
+ phones and other devices with PIM applications.</para>
+ =20
+ <para>The OBEX client is implemented in the
+ <application>obexapp</application> utility from <ulink =
=20
+ url=3D"http://www.geocities.com/m_evmenkin/">Maksim Yevmenkin's
+ snapshot</ulink>. It needs the <application>openobex</application=
>
+ library from same package and the
+ <filename role=3D"package">devel/glib12</filename> port. Note tha=
t
+ <application>obexapp</application> does not require root privilege=
s
+ to operate.</para>
+ =20
+ <para>OBEX client. First, find which channel on the remote device i=
s IrMC
+ Synchronization or OBEX Object Push. After that, use
+ <application>obexapp</application>. Here is an example session wh=
ere
+ we download a file (device info from a mobile phone) and send
+ a file (business card to the phone's directory):</para>
+ =20
+ <screen>&prompt.user; <userinput>obexapp -a 00:80:37:29:19:a4 -C 10<=
/userinput>
+obex> get
+get: remote file> telecom/devinfo.txt
+get: local file> devinfo-t39.txt
+Success, response: OK, Success (0x20)
+obex> put
+put: local file> new.vcf
+put: remote file> new.vcf
+Success, response: OK, Success (0x20)
+obex> di
+Success, response: OK, Success (0x20)</screen>
+
+ <para>OBEX server. First, register the OPUSH service with the local
+ <application>sdpd</application>. If OPUSH does not work,
+ you can try the FTRN service instead. Then, start the OBEX daemon
+ using the channel number registered with sdpd:</para>
+ =20
+ <screen>&prompt.root; <userinput>obexapp -s -C 10</userinput></scree=
n>
+ =20
+ <para>Received files will appear in <filename>/var/spool/obex</filen=
ame>.
+ This can be overriden with the <option>-r</option> switch. Make s=
ure
+ the directory exists, <application>obexapp</application> will not
+ create it. On a typical workstation with a single user it is usef=
ul
+ to set a default owner of received files. See obexapp(1)
+ for details.</para>
+ =20
+ </sect2>
+
+ <sect2>
+ <title>Serial Port Profile (SP)</title>
+ <para>Bluetooth can be used to emulate serial port connections.
+ To connect to a remote device, first locate the RFCOMM channel wit=
h the
+ Serial Port profile. Then, start the Serial Port Profile Daemon
+ &man.rfcomm.sppd.1; with a free pseudo tty:</para>
+
+ <screen>&prompt.root; <userinput>rfcomm_sppd -a 00:07:E0:00:0B:CA -c=
1 -t /dev/ttyp6</userinput>
+rfcomm_sppd[94692]: Starting on /dev/ttyp6...</screen>
+
+ <para>Now connect this pseudo tty to your actual terminal:</para>
+ =20
+ <screen>&prompt.root; <userinput>cu -l ttyp6</userinput></screen>
+
+ </sect2>
+ =20
+ <sect2>
+ <title>Troubleshooting</title>
+ =20
+ <sect3>
+ <title>A remote device cannot connect to us</title>
+ <para>Some older devices do not support role switching. By defaul=
t,
+ when &os; is accepting a connection, it tries to switch roles
+ to become a master. Devices which do not support this will not
+ be able to connect. Role switching is performed when a connecti=
on
+ is being established, so we cannot ask the remote device if it d=
oes
+ support role switching. There is a driver option to disable rol=
e
+ switching on our side:</para>
+ <screen>&prompt.root; <userinput>hccontrol -n ubt0hci write_node_r=
ole_switch 0</userinput></screen>
+ </sect3>
+ =20
+ <sect3>
+ <title>Something is going wrong, can I see what exactly is happeni=
ng?</title>
+ <para>Yes, you can. Use the <application>hcidump</application> to=
ol
+ from <ulink url=3D"http://www.geocities.com/m_evmenkin/">Maksim Ye=
vmenkin's
+ snapshot</ulink>, which works much like &man.tcpdump.1;. You can
+ use it to display the content of Bluetooth packets on the terminal
+ and to record Bluetooth communication for later analyzation.</para=
>
+ </sect3>
+ =20
+ </sect2>
+
+ </sect1>
+
</chapter>
=20
<!--
--=-xhrw/zZeuo+fqFQCDfUF--
More information about the freebsd-doc
mailing list