tagline: From openSUSE
The following information is a fix to bug 461369 . "hcitool cc <bt addr>" reports "Can't connect: Input/output error", and "bluetoothd -nd" reports that it can't connect to d-bus. This is a problem with the bluetooth kernel driver not working properly. The solution is to "modprobe btusb reset=1" as root. Then add the following line to your /etc/modprobe.conf.local file (again, as root):
options btusb reset=1
This should allow bluetooth to function after subsequent reboots.
If this workaround doesn't resolve the problem, you can try to change the /etc/dbus-1/system.conf file. You should comment the lines:
<allow send_requested_reply="true" send_type="method_return"/> <allow send_requested_reply="true" send_type="error"/>
And add the following ones:
<!-- Fix to avoid access denials on PackageKit and others --> <allow send_requested_reply="true" />
The resulting file should appear as following:
<!-- allow sending valid replies --> <!-- commented out part <allow send_requested_reply="true" send_type="method_return"/> <allow send_requested_reply="true" send_type="error"/> --> <!-- Newly added line to fix permission problems --> <allow send_requested_reply="true" />
Then restart the computer.
If you are having issues with kde's bluetooth frontends on 11.1 try installing gnome-bluetooth and bluez-gnome, and running bluetooth-applet. This does not work, but it gives you something to occupy your time. Or, go back to 10.3.
Downgrading the Bluetooth Stack
Another alternative is to remove the Bluetooth software that is packed with 11.1, which is BlueZ 4.x and install the previous that shipped with 11.0, which is BlueZ 3.x. To do that, RPMs would be easier, however they are no longer available, it is possible to accomplish that following this tutorial  currently in Portuguese.
Quick and Dirty
This should at least get you going if your bluetooth is working, but your KDE/Gnome app is broken (as is most).
Put your device in discover mode
# hcitool scan Scanning ... XX:XX:XX:XX:XX:XX Microsoft Bluetooth Notebook Mouse 5000 # hidd --connect XX:XX:XX:XX:XX:XX
Mouse / device should now work until it sleeps.
The only problem is finding which 11.1 rpm contains hidd... According to a openSUSE forum post , it was removed several versions ago and has not been put back in.
Most of the HOWTOs linked from the Bluez.org Wiki apply pretty well to recent openSUSE releases, so unless we have more extensive documentation here, it might be a good idea to read those.
Bluetooth audio is working now smoothly in 11.2 . HOWTO to get things going is available here.
Activating / deactivating bluetooth
To save energy on a laptop and to be protected against bluetooth hacks, the bluetooth module should be enabled only when needed. Use the Fn-key combination (e.g. Fn + F5, depending on your laptop model) to switch it on/off.
- Note that in 11.1, the KDE input wizard is not working correctly. Please use the bluetooth-applet (package bluez-gnome) for now. This might not work. OpenSUSE 10.3 Bluetooth works reliably. 11.1 does not.
- How to connect your input devices using kinputwizard. This might not work.
- More good information is on the Bluez Wiki Input Devices HOWTO Page. This page assumes a working knowledge of DBus utilities and python programming.
RFCOMM Devices (aka "Dialup")
- How to setup rfcomm devices.
There is a bug in in 10.3 where the hidd command has been disabled , and you are not able pair bluetooth devices. See bugzilla [] This was not a problem in 10.2. To work around this, do not enable bluetooth from YaST. Re-install Gnome bluetooth packages as well as KDE Kinputwizard. run gnome tools from the control panel, and use kinputwizard to pair your device. Once paired you can use gnome bluetooth applet as per normal.
For 10.3, you can grab an updated bluez-gnome package from GNOME:Community. This will allow you to pair and connect input devices. Install gnome-vfs-obexftp in order to browse obex serving devices.
Pairing the devices in Gnome
The pairing of the bluetooth (BT) devices is a communication procedure. In our case between the BT controller and a BT device.
The standard procedure comprises:
- controller scans for available devices
- user choose the device to pair with
- controller and device exchange the PIN
If the device has an input/output capabilities the user can type the PIN. The communication between the BT controller and the user goes through the dbus and gnome BT applet bluetooth-applet .
If the device has not an input/output capabilities either default PIN 0000 is used or in worse case an fixed PIN different from the default is used.
The functionality to recognize the type of the BT device must be provided. Either default (or any other prepared) PIN is send or the user is asked via the gnome BT applet bluetooth-applet for the PIN.
The Bluetooth LED on my laptop is off
(sudo hcitool scan says: Device is not available: No such device)
Laptops often have a dedicated LED showing the status. E.g. a Lenovo X60s has its Bluetooth hardware indicator between the WLAN and the Num-Lock indicator.
Bluetooth does not work while the LED is off. A Lenovo x60s laptop has a hardware switch below its front edge, which must be pushed to the right-hand side, to enable Bluetooth and WLAN.
If the WLAN-LED is on, but the Bluetooth-LED remains off, try hitting Fn-F5. This is sometimes needed after suspend/resume.
Can I use the hcitool utility to pair or connect the bluetooth device?
The hcitool provides the user with the capability to communicate on the low-level with the bluetooth (BT) device. Unfortunately this utility is not supposed to be used for pairing or connecting the BT devices from the command line. The package bluez-test comprises small program written in python /usr/bin/simple-agent which can be used for this purpose. The /usr/bin/simple-agent is a text file. The complexity of the pairing or connecting the BT device can be seen from the content of this file. While the /usr/bin/simple-agent and other programs from the bluez-test package are not in production state it is recommended to use them for testing and development purposes only. The production desktops user is supposed to use the bluetooth-applet from the bluez-gnome package to communicate with the BT devices. From the upstream mailing lists I deduce that it can not be expected that this situation is going to be changed.
But the hcitool utility can be used to view information and status of the BT devices.
Scan for visible BT devices:
box:/ # hcitool scan Scanning ... 00:04:61:82:92:AB Printer Adapter 8292AB 00:1E:3D:F7:74:C4 my.other.box 00:1B:59:15:D9:A6 my.phone
List connected BT devices:
box:/ # hcitool con Connections: < ACL 00:1B:59:15:D9:A6 handle 12 state 1 lm MASTER AUTH ENCRYPT
Show link quality of connected BT device:
box:/ # hcitool lq 00:1B:59:15:D9:A6 Link quality: 255
The system sees the BT keyboard/mouse as usb devices in HID mode, how do I switch to HCI mode ?
Blueooth (BT) keyboard/mouse sets are equipped with proprietary usb bluetooth dongle and works as a standard usb keyboard/mouse from the computer point of view. After the startup the usb dongle is running in the "Human interface device" (HID) mode. This behaviour enables to use the BT keyboard/mouse with BIOS only. Then, when the system is booted and the bluetooth subsystem is operational the usb dongle can be switched to to the "Host Controller Interface" (HCI) mode. Then the usb dongle operates as a BT controller and the keyboard/mouse are connected to the system as BT devices. The utility hid2hci should cover the whole transfer, but it works only for a couple of devices (just reported, I have seen none). Generally I have seen either the BT keyboard/mouse is used in the HID mode with the proprietary usb bluetooth dongle or the BT keyboard/mouse is used as a secondary input coupled to other bt HCI controller (typically notebook).
How can I analyze the bluetooth protocol.
If you want to analyze the bluetooth protocol you can use hcidump and wireshark. For example to see the BT device responding to hcitool scan command do the following:
- put the BT device into the pairing mode
- as a root issue command hcidump -t -w test
- as a user issue command hcitool scan; wait for the command to complete
- stop the hcidump -t -w test with Ctrl-C
- start wireshark and open the test file.
I can't get my mouse working.
The mouse has to be put into the "pairing mode". To put a bluetooth device into the pairing mode means:
"The process of establishing a new relationship between two Bluetooth enabled devices. During this process a link key is exchanged (either before connection establishment was requested or during connecting phase)."
as described in . How to put into the "pairing mode" your specific device shall be described in the manual. If you need help with putting the mouse into the pairing mode post the model of the mouse and attach the manual if possible.
To solve this problem we have to be sure that the mouse can be seen. We need the following information.
- check the output of # hciconfig -a (to be sure, that the adapter is working)
- then put the mouse into the pairing mode (otherwise the mouse can not be seen)
- check the output of # hcitool scan (to check that the adapter sees the mouse)
The BT_ADDR of your mouse shell be listed in the output in step 3. If the mouse is not listed then try with other mouse to rule out the HW problem.
Problems with the Dell mouse
Some bluetooth Dell mice come with a dongle that acts as a HID device when the comupter is starting. Then udev turns the HID dongle into the HCI bluetooth adapter with the command hid2hci. There are not enough information about the Dell mice to treat them separately by IDs and the udev rule bluetooth-hid2hci.rules is triggered by the common ID_VENDOR==413c comparizon. But when Dell usb mouse [413c:3010] connected with the cable is used the udev rule triggers the hid2hci command with the [413c:3010ii] selector and renders the mouse unusable. With this udev rule disabled bluetooth Dell mice will not switch from HID to HCI mode automaticaly, but can be switched manualy. The HID to HCI switching is not a reliabe process and disabling this udev rule could avoid other problems. Once the Dell mice are properly identified the rule bluetooth-hid2hci.rules can be enhanced with the list of mice the same way as other vendors did. for details reffer to bnc 614526.
openSUSE bluetooth HW compatibility.
Sometimes can happen that the bluetooth device implements the bluetooth protocol in a different way than it is expected from the bluez.org developers. This is the list of known problems. Each record contains a bugzilla.novell.com bug number where more details can be found.
|microsoft bluetooth notebook mouse 5000||setup new device wizard found the mouse but failes to connect||The mouse tries to re-use the previous connection and
request to connect with the old l2cp channel ID (CIDD). The HCI refuses to connect with the message "Connection refused - no resources available" which means there is no more such a CIDD cached in HCI. The mouse could try to establish new connection but it does not.
|MoGo Mouse BT. Model MG100. (http://www.mogomouse.com)||turning the mouse off and back on to break the connection||When the mouse is switched off it does not send disconnect request to the controller. Thus the controller is waiting and disconnects after the 20s time
out. Even when the mouse is switched on within this 20s no packets can be seen. The mouse is then connected with the standard handshake .