Bluetooth 'Send files' returns permission denied error

Bug #872044 reported by CaptainMark on 2011-10-10
738
This bug affects 251 people
Affects Status Importance Assigned to Milestone
GNOME Bluetooth
New
Undecided
Unassigned
Linaro Linux
Won't Fix
Undecided
Unassigned
Linaro Ubuntu
Medium
Unassigned
OEM Priority Project
Medium
Ursula Junque
Precise
Undecided
Unassigned
bluez (Fedora)
Invalid
High
bluez (Ubuntu)
Undecided
Unassigned
Oneiric
Undecided
Unassigned
Precise
Undecided
Unassigned
linux (Ubuntu)
Medium
Ming Lei
Oneiric
Undecided
Unassigned
Precise
Medium
Ming Lei
obex-data-server (Ubuntu)
Oneiric
Undecided
Unassigned
Precise
Medium
Unassigned
obexd (Ubuntu)
Oneiric
Undecided
Unassigned
Precise
Medium
Unassigned

Bug Description

Gnome 3 bluetooth manager cannot send files to my HTC Desire phone, (or any phone that I could try) Gnome2 bluetooth manager would send some form of authorisation request when first sending a file to my phone, which i would accept on the phone and then all future files could be sent with a simple 'accept?' message on the phone, on any gnome3 setup i have tried there is not authorisation request and i believe this is what leads to a permission denied error on screen (video attached)

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: gnome-bluetooth 3.2.0-0ubuntu1
ProcVersionSignature: Ubuntu 3.0.0-12.20-generic 3.0.4
Uname: Linux 3.0.0-12-generic x86_64
ApportVersion: 1.23-0ubuntu3
Architecture: amd64
Date: Mon Oct 10 23:23:33 2011
ExecutablePath: /usr/bin/bluetooth-applet
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111010.1)
SourcePackage: gnome-bluetooth
UpgradeStatus: No upgrade log present (probably fresh install)

CaptainMark (imark-skinner) wrote :
Launchpad Janitor (janitor) wrote :

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

Changed in gnome-bluetooth (Ubuntu):
status: New → Confirmed
Pedro Villavicencio (pedro) wrote :

Thanks for the report, could you please attach your /var/log/messages after reproduced the issue? thanks in advance.

Changed in gnome-bluetooth (Ubuntu):
importance: Undecided → Low
status: Confirmed → Incomplete
Oscar Tiderman (oscar-tiderman) wrote :

I am suffering from the same problem but on my Samsung Galaxy S, used to work in Natty.
My /var/log/messages is empty but these are the only lines regarding this in /var/log/syslog:

Oct 25 18:33:42 oscar-laptop kernel: [ 549.861814] ACPI: EC: GPE storm detected, transactions will use polling mode
Oct 25 18:37:03 oscar-laptop bluetoothd[1306]: Mode session 0x7f1d90aa0530 with :1.63 activated
Oct 25 18:37:07 oscar-laptop obex-client[2467]: Permission denied (13)
Oct 25 18:37:12 oscar-laptop bluetoothd[1306]: Mode session 0x7f1d90aa0530 with :1.63 activated
Oct 25 18:37:15 oscar-laptop obex-client[2467]: Permission denied (13)

It's pretty quiet, this is after two unsuccessful attempts to send a file to my phone (18:37).

CaptainMark (imark-skinner) wrote :

Same as post #4 /var/log/messages is empty or does not exist, i can reproduce the error anytime so i can run any commands needed

aka (vangop) wrote :

Same thing. Also I cannot pair Phone->PC if the pairing is initiated from the phone.
The phone asks if the pin is correct, I confirm, it then says pin incorrect. Samsung galaxy, Android.

petogal (petogal) wrote :

Same thing, Samsung Galaxy s2 and HP laptop

Florent Mertens (givre) wrote :

Same problem with my Samsung i5800.

Changed in gnome-bluetooth (Ubuntu):
status: Incomplete → Confirmed
Amneet Bedi (amneetbedi) wrote :

Facing the same issue with my Samsung Corby Plus

Same problem with samsung galaxy s2 - also it seems as though bluetooth audio will be broken.

Jonathan Bispo (jfb0101) wrote :

I have problemas with bluetooth in Ubuntu 11.10 too. I can send files but when it ends my system brakes and I need to restart that. I'm using the default manager of Gnome 3.

Nelo (nelo) wrote :

Same problem, Samsung Galaxy S2 and DELL Studio xps 1647

David Young (dove-young) wrote :

