regression in gvfs to connect/browse using obex

Bug #899858 reported by Rene
302
This bug affects 74 people
Affects Status Importance Assigned to Milestone
OEM Priority Project
Fix Released
High
James M. Leddy
Oneiric
Fix Released
Undecided
James M. Leddy
Precise
Fix Released
High
James M. Leddy
gvfs
Expired
Medium
gvfs (Debian)
Fix Released
Unknown
gvfs (Ubuntu)
Fix Released
High
Sebastien Bacher
Oneiric
Fix Released
Undecided
Mathieu Trudel-Lapierre
Precise
Fix Released
High
Sebastien Bacher

Bug Description

SRU form for Oneiric

[Impact]
This bug prevents anyone from browsing their phone over bluetooth in Oneiric. This is a regression because people were able to browse their phones in Natty and earlier.

[Development Fix]
Build libgvfsdaemon as a static rather than shared library.

[Stable Fix]
Same as development fix.

[Test Case]
Use Gvfs-mount to mount the phone:

$ gvfs-mount obex://[B8:F9:34:44:B4:10]
Error mounting location: Connection refused

[Regression Potential]
Minimal. The fix is the same as Precise, and has been extensively tested there. It has also gone through testing on Oneiric through the process of finding the bug. Additionally, upstream has always statically linked libgvfsdaemon, and we have not seen bug reports there or in other distros for that. Natty and earlier versions of Ubuntu have statically linked libgvfsdaemon and work fine.

[Original bug report]

Action "browse file on devices" from bluetooth gnome applet is not working since upgrade to Oneiric
Using same hardware configuration (PC + cell phone), it was working fine in natty.

after correct pairing of devices (same hardware). The cell phone I connect to is obex capable. it is a Sony Ericsson W20i.

$ gvfs-mount obex://[B8:F9:34:44:B4:10]
Error mounting location: Connection refused
$ obexfs -b B8:F9:34:44:B4:10 m
$ ls m
Phone memory
$

so obexfs is ok, but gvfs-backends has a pb.
After mounting with obexfs, browsing in nautilus is ok.

From the applet if I just try "Send file to device", I also get a "connection refused (111)" message.

On the phone, the connexion is set as "always allow"

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: gvfs-backends 1.10.0-0ubuntu1
ProcVersionSignature: Ubuntu 3.0.0-14.23+kamal~fix~stuck~backlight4-generic 3.0.9
Uname: Linux 3.0.0-14-generic i686
ApportVersion: 1.23-0ubuntu4
Architecture: i386
Date: Sun Dec 4 10:53:24 2011
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release i386 (20111012)
SourcePackage: gvfs
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

Revision history for this message
Rene (g.xrc) wrote :
Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/GNOME. If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

Changed in gvfs (Ubuntu):
importance: Undecided → Low
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gvfs (Ubuntu):
status: New → Confirmed
Revision history for this message
Simone Lussardi (simone-lussardi) wrote :

Same here, please everyone click on this "Bug affects me", because too much time has passed and even Precise still have this bug. As instructed in another hot bug, please keep this bug only to report that Bluetooth devices cannot be browsed.

Refer to this bug as well:
https://bugs.launchpad.net/oem-priority/+bug/879923

tags: added: rls-mgr-p-tracking
summary: - regression in gvfs to connect using obex
+ regression in gvfs to connect/browse using obex
Revision history for this message
Ego (egogratis) wrote :

I tested this in Ubuntu 11.10 and Ubuntu 12.04 and got the same result. Then based on workaround from this bug:

https://bugs.launchpad.net/ubuntu/+source/obexd/+bug/872044

I tested it again. With disabling SSP the device is shown in Nautilus but browsing does not work but with disabled SSP there is one difference.

$ gvfs-mount obex://[B8:F9:34:44:B4:10]
Error mounting location: Connection refused

This problem is gone but there is another one:

Error mounting location: DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

Using obexfs and mounting the device enables browsing the device with Nautilus!

Revision history for this message
James M. Leddy (jm-leddy) wrote :

I'm not actually positive it's a regression in gvfs. I've compiled the natty version of gvfs, and that didn't help. In both cases I get:

gvfs-mount obex://[40:89:4E:71:40:E3]
Error mounting location: Connection to the device lost

The command takes a few seconds to complete, which makes me wonder if there is a timeout. When using the bluetooth applet to browse, I get the same DBus error as in comment #5.

tags: added: bluetooth
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

As another piece of the puzzle, when I try this on my system with my own HTC Glacier phone:

