Wireless Hacks. 1917 IndustrialStrength Tips and Tools [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Wireless Hacks. 1917 IndustrialStrength Tips and Tools [Electronic resources] - نسخه متنی

Rob Flickenger

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید










Hack 18 Bluetooth File Transfers in Linux


Exchange data freely between your Bluetooth
device and your Linux box.

[Hack #17] from anywhere your cell phone
works is pretty darn cool, but your phone probably has other
features. Maybe someone messaged you a photo from their family
barbecue that you want to copy over to your laptop. Or maybe you just
want to install some applications on your shiny new phone.

The heart of file transfer over Bluetooth
is called the Object
Exchange, or OBEX, protocol, a binary file
transfer protocol run over not merely Bluetooth, but also Infrared
and even generic TCP/IP. The
OpenOBEX project at
http://openobex.sf.net/ offers
the most ubiquitous open source implementation of the protocol. You
can get packages for libopenobex and
openobex-apps from the sid
distribution, and Red Hat packages for openobex
can be had from the
SourceForge site
or on rpmfind.net. Bluetooth actually supports
two different OBEX profiles for transferring files:

OBEX Push, which is primarily used
for dumping individual files to a Bluetooth device, and OBEX File
Transfer, which supports a richer set of file exchange operations.

Unfortunately,
the present state of the art in Bluetooth file transfer using Linux
is still in considerable flux. The
openobex-apps package contains an
obex_test application, which offers one
very rudimentary way of sending files to your Bluetooth devices.
First, you need to figure out which Bluetooth channel your phone or
other device uses for OBEX File Transfer; to do this, type:

# sdptool search FTRN
Inquiring ...
Searching for FTRN on 00:11:22:33:44:55 ...
Service Name: OBEX File Transfer
Service RecHandle: 0x10003
Service Class ID List:
"OBEX File Transfer" (0x1106)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 10
"OBEX" (0x0008)

Now you can try connecting to the device with
obex_test, using the -b
option (for Bluetooth), the BD address of the device, and the FTRN
channel number:

$ obex_test -b 00:11:22:33:44:55 10
Using Bluetooth RFCOMM transport
OBEX Interactive test client/server.
> c
Connect OK!
Version: 0x10. Flags: 0x00
> x
PUSH filename> /home/sderle/images/image.jpg
name=/home/sderle/images/image.gif, size=7294
Going to send /home/sderle/images/image.gif(opt21.gif), 7294 bytes
Filling stream!

obex_test proceeds to display some progress
messages, followed by a confirmation:

Made some progress...
Made some progress...
Made some progress...
Filling stream!
PUT successful!

The file should appear on your device. Similarly,
obex_test can receive files sent from your
device, if you configure your computer's Bluetooth
interface to answer to OBEX Push requests, again using
sdptool with the same channel your device uses
for OBEX Push:

$ sdptool add --channel=10 OPUSH
$ obex_test -b 00:11:22:33:44:55 10
Using Bluetooth RFCOMM transport
OBEX Interactive test client/server.
> s

obex_test should print a blank line and then
pause. Now send a file from your phone via Bluetooth.
You'll see a ton of status messages, and then
obex_test will report that it's
finished. You should be able to find your file in
/tmp.

The problem with
obex_test, other than a total lack of
documentation, is that it's entirely driven by
terminal-based user interaction. What if we want to script file
transfers or be able to receive files automatically? Another,
probably easier way of getting files from your computer to your phone
involves a little app called
ussp-push, which you can get from
http://www.unrooted.net/hacking/ussp-push.tgz.
ussp-push is based on some code from the Affix
stack, but actually relies on
OpenOBEX. Also, it
doesn't compile at present right out of the box, so
we'll use Perl to tweak it so that it compiles
properly with modern versions of OpenOBEX:

# tar xfz ussp-push.tgz
# cd ussp-push
# perl -pi -e 's/custfunc\.userdata/custfunc.customdata/g' obex_main.c
# make
...
# cp ussp-push /usr/local/bin

ussp-push relies on having an
RFCOMM serial device bound to the
Bluetooth channel your device uses for OBEX Push, so
we'll first need to fire up
sdptool again,
and then use rfcomm to bind the device to the
listed channel:

# sdptool search OPUSH
Inquiring ...
Searching for OPUSH on 00:11:22:33:44:55 ...
Service Name: OBEX Object Push
Service RecHandle: 0x10004
Service Class ID List:
"OBEX Object Push" (0x1105)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 9
"OBEX" (0x0008)
# rfcomm bind /dev/rfcomm1 00:11:22:33:44:55 9

Now you can use ussp-push to send files to your
device.

$ ussp-push /dev/rfcomm1 /home/sderle/images/image.jpg image.jpg

ussp-push takes three arguments: an RFCOMM
device, a local file to push, and the name of the file to save it as
on the remote side. When you run ussp-push,
you'll see an avalanche of progress info, hopefully
concluding with the file appearing on your phone. If you create an
entry for the new RFCOMM device in
/etc/bluetooth/rfcomm.conf, you can have the device bound on boot.
Save the following wrapper script as
btpush
,
and save it somewhere handy (such as your ~/bin
directory). You can then use it to trivially send files directly to
your phone:

#!/bin/bash
# btpush - send files to a Bluetooth device using ussp-push
# just run it as: btpush <file>
ussp-push /dev/rfcomm1 $1 `basename $1`

If you get permissions issues when running
ussp-push, make sure your
/dev/rfcomm* devices are group-writeable, and
are owned by a group that you're a member of.

Similarly, you can receive files using another small app called
obexserver , which you
can fetch from http://www.frasunek.com/sources/unix/obexserver.c.
obexserver needs to be built together with
openobex-apps. Once you've
built openobex-apps, do the following from
within the top-level source directory:

# cd src
# wget http://www.frasunek.com/sources/unix/obexserver.c
# gcc -o obexserver obexserver.c libmisc.a -lopenobex
# cp obexserver /usr/local/bin

To receive files, first set up OBEX Push service on your computer by
running sdptool add --channel=10 OPUSH, changing
the channel as necessary to match the one your device uses for OBEX
Push. Now you can just run obexserver without
arguments, and send a file from your phone.
obexserver will receive the file, store it in
/tmp, and exit.

Being able send files from phone to computer and back is nice, but
having to send and receive files individually
doesn't present the absolutely most convenient
interface. Fortunately, if your Bluetooth device is running the
SymbianOS or EPOC
operating systemthis includes Series 60
phones and the
Ericsson P800you can actually mount your
device's filesystem on your computer via
NFS. The package
that performs this minor miracle is called p3nfs, and it's available
at http://www.koeniglich.de/p3nfsl. The
source distribution comes with binaries to run on your phone, in case
you don't have a cross-compiler (which is likely).
The phone application is called
nfsapp, and you can find the appropriate
binary version for your phone in the bin/
subdirectory, with a .sis extension. Use one of
the methods just described to send the appropriate SIS file to your
phone and install it there. Next, build and install p3nfsd in the
usual way. If you installed the RPM provided by
koeniglich.de, you can find the SIS files in
/usr/share/doc/p3nfs-[version].

You'll want to create a mount point in your
filesystem for the NFS share; p3nfs uses
/mnt/psion by default. Also, p3nfs needs its own
RFCOMM device, so you'll need set one up. If
you're running a Nokia phone,
you'll probably want to bind to channel 4;
otherwise, you may be using channel 3.

# mkdir /mnt/phone
# rfcomm bind /dev/rfcomm2 00:11:22:33:44:55 4

Now, start nfsapp on your phone.
Don't worry if you pick the wrong channel at
firstwhen you run nfsapp on your phone,
it will tell you which channel it's listening to. If
you told rfcomm to bind to the wrong one, just
run rfcomm unbind /dev/rfcomm2 and try the right
channel. At first, nfsapp defaults to listening
to the infrared portclick the joystick or press the
p key to cycle between IR, Bluetooth, and TCP
transport. Once you select Bluetooth, nfsapp
gives you 30 seconds to start p3nfs on your computer. Assuming
everything else is configured correctly, you should be able to start
p3nfsd as follows:

# p3nfsd -series60 -tty /dev/rfcomm2 -dir /mnt/phone -user sderle
p3nfsd: version 5.13a, using /dev/rfcomm2 (115200), mounting on /mnt/phone
p3nfsd: to stop the server do "ls /mnt/phone/exit". (pid 3274)

p3nfsd will probably take a few seconds to finish mounting. A quick
look at lsmod will verify that, in fact,
it's using your kernel's NFS
support. You'll want to replace
-series60 with -UIQ or another
option if you're not running a Series 60
phonerun p3nfsd without any options for a list.
You'll want to alter the -tty,
-dir, and -user options as
appropriate. The -user option
isn't strictly necessary, but p3nfsd mounts the
share with user-only read and execute permissions, so if you
don't use it, you'll need to be
root to browse the share. Now you should be able to
cd into /mnt/phone, and do
all the things you're accustomed to doing in a
Unix-like NFS mount. You'll need to ls
/mnt/phone/exit
to unmount the share, which is a little
weird. Otherwise, p3nfsd unmounts after a few minutes of
inactivityyou can control the timeout using the
-timeout option.

By this point, you've got several options for
exchanging data between Bluetooth devices. Obviously, you can easily
reuse these techniques to exchange files between two
Bluetooth-equipped Linux machines as well, and, in fact, these same
methods work pretty well for infrared file transfers, with a little
tweaking, but that's beyond the scope of this hack.
One last thing: if you want your new RFCOMM devices to be there the
next time you boot, don't forget to add entries for
them to /etc/bluetooth/rfcomm.conf. Now start
installing those applications!

Schuyler Erle


/ 158