Bug 733847

Same issue here, since few weeks I get this issue from both my Thinkpad X201 and MacBook 5,5 running Fedora 15. Note this bug look similar to 735319.

Same issue here.... I have a Samsung Galaxy Gio and a Toshiba with Fedora... Help me to resolve this problem

Same issue.  Macbook Pro running Fedora 15 with Asus Transformer

Same here, but can work around using another dongle. The bad dongle:
"ID 0a5c:2121 Broadcom Corp. BCM2210 Bluetooth" (from lsusb), the working one
"ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)".

As for others, both worked fine until some update of F15 (and F16).

Now, how do I select a working dongle from what's available today (both of my are actually quite old i. e., some years.)

Same problem since upgrade to F16, Thinkpad X201.

Deleting handset and re-pairing, I can select the option to use the phone for DUN, which seems to complete ok, but when I next try to use it will fail.

Going back into bluetooth settings I find that DUN is not ticked (which seems wrong in itself?) for the device; toggling it fails with the 'Connection refused (111)' error.

Reproducing error on command line (w bad dongle):
 # hcitool cc 50:C9:71:12:9D:13
 # echo $?
0
 # sdptool records  50:C9:71:12:9D:13
Failed to connect to SDP server on 50:C9:71:12:9D:13: Host is down
 # hcitool dc 50:C9:71:12:9D:13
Not connected.

I. e., although 'hcitool cc' returns OK, there is no connection made. Since there is a report in bug 735319 (possible dup) about a Nokia phone which works, I tried also my Symbian 3^ Nokia E6, same results: browsing works with the good dongle, but not w the bad one. Other tests performed with  a Jabra EasyGo headset. So, it's not just about browsing but also A2DP streaming audio .

See also bug 750771 and bug 753617, the latter referenced in the release notes.

Created attachment 541887 [details]
hcidump from 'hcitool cc <addr>'

Output from hcidump while doing 'hcitool cc 50:C9:71:12:9D:13' in another window, trying to connect to my Jabra EasyGo headset.

Looking into dmesg, I find the following sequence repeated 5-10 times when I insert the bad dongle:

[41999.120983] usb 1-1.1.1: new full speed USB device number 13 using ehci_hcd
[41999.215339] usb 1-1.1.1: New USB device found, idVendor=0a5c, idProduct=2121
[41999.215350] usb 1-1.1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[41999.215359] usb 1-1.1.1: Product: BCM92045B3 ROM
[41999.215366] usb 1-1.1.1: Manufacturer: Broadcom Corp
[42077.022227] usb 1-1.1.1: USB disconnect, device number 13
[42077.022521] Bluetooth: hci0 urb dc89c000 submission failed

Eventually, it settles without the last two lines. The working dongle have no error message, there is just three lines which looks sane and they are not repeated. 

Placing the headset *really* close (5 cm) from the dongle, it connected OK but still no sound while streaming audio. dmesg says:
[49233.438124] Bluetooth: hci0 SCO packet for unknown connection handle 6

Hm... Are everyone having troubles using Broadcom chips?

Seeing the same/similar issue on F16. Lenovo W510, Broadcom, Nokia N900.