Seems there is not a workaround so far. I confirm the same problem between Thinkpad T400 and HTC Incredible S. Ubuntu 11.10 i386 desktop

David Young (dove-young) wrote :

Workaround:

Seems I checked “Share public files over Bluetooth" in Personal File Sharing Preference panel, then I could send files in ~/Public folder to my smart phone.

Files not in ~/Public folder can also be sent over Bluetooth.

mano-மனோ (manoj-neyveli) wrote :

 The same problem between my lg510 and ideapad z460.

fgy (1stmrfgy) wrote :

Same problem, Lenovo X201-Samsung S5230.
part of syslog:
.....
Nov 1 19:32:57 x201 bluetoothd[1071]: Discovery session 0x7f7331e11550 with :1.93 activated
Nov 1 19:33:06 x201 bluetoothd[1071]: Mode session 0x7f7331e0f500 with :1.86 activated
Nov 1 19:33:08 x201 obex-client[6181]: Permission denied (13)
......

fjkum (fongjeng-kum) wrote :

Please has someone assigned to look at this bug as it's really makes me feel handicapped when this bluetooth stops working.

Niklas Fischer (niklasfi) wrote :

I can confirm the bug as well as as the error message Permission denied (13) when I initialize sending a file.

Same problem here with Galaxy S. And why importance set to low ? It's pretty annoying...

CaptainMark (imark-skinner) wrote :

This is not restricted to ubuntu 11.10, running the early cut of 12.04 and this bug is also present

98 comments hidden view all 158 comments

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

97 comments hidden view all 158 comments
aka (vangop) wrote :

There's a workaround - to mount the phone with obexfs. see http://ubuntu-answers.blogspot.com/2011/11/bluetooth-on-ubuntu-1110.html

David Young (dove-young) wrote :

Send files in your ~/Public folders are OK. In case you have checked “Share public files over Bluetooth" in Personal File Sharing Preference

Send files from other folders will encounter 'Permission deny' problem

Steffen Krumbholz (skrumbholz) wrote :

Sending files from ~/Public folder [1] to my Android phone doesn't work for me. I have configured sharing over bluetooth in gnome-file-share-properties and paired the devices successfully. But I still get the permission denied (13) error.

Sending files the other way around works like a charm.

Linux eeepc 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:50:42 UTC 2011 i686 i686 i386 GNU/Linux
Distributor ID: Ubuntu
Description: Ubuntu 11.10
Release: 11.10
Codename: oneiric
gnome-user-share: 3.0.0-2ubuntu3
gnome-bluetooth: 3.2.0-0ubuntu2

[1] I have configured the folder ~/Temp as the public folder in file $HOME/.config/user-dirs.dirs (XDG_PUBLICSHARE_DIR="$HOME/Temp")
drwxrwxr-x 2 skrumbholz skrumbholz 4096 2011-11-15 14:01 /home/skrumbholz/Temp

ಸతీशः (bdsatish) wrote :

Same problem, Galaxy S. Even sending from ~/Public doesn't work anymore. There is a segmentation fault with the error messages:

Nov 16 01:58:17 sarvamula kernel: [ 2936.499111] gnome-control-c[3211]: segfault at 8 ip a6d1e230 sp bfc3df20 error 4 in libgnome-bluetooth.so.8.0.0[a6d17000+1a000]
Nov 16 01:58:27 sarvamula bluetoothd[2033]: input-headset driver probe failed for device CC:05:1B:97:08:E7
Nov 16 01:59:09 sarvamula bluetoothd[2033]: Discovery session 0xb7f2d0d8 with :1.82 activated
Nov 16 01:59:17 sarvamula obex-client[3764]: obex-client daemon 0.42
Nov 16 01:59:17 sarvamula bluetoothd[2033]: Mode session 0xb7f2d0d8 with :1.85 activated
Nov 16 01:59:20 sarvamula obex-client[3764]: Permission denied (13)
Nov 16 01:59:22 sarvamula bluetoothd[2033]: Mode session 0xb7f2d0d8 with :1.85 activated
Nov 16 01:59:24 sarvamula obex-client[3764]: Permission denied (13)

From /var/log/syslog

95 comments hidden view all 158 comments

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

103 comments hidden view all 158 comments
phcoder (phcoder) wrote :

I've discovered where the problem comes from: some devices are unable to respond to open request in rapid succession after the SDP scanning. You need to close SDP session and wait 2 seconds before connecting to rfcomm, like the attached patch.

The attachment "sdp.diff" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. 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 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
103 comments hidden view all 158 comments

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

102 comments hidden view all 158 comments
Teguh Wibowo (kangtguh) wrote :

