bluetooth discovery fails: no devices found during scan

[Stefan Sommer]

Binary package hint: bluez

hcitool scan completes without errors but no devices found

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: bluez 4.91-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.39-0.5~20110427-generic 2.6.39-rc5
Uname: Linux 2.6.39-0-generic x86_64
Architecture: amd64
Date: Thu May 12 10:42:55 2011
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Release amd64 (20110427.1)
InterestingModules: rfcomm bnep btusb bluetooth
MachineType: Hewlett-Packard HP Pavilion dm1 Notebook PC
ProcEnviron:
 LANGUAGE=en_US:en
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.39-0-generic root=UUID=e48720e0-d114-4e3e-acb1-5d1b33567ac5 ro crashkernel=384M-2G:64M,2G-:128M quiet splash vt.handoff=7
SourcePackage: bluez
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 03/04/2011
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: F.05
dmi.board.asset.tag: Base Board Asset Tag
dmi.board.name: 1611
dmi.board.vendor: Hewlett-Packard
dmi.board.version: 96.1F
dmi.chassis.asset.tag: Chassis Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: Hewlett-Packard
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnHewlett-Packard:bvrF.05:bd03/04/2011:svnHewlett-Packard:pnHPPaviliondm1NotebookPC:pvr0589100000252B00000320100:rvnHewlett-Packard:rn1611:rvr96.1F:cvnHewlett-Packard:ct10:cvrChassisVersion:
dmi.product.name: HP Pavilion dm1 Notebook PC
dmi.product.version: 0589100000252B00000320100
dmi.sys.vendor: Hewlett-Packard
hciconfig:
 hci0: Type: BR/EDR Bus: USB
  BD Address: EC:55:F9:D1:60:07 ACL MTU: 310:10 SCO MTU: 64:8
  UP RUNNING PSCAN
  RX bytes:2767 acl:0 sco:0 events:116 errors:0
  TX bytes:1966 acl:0 sco:0 commands:111 errors:0

[Stefan Sommer (stefan-nefan)]

A workaround is described here: http://ubuntuforums.org/showthread.php?t=1584388. Boot in Windows, turn on bluetooth, turn off bluetooth/wifi in hardware with fn-12, and boot in Linux. This is just a workaround; it's suboptimal having to install Windows to get working bluetooth.

[Kevin S (ks20xx)]

Confirmed. Kubuntu 10.10. Bluez 4.6 and 4.85.

[Geert (geert-x)]

Bluetooth discovery fails because with the Ralink chip the bluetooth radio is off by default, it need's to be switched on after each boot. This can be done with the command: sudo bccmd psset -s 0x0000 0x028c 0x0001

Afterwards restart bluetooth: sudo /etc/init.d/bluetooth restart

You can add this command to /etc/init.d/bluetooth (suggestion is to put it after the log_daemon_msg command) to switch the radio on automatically.

Information found on https://bugs.meego.com/show_bug.cgi?id=3498

(In my case this fix only worked after modifying /etc/init.d/bluetooth and a reboot).

[Mikko Virkkilä (virkkila)]

After issuing the following two commands:

sudo bccmd psset -s 0x0000 0x028c 0x000
sudo bccmd warmreset

I started seeing inquiry results and was able to successfully pair to another device. I did not need to restart bluez.

[Mikko Virkkilä (virkkila)]

Seems copy-pasting dropped the last 1 on the line, that should be

sudo bccmd psset -s 0x0000 0x028c 0x0001
sudo bccmd warmreset

Browsing through the bccmd source code: The first part is "put the value 0x0001 in ps key 0x028c and store it in store 0x0000". Store 0x0000 is the same as default, so the -s switch (specify store) doesn't really have much of an effect.

The following single command should work just as well (-r indicates do a warm reset afterwards)

sudo bccmd psset -r 0x028c 0x0001

[Geert (geert-x)]

This single command is a good suggestion. I think I'll put in in a script on my desktop to switch on the radio when needed instead of switching it on by default using /etc/init.d/bluetooth. This will save battery power.

[Geert (geert-x)]

Did some further testing and finished my bash script to enable the bluetooth radio when required. (I removed the modifications I made to '/etc/init.d/bluetooth'). The script looks like this:

sudo bccmd psset -s 0x0000 0x028c 0x0001
sudo hciconfig hci0 up
sudo /etc/init.d/bluetooth restart
sleep 2

Remarks: on my PC (an HP Pavilion DM1 with Mint 11) the bccmd command doesn't work when combined with a warm reset (the -r argument)! The bluetooth restart is also required to get things working.

The script works flawlessly, after execution the gray bluetooth icon in the system tray immediately changes to black and you paired devices show up. (Also tested with Blueman Bluetooth Manager).

[Mikko Virkkilä (virkkila)]

Hello everyone,

Using the following steps I fixed my bluetooth for now.

