*** Bug 747264 has been marked as a duplicate of this bug. ***

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

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 ")

Installing bluez-hid2hci does allow browsing to work, but file transfers (to or from) do not work.

(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.

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.

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.

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.

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

(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?

(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.

*** Bug 757229 has been marked as a duplicate of this bug. ***

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'

See also bug 733847 which might be a dup. In this,  it's hw dependent, using another dongle might help

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.

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

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.

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

The command is hciconfig instead of hcidump. Does anyone know how to make the workaround persist across Bluetooth on/off and system reboots?

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.

I'm confused, so does bluetooth file transfer work in Fedora 16 or not?

Created attachment 567002 [details]
start browsing bluetooth files

start browsing bluetooth files

Created attachment 567003 [details]
download files over bluetooth

download files over bluetooth

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?

@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.

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?

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?

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

(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.
:-((

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 #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

Is bluetooth completely messed up? Will this be fixed anytime soon? What is going on in kernel team that maintains this code?

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/

*** Bug 537720 has been marked as a duplicate of this bug. ***

*** Bug 735319 has been marked as a duplicate of this bug. ***

*** Bug 806642 has been marked as a duplicate of this bug. ***

*** Bug 727106 has been marked as a duplicate of this bug. ***

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

Moving this bug to Rawhide version as this bug occurs in F16 to F18 releases and it's very likely to hit also F19.

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 ***