The same problem between my samsung phone and fujitsu MH-330, service list just dial-up,no file transfer no object push.
I've installed blueman (bluetooth-manager) package.
I just found that my netbook CAN receive files SUCCESSFULLY from my phone while the bluetooth-manager (blueman) active,but CANNOT send back from my netbook to my phone. [Sending files - failed with the a 'permission denied error(13)'].

103 comments hidden view all 158 comments

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

103 comments hidden view all 158 comments
Felix (apoapo) wrote :

On 07.12.2011 16:07, Felix wrote:
> Are we talking about the same bug?
>
> https://bugs.launchpad.net/ubuntu/+source/gnome-bluetooth/+bug/879923
>
I think we do. There is the same bug in both obexd-client and
obex-data-server. I've posted a patch only to one of the packages. Here
attached is the patch for obexd.

--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

I confim. Samsung Galaxy 5 in Ubuntu 11.10 (gnome-shell). IMHO this bug is critical. Bluetooth is the stardard way to comm with mobile. All Ubuntu look&fell is affected by this bug. How will change to Ubuntu if it cannot comm with his mobile?

phcoder (phcoder) wrote :

On 07.12.2011 18:54, Andre Cavalcante wrote:
> I confim. Samsung Galaxy 5 in Ubuntu 11.10 (gnome-shell). IMHO this bug
> is critical. Bluetooth is the stardard way to comm with mobile. All
> Ubuntu look&fell is affected by this bug. How will change to Ubuntu if
> it cannot comm with his mobile?
>
It's not Ubuntu fault. Just your and my phones are piece of crap. It
would be nice if my or similar workaround would be accepted though.

--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko

carlosv (cvedovatti) wrote :

The bug stills present on the alpha version of Ubuntu 12.04, hope to see to solve soon.

icewater (a-ubuntu) wrote :

Connection to the headset I use to listen to music (LG HDS 700) also fails with the bluetooth applet, but works with blueman, as mentioned earlier in this bug.

It worked with the applet exactly one time, then not again.

I'm on 11.10

sreenivasa reddy (cnureddy-b) wrote :

Both the solutions in comment #21 worked for me

1). I could mount folders via obexfs

2). apt repo upgrade as below
  $ sudo add-apt-repository ppa:blueman/ppa
  $ sudo apt-get update
  $ sudo apt-get upgrade

I feel this bug can be closed

Kent Lin (kent-jclin) on 2011-12-20
Changed in oem-priority:
importance: Undecided → Critical
Changed in oem-priority:
status: New → Confirmed

I am affected by the same bug (fresh install of Ubuntu 11.10 with Unity). Actually I cannot do any file transfer with my phone : sending files from the phone, from the PC, browsing files, nothing works (permission denied everywhere). Also, the bluetooth-applet crashes. Only the initial pairing with the phone went fine. Typical errors in syslog are :

Dec 21 11:26:27 guilleri obex-data-server: sdp_extract_seqtype: Unexpected end of packet
Dec 21 11:27:08 guilleri bluetoothd[4523]: Bluetooth daemon 4.96
Dec 21 11:27:08 guilleri bluetoothd[4523]: Unable to get on D-Bus
[...]
Dec 21 11:29:34 guilleri obex-client[4567]: obex-client daemon 0.42
Dec 21 11:29:34 guilleri bluetoothd[1136]: Mode session 0x7fa6debc6630 with :1.82 activated
Dec 21 11:29:36 guilleri obex-client[4567]: Permission denied (13)

Comment #14 suggested to look into the "Personal file sharing" settings but I cannot find them in Unity's system settings (though the package gnome-user-share is installed).