First I disabled wireless using fn+f12, and then I re-enabled it, again using fn+f12.
This made the adapter show up in BlueZ as hci0, which is needed for running the bccmd commands.

Then I issued the following command:

bccmd psset -r -s implementation 0x028c 0x0001

After that command Bluetooth started working and survives a shutdown just fine. The implementation ps store is on eeprom, so that key 0x028c now has the value 0x0001 stored on the module's eeprom.

[Launchpad Janitor (janitor)]

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

[Eric Miao (eric.y.miao)]

Simply performing bccmd in the bluetooth init script might not be a good idea, as it's not applicable to other bluetooth modules. One reliable way is to keep it in the udev rules. I used the rules below which is working for me:

SUBSYSTEM=="bluetooth", SUBSYSTEMS="usb", ATTRS{idVendor}=="148f", ATTRS{idProduct}=="2000", RUN+="/usr/sbin/bccmd -d $kernel psset -r 0x028c 0x0001"

This is not the optimal fix as it's going to set the key anyway to 1 upon the hci device is added, but could be less intrusive.

[Eric Miao (eric.y.miao)]

Below is a fix to bluez

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "fix-ralink-rt5390-bluetooth-with-bccmd.patch" 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-reviewers team 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.]

[Eric Miao (eric.y.miao)]

Better to add 'udevadm trigger --action=add --subsystem-match=bluetooth' to bluez.postinst, so the udev rule can take effect once the package has been installed.

[Eric Miao (eric.y.miao)]

Updated the patch with v2:

 - change to Makefile.in to add the udev rule as it seems not generated from Makefile.am
 - add 'udevadm trigger --action=add --subsystem-match=bluetooth' to debian/bluez.postinst

[Mathieu Trudel-Lapierre (cyphermox)]

I'm still not convinced that this should be covered by a udev rule in bluez; seems to me like this will conflict with the killswitch states for the device, which appear to me as more important to preserve in all cases. (For instance, booting your computer in a plane shouldn't cause the udev rule to trigger and radio to be turned on despite the killswitch state being off, and it's unclear yet how this reacts). The patch looks technically correct and seems like it will do the right thing, but it seems a little dangerous to assume the radio should just be turned on (and that's the driver's job anyway)

May I suggest fixing this at the linux kernel driver level instead? I'll open a linux task in case.

[Callum Hutchinson (callumhutchinson1)]

Not sure on the progress on this but while toying around the other day under Wubi on my HP G62-B18SA notebook I found that by default Bluez does not support the wifi card entirely, however, Blueman does. The only issue I have found with Blueman is that the wifi card tends to be enabled by default on startup much like the script or patch described above.
Can anyone confirm this?

[Callum Hutchinson (callumhutchinson1)]

I can confirm that Linux Mint has normal wifi + bluetooth behaviour, how does one go about extrapolating this onto Ubuntu?

[Joseph Salisbury (jsalisbury)]

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Юрий Чудновский (fqc)]

Confirm bug affects Ubuntu 13.04 (hardware: HP ProBook 4320s, Ralink bluetooth ), so it must be fixed.

[Craig Magina (craig.magina)]

This occurs in Ubuntu 13.10 amd64 on an HP Pavilion DM1Z (AMD APU E-350 unit) and the "bccmd psset -r -s implementation 0x028c 0x0001" workaround does work.

[Mahmoud Salaheldin (mahmoud-salaheldin)]

tried

and it made it work on my ubuntu 14.04 LTS

 sudo bccmd psset -s 0x0000 0x028c 0x0001
sudo hciconfig hci0 up
sudo /etc/init.d/bluetooth restart

[Юрий Чудновский (fqc)]

Confirm bug for 15.10
Even more, Bluetoth applet say 'no adapters found' even if connected to other devises.

$sudo bccmd psset -s 0x0000 0x028c 0x0001
$hcitool dev
Devices:
 hci0 CC:52:AF:DE:E9:CB
$sudo /etc/init.d/bluetooth restart
[ ok ] Restarting bluetooth (via systemctl): bluetooth.service.
// in dmesg: Bluetooth: hci0 hardware error 0x37
$hcitool dev
Devices:
$sudo hciconfig hci0 up
@frank@FQC-book:~$ hcitool dev
Devices:
 hci0 CC:52:AF:DE:E9:CB

[Daniel van Vugt (vanvugt)]

Thank you for reporting this bug to Ubuntu.
Ubuntu 11.04 (natty) reached end-of-life on October 28, 2012.

See this document for currently supported Ubuntu releases:
https://wiki.ubuntu.com/Releases

We appreciate that this bug may be old and you might not be interested in discussing it any more. But if you are then please upgrade to the latest Ubuntu version and re-test. If you then find the bug is still present in the newer Ubuntu version, please add a comment here telling us which new version it is in and change the bug status to Confirmed.

[Paul White (paulw2u)]

Bug did not expire due other bug tasks
No reply to comment #25 or other comments for over 3 years
Marking "Invalid" to close