1- This doesn't work at all unless I use the Bluetooth File Transfer app. By itself, bluez on android doesn't appear to support Obex FTP (or it's blocked)

2- With the app running an FTP enabled (once the connection is allowed in):
Feb 22 13:17:15 gaea obex-data-server: sdp_extract_seqtype: Unexpected end of packet

I've done all this just with the gvfs-mount command, and clicking on the added item in Nautilus (which still triggers, in time, a DBus timeout error message).

This seems to indicate to me that there may be further issues at the obex-data-server level that will need to be tackled for browsing to work properly.

Changed in obex-data-server (Ubuntu):
status: New → Confirmed
importance: Undecided → Low
Revision history for this message
James M. Leddy (jm-leddy) wrote :

I'm still investigating this on a motorola RAZR V3XX. I have the same behavior as comment #0, except I don't get a connection refused. Instead I get our favorite:

Error mounting location: DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

In both cases it looks like it acutally went through on an obex level, since I get in my gnome-shell output:

** Message: has_config_widget 00:1D:BE:A4:8F:49 DialupNetworking
** Message: has_config_widget 00:1D:BE:A4:8F:49 OBEXObjectPush
** Message: has_config_widget 00:1D:BE:A4:8F:49 OBEXFileTransfer
** Message: has_config_widget 00:1D:BE:A4:8F:49 Headset_-_AG
** Message: has_config_widget 00:1D:BE:A4:8F:49 HandsfreeAudioGateway
** Message: has_config_widget 00:1D:BE:A4:8F:49 DialupNetworking
** Message: has_config_widget 00:1D:BE:A4:8F:49 OBEXObjectPush
** Message: has_config_widget 00:1D:BE:A4:8F:49 OBEXFileTransfer
** Message: has_config_widget 00:1D:BE:A4:8F:49 Headset_-_AG
** Message: has_config_widget 00:1D:BE:A4:8F:49 HandsfreeAudioGateway
** Message: Default Bluetooth adapter is powered

Also I've built obexd and obex-data-server for natty on oneiric and they haven't helped. I don't believe anything in the obex stack is at fault here, but whatever is supposed to be handling the dbus messages is.

Revision history for this message
James M. Leddy (jm-leddy) wrote :

Okay, take it back, this is definitely a gvfs bug. I must have only installed gvfs package from the previous comment and forgot to install all the dependent libraries. With a version of gvfs from natty (1.8.0-0ubuntu2) compiled for Oneiric, I can't reproduce this bug.

I'm bisecting now.

no longer affects: obex-data-server (Ubuntu)
Revision history for this message
James M. Leddy (jm-leddy) wrote :

The first bad version is gvfs-1.8.0-1. This regression is caused by 05_shared_libdaemon.patch. It isn't exactly clear to me why this is, but if I take out the patch and build with the libgvfscommon0 package as was done in gvfs-1.8.0-0ubuntu1 and earlier, I can successfully mount the phone.

I have a patch that I will upload shortly.

Revision history for this message
James M. Leddy (jm-leddy) wrote :

This reverts 05_shared_libdaemon.patch

Martin Pitt (pitti)
tags: added: rls-p-tracking
removed: rls-mgr-p-tracking
Changed in oem-priority:
assignee: nobody → James M. Leddy (jm-leddy)
importance: Undecided → High
status: New → Confirmed
Changed in gvfs (Ubuntu):
importance: Low → High
Revision history for this message
Ego (egogratis) wrote :

Fantastic. Cant' wait to try it out!

Changed in oem-priority:
status: Confirmed → In Progress
Changed in gvfs (Ubuntu):
status: Confirmed → In Progress
Changed in gvfs (Ubuntu):
milestone: none → oneiric-updates
milestone: oneiric-updates → none
status: In Progress → New
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gvfs (Ubuntu Oneiric):
status: New → Confirmed
Changed in gvfs (Ubuntu):
status: New → Confirmed
Revision history for this message
Martin Pitt (pitti) wrote :

This was introduced years ago in

gvfs (1.4.1-5+gdu) experimental; urgency=low

  * 05_shared_libdaemon.patch:
    + Put the common code for all gvfsd-* in a private library in
      /usr/lib/gvfs/libgvfsdaemon.so. This reduces binary sizes and
      memory overhead caused by the multiple running daemons.
 [...]

 -- Josselin Mouette <email address hidden> Mon, 16 Nov 2009 18:28:56 +0100

So we don't want to regress this. We should fix the patch instead.

Changed in gvfs (Debian):
status: Unknown → New
Revision history for this message
James M. Leddy (jm-leddy) wrote :

I've created a more minimal patch that leaves 05_shared_libdaemon.patch in tact while still fixing the problem. The problem is having libdaemon as a shared library causes dbus timeouts. Please let me know what you think.

I will upload a patch against 12.04 later today.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks James, are you sure it's not a red herring? I see no reason why that change should fix it in theory, I also built without 05_shared_libdaemon.patch here and I still get the connection refused issue, obexfs is also not behaving in a consistant way for me... could be simply a random timing issue and depending of the luck you get when trying?

Revision history for this message
James M. Leddy (jm-leddy) wrote :

I think the fix to that is an upgraded obexd as in bug 879923. This bug was opened from that bug to deal specifically with browsing.

The patch that I've posted fixes :

---
Could not display "obex://[(BT_address)]/".

Error: DBus error org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Please select another viewer and try again.
---

I think combining the fixes from 879923 as well as pulling the 05_shared_libdaemon.patch will allow devices that use SSP to be browsed. I know that 05_shared_libdaemon.patch as in gvfs in 11.10 breaks browsing for some (and possibly all) devices that used to work on 11.04.

https://bugs.launchpad.net/oem-priority/+bug/879923/comments/41

Revision history for this message
James M. Leddy (jm-leddy) wrote :

In order to test this I connected to my Nokia N9. At first, I got a "Connection refused" message, but then after issuing "sudo hciconfig hci0 sspmode 0" on the command line, I was able to browse my phone using gvfs-1.10.0-0ubuntu2+jml3. I suspect using gvfs-1.10.0-0ubuntu2 would result in dbus timeout.

Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "gvfs_obex_browse_fix_minimal.oneiric.patch" of this bug report has been identified as being a patch in the form of a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags: added: patch
Revision history for this message
Sebastien Bacher (seb128) wrote :

thanks, why do you need that hciconfig call? what bug is in precise? here I get the connection refused error on gvfs-mount with or without the library patch in gvfs, obexfs mounted my phone fine once on friday but seems to return without doing anything since, not sure what I changed though...

Revision history for this message
Ego (egogratis) wrote :
Revision history for this message
Anomaly (bertrand3000) wrote :

With the latest kernel update on Precise that fixes the "Send file to device" problem, I can confirm that "Browing file on device" still does not work correctly.

Bluetooth device is Samsung B2710 (with Samsung proprietary OS).

On Natty (correct behavior) : Browsing File on Device will pop up a connection confirmation on the phone ; when "yes" is answered, Nautilus will open with the files on the phone.

On Precise with latest kernel update : Browsing File on Device will pop up a connection confirmation on the phone ; when "yes" is answered, nothing seems to happen. If you open Nautilus manually, you notice that the phone has been mounted, but trying to access it gives the error message "The name was not provided by any .service file" or "Message did not recieve a reply" (the latter being followed by an automatic unmount).

On /var/log/syslog the following line is added on each attempt : "obex-data-server: sdp_extract_seqtype: Unexpected end of packet".

tags: removed: rls-p-tracking
Revision history for this message
James M. Leddy (jm-leddy) wrote :

I'm attaching the binaries from Oneiric for testing. These were built with gvfs_obex_browse_fix_minimal.oneiric.patch . Please keep in mind these are for testing purposes only and totally unsupported and may be overwritten by a gvfs update.

Revision history for this message
James M. Leddy (jm-leddy) wrote :
Revision history for this message
James M. Leddy (jm-leddy) wrote :
Revision history for this message
James M. Leddy (jm-leddy) wrote :
Revision history for this message
James M. Leddy (jm-leddy) wrote :
Revision history for this message
James M. Leddy (jm-leddy) wrote :
Revision history for this message
Ego (egogratis) wrote :

Any chance for either:

1.) Oneiric (32bit)
2.) Precise (64bit)