Update : I finally found the Personal file sharing settings, it was well-hidden in the Dash (see Bug #883769). I can now receive files sent from the phone on my PC. No luck yet for sending files from the PC, and browsing files on the phone...

theghost (theghost) wrote :

There is also an upstream bug-report: https://bugzilla.gnome.org/show_bug.cgi?id=663044

I might help with this bug.

dAnjou (danjou) wrote :

This bug has probably nothing to do with GNOME. I tried to use the Bluetooth Chat sample from Android ( http://developer.android.com/resources/samples/BluetoothChat/index.html ) with the little code snippet in the attachment and I get this (MAC disguised by me):

max@XV88:~/Projekte/python$ python bt_spam_server.py
Searching ...
connecting to "BluetoothChat" on 3C:5A:37:XX:XX:XX
Traceback (most recent call last):
  File "bt_spam_server.py", line 39, in <module>
    sock.connect((host, port))
  File "<string>", line 5, in connect
bluetooth.btcommon.BluetoothError: (13, 'Permission denied')
max@XV88:~/Projekte/python$

I tested it on a Natty machine too and it worked perfectly.

(Credits for the snippet go to http://www.humbug.in/2010/sample-bluetooth-rfcomm-client-app-in-python/ )

Indeed not an issue with gnome-bluetooth really, this has more to do with obexd or obex-data-server than GNOME (and probably not bluez either).

I'm reassigning this to obexd for now, since there really does seem to be something wrong with it at least in precise (and updating to the latest source seems to let it work better).

The two patches provided might help, but I'm just generally not fond of adding timeouts for the fun of it; it always seems like there ought to be a better way to achieve this. However, since the "ugliest" one is for obexd, which has heavily changed in 0.43, it still seems like the lesser evil than trying to look through and backport the changes.

affects: gnome-bluetooth (Ubuntu) → obexd (Ubuntu)
Changed in obexd (Ubuntu):
importance: Low → Medium
Changed in obex-data-server (Ubuntu):
importance: Undecided → Medium

The issue probably also affects o-d-s, so let's keep a task open for it too.

Changed in obex-data-server (Ubuntu):
status: New → Confirmed
Changed in oem-priority:
assignee: nobody → Ursula Junque (ursinha)
tags: added: rls-mgr-p-tracking
Ursula Junque (ursinha) on 2012-01-30
Changed in obexd (Ubuntu):
status: Confirmed → Incomplete
Changed in oem-priority:
status: Confirmed → Incomplete
Changed in obex-data-server (Ubuntu):
status: Confirmed → Incomplete
Ursula Junque (ursinha) on 2012-01-30
Changed in oem-priority:
status: Incomplete → Confirmed
Changed in obexd (Ubuntu):
status: Incomplete → Confirmed
Changed in obex-data-server (Ubuntu):
status: Incomplete → Confirmed
Changed in oem-priority:
importance: Critical → Medium
tags: added: linaro-ubuntu lt-origen
tags: added: patch-needswork
removed: patch
Changed in bluez (Ubuntu):
status: New → Confirmed
Changed in obex-data-server (Ubuntu):
status: Confirmed → Incomplete
Changed in linaro-ubuntu:
status: New → Confirmed
importance: Undecided → Medium
92 comments hidden view all 158 comments

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.

Changed in obex-data-server (Ubuntu):
status: Incomplete → Confirmed

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?

Changed in linux (Ubuntu):
status: New → Confirmed

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.

Changed in linux (Ubuntu):
importance: Undecided → Medium
tags: added: bluetooth
Changed in linux (Ubuntu):
assignee: nobody → Ming Lei (tom-leiming)

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

Created attachment 567002
start browsing bluetooth files

start browsing bluetooth files

Created attachment 567003
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.

Changed in linux (Ubuntu Precise):
status: Confirmed → Fix Committed
Changed in linux (Ubuntu Precise):
status: Fix Committed → Fix Released
tags: added: rls-p-tracking
Tim Gardner (timg-tpi) on 2012-03-19
Changed in linux (Ubuntu Oneiric):
status: New → Fix Committed
tags: removed: rls-p-tracking
no longer affects: obexd (Ubuntu)
no longer affects: obex-data-server (Ubuntu)
Changed in obex-data-server (Ubuntu Oneiric):
status: New → Invalid
Changed in obex-data-server (Ubuntu Precise):
status: Confirmed → Invalid
Changed in obexd (Ubuntu Precise):
status: Confirmed → Invalid
Changed in obexd (Ubuntu Oneiric):
status: New → Invalid
Changed in bluez (Ubuntu Oneiric):
status: New → Invalid
Changed in bluez (Ubuntu Precise):
status: Confirmed → Invalid
no longer affects: oem-priority/q-series
Changed in oem-priority:
status: Confirmed → Fix Released

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?

Luis Henriques (henrix) on 2012-04-02
tags: added: verification-needed-oneiric
tags: added: verification-done-oneiric
removed: verification-needed-oneiric

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?

Changed in linux (Ubuntu Oneiric):
status: Fix Committed → Fix Released

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

Fathi Boudra (fboudra) on 2013-03-29
Changed in linaro-ubuntu:
status: Confirmed → Fix Released
Linus Walleij (triad) on 2013-09-16
Changed in linux-linaro:
status: New → Won't Fix
Changed in bluez (Fedora):
importance: Unknown → High
status: Unknown → Invalid
Displaying first 40 and last 40 comments. View all 158 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.