(In reply to comment #8)
> Looking into dmesg, I find the following sequence repeated 5-10 times when I
> insert the bad dongle:
[cut]

This seem to be  gone in Fedora 16 kernel 3.1.5-6, dmesg output looks fine besides the "hci0 urb ecf29680 submission failed" message which is present also with the working dongle.   

Connection (i. e., hcidump output) still fails in the same way, though.

@Kevin R. Page I've also a Thinkpad X201 and the same problem https://bugzilla.redhat.com/show_bug.cgi?id=753617 . I still use F15 with 2.6.38 and I hope they will fix this Bug until F17.....

@Alec Leamas I've bought another dongle, HAMA Version 3.0/EDR Class2 Nano-Bluetooth-USB-Adapter.

$ lsusb
Bus 002 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

But it doesn't solve the problem - shit! Pairing was successful, but I can't browse or send files with F16 (same problem with my built in bluetooth adapter).

tail /var/log/messages 
Dec 29 20:04:34 x201 bluetoothd[1256]: bluetoothd[1256]: Mode session 0x7fc540860260 with :1.48 activated
Dec 29 20:04:35 x201 obex-client[2202]: Connection refused (111)
Dec 29 20:04:35 x201 dbus[1348]: [system] Rejected send message, 2 matched rules; type="method_return", sender=":1.0" (uid=0 pid=1256 comm="/usr/sbin/bluetoothd -n ") interface="(unset)" member="(unset)" error name="(unset)" requested_reply="0" destination=":1.48" (uid=1000 pid=2202 comm="/usr/libexec/obex-client ")

$ rpm -qa | grep bluez
bluez-hid2hci-4.96-3.fc16.x86_64
bluez-cups-4.96-3.fc16.x86_64
bluez-libs-4.96-3.fc16.x86_64
bluez-4.96-3.fc16.x86_64

$ rpm -qa | grep gnome-user-share
gnome-user-share-3.0.1-1.fc16.x86_64

# l2ping 40:98:4E:71:1B:36  
Ping: 40:98:4E:71:1B:36 from 00:1B:DC:04:5B:DC (data size 44) ...
44 bytes from 40:98:4E:71:1B:36 id 0 time 12.89ms
44 bytes from 40:98:4E:71:1B:36 id 1 time 18.59ms
44 bytes from 40:98:4E:71:1B:36 id 2 time 33.60ms
44 bytes from 40:98:4E:71:1B:36 id 3 time 29.87ms
Send failed: Connection reset by peer

Same problem also with a Bazoo Bluetooth V3.0 USB dongle:
$ lsusb
Bus 001 Device 004: ID 0a5c:2198 Broadcom Corp.

sending files is possible if you retry it again and again
http://dl.dropbox.com/u/9887743/bluetooth-bug.ogv

Not in all cases, tried to do what you did but still keeps getting refused

0db0:3801 Micro Star International Motorola Bluetooth 2.1

but using obexftp works

obexftp -b (thehexaddress) -p (source file)

for me the first try fails, but the program automaticly retry and the second always works.

Can any one from red hat give an answer to when this will be fixed, 

Bluetooth seems to be working, but the implementation is wrong.

I believe I am seeing the same problem.  I when I try connecting my iphone to my laptop, it finds the iphone in discovery.  I when I try to set-up it shows a pin number on the screen with a match/does not match button.  At the same time it shows the same pin on the iphone with a pair/cancel option.  It does not seem to matter which I click first, the iphone button, or the laptop button, either way it spins its wheels for a few minutes and then tells me setting up the device failed.   

Afterwards, the iphone is listed in my bluetooth connections and the laptop is listed on my iphone.  Both show the devices as not connected.  I have repeated this dozens of times with the same results.

Once it actually did succeed in connecting.   However, I since reset my iphone and I haven't been able to repeat that success...

Bill

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

Seems that this specific bug is fixed in kernel 3.5.0 (F17), although I hesitate to close without another report - lot's of people seem to affected by this one.

Note that 3.5.0 has other problems, notably bug #827629.

Obex seems to work again for me too. Glad there is finally a fix. I have not tried any audio device yet. (Thinkpad x220).

hey, lost focus... I can't close this one :) But it seems that someone should.

Hi, just wondering, any update on this?

I still see this on my Fedora-16, X220 laptop. 
- pairing to my Nokia phone is successful
- I get the error mentioned in the description when I try to 'browse' the files on the device.

Just to be more clear, this is what I see in my /var/log/messages
#----------------#
Sep 22 12:41:09 tesla obex-data-server: sdp_extract_seqtype: Unexpected end of packet
Sep 22 12:41:09 tesla obex-data-server: sdp_extract_seqtype: Unexpected end of packet
#----------------#

root@~$ uname -r ; rpm -q gnome-bluetooth
3.4.7-1.fc16.x86_64
gnome-bluetooth-3.2.2-1.fc16.x86_64
root@~$

It works for me (gnome-bluetooth-3.4.2-1.fc17.x86_64), it's not as stable as it was last year, but it works at least.

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/

(In reply to comment #24)
> 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/

Hi, I originally reported the bug but I don't have a Fedora installation to test at the moment. Are any of the other commenters still experiencing it?

Nathan, can you put Fedora 18 Beta RC1 live image on flashdisk, boot to live system and try to reproduce the bug? Thanks.

Since Fedora 16 end-of-life will be in 2013 Q1 it's more important to fix Bluetooth in Fedora 17 and 18 releases.

(In reply to comment #26)

I gave it a try with Fedora 18 Beta RC1, but got the following error message:

"Oops! Something went wrong.
Unhandled error message: The name:1.65 was not provided by any .service files."

However, I was able to send a file from the computer to the device (a Sony Ericsson Cedar phone), which is an improvement!

I've had difficulties connecting to this device via Bluetooth using various flavours of Linux and Windows, so I'm wondering if it is a device-specific issue.

Can you also send a file from device to computer?

No, I can't send a file from the device to the computer in either Fedora or Windows.

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

Obex push has been fixed in F18, but not in F17. It seems to be same bug as #747575.

About FTP browser, that's different bug, see #537720.

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