Revision history for this message
James M. Leddy (jm-leddy) wrote :

Ego, I have the precise build now, let me upload it. Again, these packages are for testing purposes only.

Revision history for this message
James M. Leddy (jm-leddy) wrote :
Revision history for this message
James M. Leddy (jm-leddy) wrote :
Revision history for this message
James M. Leddy (jm-leddy) wrote :
Revision history for this message
James M. Leddy (jm-leddy) wrote :
Revision history for this message
James M. Leddy (jm-leddy) wrote :
Revision history for this message
James M. Leddy (jm-leddy) wrote :
Revision history for this message
James M. Leddy (jm-leddy) wrote :
Revision history for this message
James M. Leddy (jm-leddy) wrote :

By the way, the precise builds have only been compile tested. Additionally, you should not have to do this, but just in case you get a "permission denied" type message : "sudo hciconfig hci0 sspmode 0"

Revision history for this message
Ego (egogratis) wrote :

"sudo hciconfig hci0 sspmode 0"

This was not needed (on fully updated Precise).

"gvfs-bin_1.11.4-0ubuntu2+jml1_amd64.deb"

I assumed this package was uploaded twice and just used the first one. Installation of packages went without any problems and then i rebooted the PC.

I tested all 3 GUI options:
-Browse Files on Device ...
-Browse files ...
-Bluetooth Settings ... -> Devices -> Browse files

