Bug 753617 - Bluetooth file sending (obex push) fails on kernels newer than 2.6.38
Bluetooth file sending (obex push) fails on kernels newer than 2.6.38
Status: CLOSED DUPLICATE of bug 747575
Product: Fedora
Classification: Fedora
Component: bluez (Show other bugs)
rawhide
x86_64 Linux
unspecified Severity high
: ---
: ---
Assigned To: Bastien Nocera
Fedora Extras Quality Assurance
https://fedoraproject.org/wiki/Common...
: CommonBugs
: 727106 747264 757229 806642 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-11-13 14:14 EST by Saurav Sengupta
Modified: 2014-09-13 14:57 EDT (History)
29 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-01-16 12:07:14 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
start browsing bluetooth files (107.74 KB, image/jpeg)
2012-03-02 02:58 EST, Valent Turkovic
no flags Details
download files over bluetooth (157.11 KB, image/jpeg)
2012-03-02 02:59 EST, Valent Turkovic
no flags Details

  None (edit)
Description Saurav Sengupta 2011-11-13 14:14:17 EST
Description of problem:
The Bluetooth userspace utilities do not work properly on kernels newer than
2.6.38. In particular, sending files by Bluetooth from the computer to a remote
device (obex push) fails. The problem occurs on both Fedora 15 with the latest updates and Fedora 16. On Fedora 16, the Bluetooth adaptor is functional
only if the bluez-hid2hci package is installed.

Version-Release number of selected component (if applicable):
4.96-3

How reproducible:
On a Fedora 16 system with the bluez-hid-2hci package installed, turn on
Bluetooth and try to send a file via Bluetooth to a remote device such as a
mobile phone.

Steps to Reproduce:
1. On Fedora 16, if package bluez-hid2hci is not installed, install it.
2. Turn on Bluetooth (system adaptor).
3. Try to send a file to a remote device such as a mobile phone.
  
Actual results:
gnome-blueooth either crashes or fails to send file to remote device.

Expected results:
File gets transferred successfully.

Additional info:
There are various manifestations of this bug on different Linux distributions, including crashing, failing with the error message, "Connection refused" and failing with the error code 111.
Comment 1 Saurav Sengupta 2011-11-13 14:19:11 EST
*** Bug 747264 has been marked as a duplicate of this bug. ***
Comment 2 Adam Williamson 2011-11-17 21:21:57 EST

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 3 Michael Cronenworth 2011-11-18 00:03:17 EST
I'm not so sure it's the kernel. I could receive files on Fedora 15 (3.0 kernel) just fine. On F16 it fails to send, receive, or browse. Pairing works fine, but repairing doesn't fix anything. It fails with SELinux enabled or in permissive mode.

I see this in my /var/log/messages after trying to send a file.

