bug with my broadcom bluetooth usb dongle

I have tested to add just (in the /etc/init.d/bluetooth):

hciconfig hci0 reset

before "exit 0"

And it work directly at boot.

I have added my lsusb -v of my broadcom usb bluetooth dongle in attachment.

Confirmed on Ubuntu 7.10. bluez-utils 3.19 with both the following usb bluetooth adapters:

Edimax EB-DGC2
Trust BT120

My dmesg displays the following messages whenever I move the mouse before running hciconfig hci0 reset:

[ 169.162683] hci_acldata_packet: hci0 ACL packet for unknown connection handle 42
[ 169.173697] hci_acldata_packet: hci0 ACL packet for unknown connection handle 42
[ 169.185666] hci_acldata_packet: hci0 ACL packet for unknown connection handle 42

After I run hciconcig hci0 reset, the connection re-establishes.

I can also run the following instead of hciconfig hci0 reset:

sudo hciconfig hci0 down
sudo hciconfig hci0 up

and it also fixes the problem.

I've just reproduced this problem in Fedora. So the problem is definitely upstream. Will post an email to bluez-users since Launchpad seems to be dead when it comes to bluetooth development

Confirmed in hardy, too.

Confirmed, using Hardy and a MSI BToes 2.0 EDR Micro Dongle.
After startup hcitool scan reports:
Device is not available: No such device
and hcitool dev is empty

sudo /etc/init.d/bluetooth restart
starts the device, however hcitool scan gives:

Scanning ...
Inquiry failed: Connection timed out

The command:
sudo hciconfig hci0 reset
makes it working perfectly (for connecting my phone at least), however after each reboot I have to restart bluetooth and reset hciconfig manually again. I will try out the above mentioned patch and report whether it was successful or not.

Adding sleep 1 && hciconfig hci0 reset or only the last part in /etc/init.d/bluetooth did not entirely fix the problem. It still does not recognize my dongle at startup, and still needs a manual restart of the script, but obviously I do not have to reset hciconfig anymore.

@Bart de Koning:
I also have the MSI BToes 2.0 EDR Micro Dongle. Adding this to /etc/init.d/bluetooth fixes it for me:

(sleep 5 && hciconfig hci0 reset) &

@Bart de Koning and stani
I have the mogodapter (micro adapter with same lsusb reported ID as yours) this makes it work thanks.

Oh scratch that it appears to work at first but does not actually work with my BT mouse. :(

Sorry to spam this bug report but it will work with my mouse if I run sudo hidd --connect=XX:XX:XX:XX:XX:XX everytime I use it. Auto connecting like what works with my other dongle is what does not work.

I have the same problem with a bluetooth mouse, and hciconfig hci0 reset fixes it. Oddly enough, even without that workaround, hard-resetting my laptop (by removing its battery, say) makes the mouse work fine next boot... -- even after I first do a normal boot so the mouse isn't working. If I then hard-reset, it starts working again. Something the init.d shutdown code is doing?

Same problem with Broadcom USB Bluetooth in my Vaio TZ330e with Hardy.

While the adapter is always found, unable to discover any remote devices.

"sudo hciconfig hcio0 reset" makes it work.

Hi @ll,

using the MSI BToes 2.0 EDR Micro Dongle the command "sudo hciconfig hci0 reset or down/up" is required in order to get the legacy Apple Wireless Keyboard and the Apple Wireless Mighty Mouse runnning.

Sorry, just forgot to mention that I am using Ubuntu Hardy - Kernel Linux 2.26.24-19-generic.

Thanks and cheers,
Markus

This problem is still under hardy. I have to run this command after each cold boot or when I restart from suspend.
The hardware involved in my case is Macbook Pro Penryn with the wireless Mighty Mouse from Apple.

I also have this problem on a Dell Latitude D630 using a Dell BT Keyboard and a Dell BT Mouse.
Doing "sudo hciconfig hci0 down" and "sudo hciconfig hci0 up" made them work properly, but I also think that the problem should be fix at the bottom.

Lams

same problem and resolution with a vaio SZ 750/N running Intrepid Ibex.

I have something similar on intrepid with my sitecom dongle (CN-521v2 001) connecting to a wireless apple keyboard. When I reboot the dongle doesnt connect with the keybouard properly unless I turn the power supply off after shutting down. Alternatively, removing the dongle from the usb slot also does the trick and the bluetooth connection with my keyboard is automatically reestablished after that.

Obviously the dongle is left in some state after shutting down that is different from powering up. and that doesnt recover properly. Remember the power stays on the usb port even when shutting down (unless you also turn the power supply off).

Thought it would be useful to share this .....

Setting importances to Medium as it seems to potentially affect a large number, although it has a fairly straightforward workaround.

Same problem with tiny Belking Bluetooth-USB adapter device 050d:016a.

What about the kernels?
i believe this is fixed in 2.6.30-rc6 kernels...

i have a ISSC Dongle, this works very well, i´m using Debian Unstable 2.6.30-rc6

Can anyone confirm this is fixed?

I've checked the issue with Karmic-beta Live-CD. The problem seems to be fixed.

I've used an Anycom USB-500 Bluetooth 2.1 Dongle and a Bluetooth Mouse on an ASUS EeePC 900A. Therefore I was not able to check file transfer. But pairing was no problem at all after booting into the live environment.

Chipset: Broadcom BCM2046B1
BT-Device: 0a5c:2157 Broadcom Corp.

Should I attach some logs/files?

Success! Thanks for the headsup AlfredSK.

My Logitech Cordless MediaBoard Pro keyboard and bluetooth dongle paired and are working in Ubuntu 9.10 Karmic-beta Live-CD. I am typing this from my MediaBoard :)

$ lsusb | grep Bluetooth
Bus 004 Device 003: ID 22b8:0850 Motorola PCS Bluetooth Device

Fixed for me in Karmic too. My Bluetooth USB dongle is working without any additional commands!

$ lsusb | grep Bluetooth
Bus 004 Device 003: ID 0a5c:2039 Broadcom Corp. Bluetooth Device

Thanks!
Btw also thanks for all the improvements: eg. I can now control my computer with my phone! Why I need it, I do not know, but it is funny!

So I guess this bug can be closed...

Closing bug due to above comments