They all worked the same way and opened up Nautilus with mounted device in root folder of device.

I tested:
-Copy to Desktop
-Drag & Drop to Desktop
-Move to Desktop
-Copy from Desktop and paste to folder on device
-Drag & Drop from Desktop to folder on device
-Cut from Desktop and paste to folder on device

Everything worked fine and i had to confirm every step on the device. When moving files from Device -> Desktop i was asked to allow deleting file from device after the move was made. Basically everything works fine.

Then i tested opening files on the device. Pictures, PDF and text files everything opened normally on Ubuntu. The only exception i found was .odf file. Probably LibreOffice related BUG.

Problems i noticed was:

1.) If you want to paste file to device and wait too long "Not authorized" error occurs. I think this is normal behavior but maybe interval should last few seconds longer.

2.) If file on device is of the same name as file on the location it will be sent this will fail and "Another operation in progress" error will occur and nothing i mentioned above will work after that. Solution is to unmount the device in Nautilus and start again.

3.) If opening file directly from device in Gedit this does work but saving the file will fail. This is just something i noticed and it's probably Gedit related.

Basically everything works fine and i hope to see this fix in regular updates soon! Fantastic work and thanks!

tags: added: rls-mgr-p-tracking
tags: added: precise
Revision history for this message
Sebastien Bacher (seb128) wrote :

James, thanks for your work, could you use a ppa rather than add debs to the bug though?

Revision history for this message
Sebastien Bacher (seb128) wrote :

Btw as said before that fix is wrong, you are playing on race, avoiding linker resolution might be enough to have a correct timing but it will not work reliably and might break it for other people, you are just changing the timing for something timing sensitive there...

Revision history for this message
James M. Leddy (jm-leddy) wrote :

I was going to use a ppa, but since I'm still figuring out launchpad I couldn't get it to accept the changes file I was using. I think I have figured out the problem and I'll use that in a future.

The fix is right, because it fixes the problem, and so far we can consistently reproduce the problem on any version of gvfs that has 05_shared_libdaemon.patch . We have not seen the problem on any package without the patch, and removing the patch fixes the problem, so there is a strong correlation there. Any explanation as to why the patch breaks things or what other issues might crop up from statically linking is speculation at this point, no one has root caused the problem. Though I have no reason to suspect statically linking again will produce any problems, since upstream does it and we did it in 11.04 and previous releases. We are currently looking in to the root cause.

A summary of what we know so far because this report is getting long: In 2009 the patch was introduced in version 1.4.1-5+gdu, but only in Debian sid. I haven't tested but I suspect that version also suffers from the regression. The patch was not submitted upstream, and the upstream version was never affected. In Ubuntu, with version gvfs-1.8.0-1 (which I have tested) we rebased to the branch that includes the patch. The Ubuntu 11.04 release was able to browse using gvfs. The latest version there is 1.8.0-0ubuntu3. In 11.10, we hit this regression where you can't browse obex, as result of the rebase to the sid branch. I've raised the bug in Debian as well.

To be sure, the savings we get from shared objects is pretty large. Here is the dir size statically linked:
# du -sh /usr/lib/gvfs
3.7M /usr/lib/gvfs

and shared:
 du -sh /usr/lib/gvfs
1.6M /usr/lib/gvfs

As I said earlier we're currently figuring out the root cause.

Changed in gvfs:
importance: Unknown → Medium
status: Unknown → New
Revision history for this message
Eric Miao (eric.y.miao) wrote :

This is really weird. The problem is with gvfsd-obexftp not able to receive the method call return from GVFS Daemon (gvfsd) after sent registerMount. The mount is actually done, however, with the method call return reply is lost on dbus, it never reaches back to gvfsd-obexftp. This does not happen with other protocols like sftp and smb. So far I do not see a direct connection that this is related to some part of the code being made as a shared object.

