Building obex-method

I published a Bazaar branch of the Nautilus obex method here:

This version works with the hcid daemon included with Ubuntu Edgy, rather than requiring the btcond daemon from Maemo.

Some simple instructions on building it:

  1. Download and build the osso-gwobex library:

    svn checkout osso-gwobex

    The debian/ directory should work fine to build a package using debuild.

  2. Download and build the obex module:

    bzr branch

    There is no debian packaging for this — just an script.

It should work on other distributions, but I haven’t tried it. The main requirement is bluez-utils 3.7, and that -x is passed to hcid to enable the org.bluez.RFCOMM interface.

Still to do is cleaning up the obex:/// listing of bonded devices, so that it serves desktop entries rather than symlinks, so that it is usable in Nautilus. This would also make it easier to show the device names to the user and get nice icons.


  1. pel
    Posted 21 October, 2006 at 9:41 pm | Permalink

    This is seriously wonderfull!

    Now I’ll have to install edgy on a machine this weekend :)

  2. Johan Hedberg
    Posted 22 October, 2006 at 12:10 am | Permalink

    I took a look at the code and it looks good. One thing however:

    About the “NFTP” service identifier, that’s actually something that btcond supported but hcid doesn’t. You’ll have to give the exact UUID-128 to hcid instead as
    “00005005-0000-1000-8000-0002ee000001″ (I hope that’s correct).

    What it’s about: some Nokia Symbian phones have two OBEX FTP services: one identified with the normal UUID and another with a Nokia specific 128 bit UUID. The service found behind the normal identifier is very limited in features on these phones while the other one supports full OBEX FTP (don’t ask me why).

  3. Wout
    Posted 23 October, 2006 at 11:17 pm | Permalink

    Thank you man. You’re awsome…. I’ve installed the software succesfully and everything works. Great…..

    B.t.w. mine gives me the full name after a while… and it’s fully useable in nautilus. (Pretty stable…)
    I’f you wan’t some testers just let me know….(just say so on your blog…. )
    GReat great great….

  4. Posted 24 October, 2006 at 7:53 am | Permalink

    Thanks! This is awesome. I’ve been thinking for some time now, though, that OBEX != bluetooth.

    There are at least four other media commonly (or less commonly) used for OBEX: USB, IrDA, Serial, and TCP/IP. All of these are supported by OpenOBEX.

    I’ve been told that IrDA is somewhat harder to deal with but USB should be pretty easy. Serial might not be worth implementing. TCP/IP, if supported at all, probably doesn’t need to be discoverable (unless of course it’s advertised through mDNS).

  5. Posted 24 October, 2006 at 9:46 pm | Permalink

    USB should use a different approach: mount it as a filesystem through FUSE/obexfs. I’ll check out how it all works

  6. Posted 25 October, 2006 at 4:30 pm | Permalink

    Wout: yeah. I implemented that a bit after posting this article.

    Andrew/Alex: Matthew Garrett has plans to add bluetooth device support to HAL, which would help here. If I can look up IrDA OBEX and Bluetooth OBEX devices in the HAL hardware database by some property, then it should be possible to support both: the only bluetooth specific code is for listing the paired devices and creating RFCOMM connections.

  7. clp
    Posted 26 October, 2006 at 12:36 am | Permalink

    I get this message in nautilus…

    obex:///” is not a valid location.

    what’s wrong?

    How do I enable the gnome-vfs-2.0 modules?

    Salu2 clp ;)

  8. Posted 26 October, 2006 at 2:30 am | Permalink

    clp: I had the same problem at first. Trouble was that by default things get installed in /usr/local. Try the following:

    ./configure –sysconfdir=/etc –prefix=/usr

  9. clp
    Posted 26 October, 2006 at 5:24 pm | Permalink

    A lot of thanks, Andrew!

    > ./configure –sysconfdir=/etc –prefix=/usr

    It’s a great job!

  10. clp
    Posted 30 October, 2006 at 5:47 am | Permalink

    In amd64 architecture I get this problem in oss-gwobex compilation:

    autoreconf2.50: running: /usr/bin/autoconf error: possibly undefined macro: AC_PROG_LIBTOOL
    If this token and others are legitimate, please use m4_pattern_allow.
    See the Autoconf documentation.
    autoreconf2.50: /usr/bin/autoconf failed with exit status: 1

    Salu2 clp ;)

  11. Onkar Shinde
    Posted 7 November, 2006 at 6:07 am | Permalink

    Works really well. I could see name of my phone and a pretty icon. Did file transfers in both directions without problem.

    I have just one question. The autogen script in the vfs module code says it requires automake1.9. Is this strict dependency?

    Also is opebobex > 1.2. a strict dependency.

    Please note that I have not even looked into code. So pardon if my questions are redundant.

  12. Hans
    Posted 12 November, 2006 at 1:24 pm | Permalink

    I followed the instructions above. And obex method works fine until i try to transfer a file to the bluetooth device (sony ericsson K750i).

    The error messages tells me that theres not enough free space on the receiver (I know theres about 1Gb free, Nautilus says 0byes free).

    Someone know how to fix this?

  13. Onkar Shinde
    Posted 18 November, 2006 at 10:55 am | Permalink

    For those who are interested, packages are available for edgy, i386. Check Edgy+1 section of

    Hope this helps.