Nov 17 22:45:04 mcronenworth obex-client[441]: obex-client daemon 0.42
Nov 17 22:45:04 mcronenworth bluetoothd[976]: Mode session 0x7f8c953c4840 with :1.470 activated
Nov 17 22:45:04 mcronenworth bluetoothd[976]: bluetoothd[976]: Mode session 0x7f8c953c4840 with :1.470 activated
Nov 17 22:45:17 mcronenworth obex-client[441]: Transfer(0xf9e630) Error: Unknown response
Nov 17 22:45:17 mcronenworth dbus[1100]: [system] Rejected send message, 2 matched rules; type="method_return", sender=":1.1" (uid=0 pid=976 comm="/usr/sbin/bluetoothd -n ") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.470" (uid=502 pid=441 comm="/usr/libexec/obex-client ")
Nov 17 22:45:17 mcronenworth dbus-daemon[1100]: dbus[1100]: [system] Rejected send message, 2 matched rules; type="method_return", sender=":1.1" (uid=0 pid=976 comm="/usr/sbin/bluetoothd -n ") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.470" (uid=502 pid=441 comm="/usr/libexec/obex-client ")
Comment 4 Michael Cronenworth 2011-11-18 00:49:21 EST
Installing bluez-hid2hci does allow browsing to work, but file transfers (to or from) do not work.
Comment 5 Saurav Sengupta 2011-11-18 05:38:33 EST
(In reply to comment #3)
> I'm not so sure it's the kernel. I could receive files on Fedora 15 (3.0
> kernel) just fine. On F16 it fails to send, receive, or browse. Pairing works
> fine, but repairing doesn't fix anything. It fails with SELinux enabled or in
> permissive mode.
> 
> I see this in my /var/log/messages after trying to send a file.
> 
> Nov 17 22:45:04 mcronenworth obex-client[441]: obex-client daemon 0.42
> Nov 17 22:45:04 mcronenworth bluetoothd[976]: Mode session 0x7f8c953c4840 with
> :1.470 activated
> Nov 17 22:45:04 mcronenworth bluetoothd[976]: bluetoothd[976]: Mode session
> 0x7f8c953c4840 with :1.470 activated
> Nov 17 22:45:17 mcronenworth obex-client[441]: Transfer(0xf9e630) Error:
> Unknown response
> Nov 17 22:45:17 mcronenworth dbus[1100]: [system] Rejected send message, 2
> matched rules; type="method_return", sender=":1.1" (uid=0 pid=976
> comm="/usr/sbin/bluetoothd -n ") interface="(unset)" member="(unset)" error
> name="(unset)" requested_reply="0" destination=":1.470" (uid=502 pid=441
> comm="/usr/libexec/obex-client ")
> Nov 17 22:45:17 mcronenworth dbus-daemon[1100]: dbus[1100]: [system] Rejected
> send message, 2 matched rules; type="method_return", sender=":1.1" (uid=0
> pid=976 comm="/usr/sbin/bluetoothd -n ") interface="(unset)" member="(unset)"
> error name="(unset)" requested_reply="0" destination=":1.470" (uid=502 pid=441
> comm="/usr/libexec/obex-client ")

In my case I could not send files from F15 either when I had installed all updates. My hcidump output (sorry, I do not have it right now) said that the rejection (which you have mentioned) was due to an authentication failure. Other error messages elsewhere also hint at being unable to find the OBEX transfer service on the phone.
Comment 6 Saurav Sengupta 2011-11-18 05:45:16 EST
To all concerned: -

Please do not consider the issue of being unable to receive files via Bluetooth to be part of this bug. It is because Fedora 16, for example, does not have the gnome-user-share (Personal File Sharing) package installed in GNOME by default. However, gnome-user-share now depends on httpd on Fedora so it becomes imperative to install httpd (Apache Web server) even if we do not need the network sharing facility. gnome-user-share can work just fine without httpd. Setting up BlueDevil to receive files on KDE works correctly, and gnome-user-share does not depend on httpd on Ubuntu now and is also installed by default there so setting it up to receive files also works. This should be filed as a separate bug. The main problem here is that sending files (OBEX push) does not work.
Comment 7 Saurav Sengupta 2011-11-18 05:52:40 EST
Browsing, including copying to and from, through obexfs (package) works but may require several tries to connect. In particular, it only seems to work for paired devices and the computer may need to be restarted after pairing, so the whole set-up is rather more of a headache than a workable solution, although right now it is the only workaround I know of.
Comment 8 Michael Cronenworth 2011-11-18 09:48:48 EST
Saurav,

My F15 boxes (now all F16) had gnome-user-share installed and all could transfer Bluetooth files just fine. There is a dependency problem if bluez-hid2hci is required. gnome-user-share should Requires it.

After attempting file browsing again today, I was able to transmit to/from and delete files on my mobile phone through the browsing window. I was also able to transmit to my phone using nautilus Send To and receive files from the phone. I'm not sure why the first attempts failed, but now everything seems to be working.

IMO this looks like a dep issue and should be assigned to gnome-user-share.
Comment 9 Japplo 2011-11-18 10:12:51 EST
Saurav,
I've exactly the same problem. If I start F15 with 2.6.38-8, bluetooth filetransfer works without problems. But if I use a Kernel > 2.6.38-8, it doesn't work. Maybe not all bluetooth adapters are affected.

# lsusb
Bus 001 Device 004: ID 0a5c:217f Broadcom Corp. Bluetooth Controller

http://www.thinkwiki.org/wiki/ThinkPad_Bluetooth_Daughter_Card_with_Enhanced_Data_Rate_%28BDC-2%29
Comment 10 Saurav Sengupta 2011-11-18 15:25:22 EST
(In reply to comment #8)
> Saurav,
> 
> My F15 boxes (now all F16) had gnome-user-share installed and all could
> transfer Bluetooth files just fine. There is a dependency problem if
> bluez-hid2hci is required. gnome-user-share should Requires it.
> 
> After attempting file browsing again today, I was able to transmit to/from and
> delete files on my mobile phone through the browsing window. I was also able to
> transmit to my phone using nautilus Send To and receive files from the phone.
> I'm not sure why the first attempts failed, but now everything seems to be
> working.
> 
> IMO this looks like a dep issue and should be assigned to gnome-user-share.

Do you mean that installing gnome-user-share allowed you to send files from F16 to a remote device?
Comment 11 Michael Cronenworth 2011-11-18 15:35:21 EST
(In reply to comment #10)
> Do you mean that installing gnome-user-share allowed you to send files from F16
> to a remote device?

No. My F15 machines were upgraded to F16 using preupgrade. Those machines already had gnome-user-share installed prior to F16 and they continued to have it installed while on F16. I was only able to send files once I installed bluez-hid2hci.
Comment 12 Chris Murphy 2011-11-26 15:38:17 EST
*** Bug 757229 has been marked as a duplicate of this bug. ***
Comment 13 Steve 2011-12-04 20:33:02 EST
I have the same problem.  Whenever I try to browse a paired device, I get an error message saying:



Error browsing device

The request device cannot be browsed, error is 'Error: Error invoking GnomeBluetoothApplet.browse_address_finish: Connection refused'
Comment 14 Alec Leamas 2011-12-06 14:37:19 EST
See also bug 733847 which might be a dup. In this,  it's hw dependent, using another dongle might help
Comment 15 Saurav Sengupta 2012-02-03 02:44:35 EST
The file sending process randomly succeeds after several tries, sometimes, especially if the devices are paired. But mostly, it fails. Also, this problem does not occur, at least in my case, when sending to a Nokia smartphone, but for all other devices, it fails.

@Alec: Bug 733847 is indeed a duplicate of this one, but using a laptop with an in-built Bluetooth adaptor, I am unwilling to use an external dongle instead. The problem did not occur in previous kernels (or Bluetooth stack versions), which clearly indicates that this is a regression.
Comment 16 Japplo 2012-02-12 18:06:16 EST
Hi guys, I've found a workaround using obexfs :-)
First, mount the bluetooth device like that:

yum install obexfs
mkdir /tmp/test
obexfs -b 12:34:56:78:90:12 /tmp/test

After this, I can send and receive files without problems! yes yes yes
Comment 17 Gökhan Sever 2012-02-13 12:58:04 EST
Hi Japplo,

I can get my N900 mount following your method. I can see files, but copying doesn't move even a bit of data, and end up crashing file manager.
Comment 18 Luiz Augusto von Dentz 2012-02-15 08:29:51 EST
This is a regression in Linux Kernel, for more information check this thread:

http://thread.gmane.org/gmane.linux.bluez.kernel/15447/focus=20013

Any 2.1 device (with Secure Simple Pairing enabled) will fail to connect if sdp is also connected, apparently obexfs doesn't do sdp thats why it works, the workaround is to disable spp by doing: sudo hcidump hci0 sspmode 0
Comment 19 Saurav Sengupta 2012-02-15 13:19:37 EST
The command is hciconfig instead of hcidump. Does anyone know how to make the workaround persist across Bluetooth on/off and system reboots?
Comment 20 Gökhan Sever 2012-02-15 15:50:04 EST
Thanks Saurav. Changing the command as you suggested mounts my N900 properly. With obexfs solution, I wasn't able to transfer files from/to the device, now I can transfer successfully.
Comment 21 Valent Turkovic 2012-03-02 02:41:59 EST
I'm confused, so does bluetooth file transfer work in Fedora 16 or not?
Comment 22 Valent Turkovic 2012-03-02 02:58:34 EST
Created attachment 567002 [details]
start browsing bluetooth files

start browsing bluetooth files
Comment 23 Valent Turkovic 2012-03-02 02:59:17 EST
Created attachment 567003 [details]
download files over bluetooth

download files over bluetooth
Comment 24 Valent Turkovic 2012-03-02 02:59:31 EST
Ok, I see now, what confused me what that for some of you mounting and downloading images FROM bluetooth devices also fails.

Downloading files FROM mobile devices works perfectly in Fedora 16, as you can see in my attached screenshots.

Sending files TO mobile devices via bluetooth fails for me also even with latest kernel and all updates.

Any news when is this issue scheduled to be fixed? Who needs to fix and what? Is it this responsibility of GNOME Bluetooth devs to make new versions of bluetooth tools that work with new kernel?
Comment 25 Saurav Sengupta 2012-03-02 05:01:51 EST
@Valent: This is not a problem in GNOME. The workaround mentioned in comments 18 and 19 works, but I have been unable to find a way to make the workaround persist across reboots.
Comment 26 Saurav Sengupta 2012-03-31 04:26:59 EDT
The Ubuntu developers seem to have fixed this: https://bugs.launchpad.net/gnome-bluetooth/+bug/872044. Has this been fixed in any kernel or BlueZ update for Fedora 16? If not, can we get an update here as well?
Comment 27 Steven Drinnan 2012-04-28 20:00:04 EDT
Confirmed that work around works for file sharing but internet does not, 

Ubuntu have fixed this (both file and internet) 12.04 and they appear to use the same method and tools as fedora. When will this be fixed?
Comment 28 Adam Williamson 2012-05-08 21:05:08 EDT
what do you mean by 'internet does not'? Are you talking about bluetooth tethering? that's nothing to do with this bug, I don't think. tethering is a completely different path from file transfer.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 29 Peter Stidl 2012-05-11 09:21:03 EDT
(In reply to comment #24)
> Ok, I see now, what confused me what that for some of you mounting and
> downloading images FROM bluetooth devices also fails.
> 
> Downloading files FROM mobile devices works perfectly in Fedora 16, as you can
> see in my attached screenshots.
> 
> Sending files TO mobile devices via bluetooth fails for me also even with
> latest kernel and all updates.
> 
> Any news when is this issue scheduled to be fixed? Who needs to fix and what?
> Is it this responsibility of GNOME Bluetooth devs to make new versions of
> bluetooth tools that work with new kernel?

Sorry, but not for me with a Samsung Galaxy Gio GT-S5660. After all new updates everything looks fine in Gnome and KDE, all drivers are loaded, devices seen, reaction seen in bluetooth-windows and icons, but no filetransfer or connection is happend. I´m using a Acer Aspire 7750G and with the VMware original aspire-clone VM bluetoth is working perfect but not with original fedora 16.
:-((
Comment 30 colesen 2012-05-28 16:16:15 EDT
I used to be able to send files from my Dell laptop running Fedora16+KDE to my mobile phone by simply selecting "Send via Bluetooth" from the 3rd mouse button popup menu with the mouse on the file to send in Dolphin but then the other day that stopped working.

The message in /var/log/messages is
May 28 20:56:57 xxxxxx dbus-daemon[1299]: dbus[1299]: [system] Rejected send message, 2 matched rules; type="method_return", sender=":1.0" (uid=0 pid=1205 comm="/usr/sbin/bluetoothd -n ") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.99" (uid=1000 pid=18765 comm="/usr/libexec/obex-client ")
May 28 20:56:57 xxxxxx dbus[1299]: [system] Rejected send message, 2 matched rules; type="method_return", sender=":1.0" (uid=0 pid=1205 comm="/usr/sbin/bluetoothd -n ") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.99" (uid=1000 pid=18765 comm="/usr/libexec/obex-client ")

Looking at the date of the last such received file on my phone I can see that the transfer was working May 16 i.e. 12 days ago. Looking among the automatic updates since that time I see that this package
obexd-0.42-1.fc16.i686.rpm
was updated May 19 to
obexd-0.44-1.fc16.i686.rpm
for "fix segfault while sending (#766314)"

So I then tried with undoing that update by force removing that package using
sudo rpm -e --nodeps obexd-0.44-1.fc16.i686.rpm
and instead installing the previous package which is part of the original Fedora 16 release using
sudo rpm --install obexd-0.42-1.fc16.i686.rpm
and with that the file transfer again works.
Comment 31 colesen 2012-06-13 16:49:56 EDT
Comment #30 cont'd... I just upgraded to F17+KDE
incl. latest packages obexd-0.44-1.fc17.i686
and kernel-PAE-3.4.0-1.fc17.i686
and send file from KDE using bluetooth still does not work.
Logging in as root to KDE makes no difference.
If the file is small then a confirmation popup shows on the phone 
and if accepted then the file name briefly shows in the bluetooth directory on the phone.
If the file is large then the confirmation prompt does not show.
The phone in unpaired mode shows switching temporarily to paired mode
irrespective of small or large file.

However instead using the following commandline script the file transfer does work
#!/bin/sh
#
# send file using bluetooth
# args: [ bdaddr [ channel file ] ]
# <>                        : get the <bdaddr>
# <bdaddr>                  : get the <channel>
# <bdaddr> <channel> <file> : send the <file>
#
case "$#" in
0) hcitool scan ;; # target must be discoverable 
1) sdptool search --bdaddr $1 OPUSH ;;
3) obexftp --nopath --noconn --uuid none --bluetooth $1 --channel $2 --put $3 ;;
esac
Comment 32 Valent Turkovic 2012-09-07 09:07:58 EDT
Is bluetooth completely messed up? Will this be fixed anytime soon? What is going on in kernel team that maintains this code?
Comment 33 Martin 2012-11-22 13:18:52 EST
Are you still have this problem in updated Fedora 16?

And please, could you try reproduce this bug in Fedora 18 Beta RC1?
http://dl.fedoraproject.org/pub/alt/stage/18-Beta-RC1/
Comment 34 Martin 2012-11-22 13:20:05 EST
*** Bug 537720 has been marked as a duplicate of this bug. ***
Comment 35 Martin 2012-11-22 13:22:37 EST
*** Bug 735319 has been marked as a duplicate of this bug. ***
Comment 36 Martin 2012-11-22 13:28:16 EST
*** Bug 806642 has been marked as a duplicate of this bug. ***
Comment 37 Martin 2012-11-22 13:42:36 EST
*** Bug 727106 has been marked as a duplicate of this bug. ***
Comment 38 Fedora End Of Life 2013-01-16 07:03:40 EST
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 39 Martin 2013-01-16 11:43:35 EST
Moving this bug to Rawhide version as this bug occurs in F16 to F18 releases and it's very likely to hit also F19.
Comment 40 Martin 2013-01-16 12:07:14 EST
Obex push has been fixed in F18, but not in F17. It seems to be same bug as #747575.

*** This bug has been marked as a duplicate of bug 747575 ***

Note You need to log in before you can comment on or make changes to this bug.