Revision history for this message
Eric Miao (eric.y.miao) wrote :

OK, here's the theory of root cause, checking the source code, there is a private implementation of dbus-glib in daemon/dbus-gmain.c. The API is a redundant of the system wide libdbus-glib. While static linked, the private implementation will be used, however, when dynamically linked, the system wide libdbus-glib has the priority over. And this happens for gvfsd-obexftp, as it seems to be the only one using this API. Before this can be fully fixed in upstream, a temporary workaround of static linking against libdaemon for gvfsd-obexftp is a rationale one.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks for tracking that issue, the recent comments start making sense, do you suggests it's a bug in libdbus-glib then which is not present in the gvfs implementation? can you reproduce the bug enough to verify that staticly linking gvfsd-obexftp is enough to workaround the issue?

Revision history for this message
Eric Miao (eric.y.miao) wrote :

I did some more testings:

1. checked the source, there are two libdbus-glib functions locally implemented in daemon/dbus-gmain.c, which are

  - dbus_connection_setup_with_g_main
  - dbus_server_setup_with_g_main

  as talked with seb128 and pitti, I did a trial building after renaming these functions to local_*. gvfs-mount exited immediately with the error message below:

  $ gvfs-mount obex://[00:1f:5c:01:ac:64]
  Error mounting location: DBus error org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)

  Note this happened almost immediately, and followed by a crash report of gvfsd-obexftp, title of which being:
  "gvfsd-obexftp crashed with SIGSEGV in _dbus_message_new_from_gerror()

2. Confirmed that making libgvfsdaemon statically linked is enough to solve this issue. Attached is the minimal change I used.

Revision history for this message
Eric Miao (eric.y.miao) wrote :

Checked with daemon/Makefile.am, obexftp is special because of a different linkage below:

  gvfsd_obexftp_LDADD = $(OBEXFTP_LIBS) $(EXPAT_LIBS) $(libraries)
  if USE_HAL
  gvfsd_obexftp_LDADD += $(HAL_LIBS)
  endif

After configuration, OBEXFTP_LIBS is

  OBEXFTP_LIBS = -ldbus-glib-1 -ldbus-1 -lpthread -lrt -lgobject-2.0 -lglib-2.0 -lbluetooth

So apparently libdbus-glib-1 has the priority to be linked first, and all invocations of the dbus-glib functions call into the system wide library firstly.

libgvfsdaemon.so doesn't not link to dbus-glib-1, but links to the local dbus-gmain.c, which means some other calls into libgvfsdaemon.so could end up calling the functions in dbus-gmain.c, which creates a more complicated mixture.

At this moment, and considering the upstream is working on a solution, I believe a quicker way would be to make libgvfsdaemon statically linked.

Martin Pitt (pitti)
Changed in gvfs (Ubuntu Precise):
assignee: nobody → Sebastien Bacher (seb128)
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gvfs - 1.12.0-0ubuntu3

---------------
gvfs (1.12.0-0ubuntu3) precise; urgency=low

  * 05_shared_lib: don't turn libgvfsdaemon into a static library,
    gvfs redefine some dbus-glib functions and having a library
    leads to load the wrong symbols, should fix the obex mount not
    working, thanks Eric Miao (lp: #899858)
 -- Sebastien Bacher <email address hidden> Mon, 02 Apr 2012 23:19:17 +0200

Changed in gvfs (Ubuntu Precise):
status: Confirmed → Fix Released
Revision history for this message
Eric Miao (eric.y.miao) wrote :

Confirmed that gvfs 1.12.0-0ubuntu3 fixed this issue for Precise. Thanks seb128!

For Oneiric, the latest gvfs version seems to be 1.10.0-0ubuntu1, where the fix doesn't seem to be there yet.

Revision history for this message
Rafael Belmonte (eaglescreen) wrote :

Would it be possible to forward this fix to upstream?
This is reported in gnome-bugs #672114 .
That would make easier to propagate the fix to the rest of GNU/Linux distributions, which are also affected.

Revision history for this message
James M. Leddy (jm-leddy) wrote :

Hello ubuntu-sru. Please consider this for inclusion in Oneiric.

description: updated
Changed in gvfs:
status: New → Confirmed
Changed in gvfs (Debian):
status: New → Incomplete
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Preparing the upload to oneiric-proposed for SRU of Seb's changes.

Changed in gvfs (Ubuntu Oneiric):
status: Confirmed → In Progress
assignee: nobody → Mathieu Trudel-Lapierre (mathieu-tl)
Revision history for this message
James M. Leddy (jm-leddy) wrote :

Thanks Mathieu. I look forward to testing it!

Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

Just uploaded to the oneiric-proposed queue, waiting to be accepted by the SRU team.

Revision history for this message
Martin Pitt (pitti) wrote : Please test proposed package

Hello Rene, or anyone else affected,

Accepted gvfs into oneiric-proposed. The package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in gvfs (Ubuntu Oneiric):
status: In Progress → Fix Committed
tags: added: verification-needed
Revision history for this message
Kent Baxley (kentb) wrote :

It looks like I can browse my phone and send files to it now, once I get everything set up.

Revision history for this message
Kent Baxley (kentb) wrote :

Someone else also needs to verify this as well as the behavior with my phone appears to be spotty.

Changed in oem-priority:
status: In Progress → Fix Committed
Revision history for this message
James M. Leddy (jm-leddy) wrote :

The package in oneiric proposed works great. Thanks Mathieu!

tags: added: verification-done
removed: verification-needed
Revision history for this message
Mikael Strom (mikael-sesamiq) wrote :

This worked for me as well, thanks a lot for your effort!

Receiving files as well as browsing device in nautilus via "obex://[xx:xx:xx:xx:xx:xx]/" works on Oneiric-x86 on MacBookPro 5,2.

Perhaps the wrong forum, but FYI:
- bluetooth-applet crash consistently when used to start browsing device.
- Send files does not work; fails with the message "Did not receive a reply. Possible causes..."

/Mike

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package gvfs - 1.10.0-0ubuntu1.1

---------------
gvfs (1.10.0-0ubuntu1.1) oneiric-proposed; urgency=low

  [ Sebastien Bacher ]
  * 05_shared_lib: don't turn libgvfsdaemon into a static library,
    gvfs redefine some dbus-glib functions and having a library
    leads to load the wrong symbols, should fix the obex mount not
    working, thanks Eric Miao (lp: #899858)
 -- James M Leddy <email address hidden> Mon, 16 Apr 2012 17:23:08 -0400

Changed in gvfs (Ubuntu Oneiric):
status: Fix Committed → Fix Released
Revision history for this message
James M. Leddy (jm-leddy) wrote :

Mikael,

Thanks for that feedback. The bluetooth-applet bug is bug 880079. The send-files problem is new, it should be documented as a separate bug.

Changed in oem-priority:
status: Fix Committed → Fix Released
Revision history for this message
rpr nospam (rpr-nospam) wrote :

On Ubuntu 12.04 x64 with Linux 3.2.0-36-generic I still cannot browse a phone over bluetooth.

$ lsusb | grep -i bluetooth
Bus 007 Device 002: ID 2001:f111 D-Link Corp. DBT-122 Bluetooth adapter

$ hcitool scan
Scanning ...
 00:1F:5D:C0:C8:08 Nokia 3120 classic

$ gvfs-mount obex://[00:1F:5D:C0:C8:08]
Error mounting location: Connection to the device lost

After the last command the following error is logged to /var/log/syslog:

Jan 19 22:42:01 mypc obex-data-server: sdp_extract_seqtype: Unexpected end of packet

On a MS Windows XP I can browse the phone over bluetooth and copy files from/to its memory.

Revision history for this message
rpr nospam (rpr-nospam) wrote :

Forgot to mention the versions:

gvfs 1.12.1-0ubuntu1.1
libmulticobex1 0.23-1build3cable OBEX library
libobexftp0 0.23-1build3transfer library
libopenobex1 1.5-2build1
obex-data-server 0.4.6-0ubuntu1
obexd-client 0.44-0ubuntu1
obexfs 0.11-1capable devices

Revision history for this message
Rafael Belmonte (eaglescreen) wrote :

Hello, I have found a very similar bug to this in Ubuntu 12.10 and 'raring'.
I reported it Bug #1103253 because I do not know if it is a duplicated if this one.

Changed in gvfs (Debian):
status: Incomplete → Fix Released
Revision history for this message
Steve White (stevan-white) wrote :

I too am having similar experiences with 12.10. It looks like
   https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/1076835

Also, I'm using the Ubuntu crash reporter thing report a crash that just happened.
The report that the reporter says it will send, says there is an existing report
   https://bugs.launchpad.net/bugs/1063599
but... I tried that URL and I don't seem to have access to it. What gives?

Changed in gvfs:
status: Confirmed → Expired
To post a comment you must log in.