I am running Debian Sid with the following bluetooth-related packages installed:
blueman 2.0.4-1
bluetooth 5.43-1
bluez 5.43-1
bluez-firmware 1.2-3
firmware-misc-nonfree 20161130-2
gnome-bluetooth 3.20.1-1
I am trying to connect Microsoft Surface Ergonomic Keyboard, without much success. Any help would be appreciated! Below, please find the details about my conundrum.
gnome-bluetooth
gnome-bluetooth detects the keyboard but cannot connect to it. Upon clicking the discovered device, gnome-bluetooth quickly reverts to Not Set Up.
Sometimes, and I have yet to figure out when, gnome-bluetooth does prompt a PIN key for connection. Most of the time, the connection drops before I can type the key on the keyboard.
Rarely, gnome-bluetooth does manage to connect to the keyboard. Within a minute, however, it bugs out, rapidly going back and forth between Connected and Not Set Up.
hcitool
hcitool scan does not turn up any result, and nor does hcitool inq.
bluetoothctl
With scan on, bluetoothctl discovers the keyboard. The following errors occur, however:
Entering pair directly after discovery shows the following:
Attempting to pair with [mac address]
[CHG] Device [mac address] Connected: yes
Failed to pair: org.bluez.Error.AuthenticationFailed
[CHG] Device [mac address] Connected: no
Entering trust [mac address] before pairing results in the same error message.
Entering pairable on before pairing results in the same error message.
Entering connect [mac address] shows the following:
[CHG] Device [mac address] Connected: yes
Failed to connect: org.bluez.Error.Failed
[CHG] Device [mac address] Connected: no
Entering trust or pairable before using connect results in the same error message.
Tracing the error in syslog
This, I believe, is the relevant log:
dbus-daemon[1068]: Activating via systemd: service name='org.bluez.obex' unit='dbus-org.bluez.obex.service'
dbus-daemon[1068]: Activating via systemd failed for unit 'dbus-org.bluez.obex.service': Unit dbus-org.bluez.obex.service not found.
blueman.desktop[1381]: ERROR:dbus.connection:Exception in handler for D-bus signal:
blueman.desktop[1381]: Traceback(most recent call last):
blueman.desktop[1381]: File "/usr/lib/python3/dist-packages/dbus/connection.py", line 230, in maybe_handle_message
blueman.desktop[1381]: self._handler(*args, **kwargs)
blueman.desktop[1381]: File "/usr/lib/python3/dist-packages/blueman/bluez/PropertiesBlueZInterface.py", line 55, in wrapper
blueman.desktop[1381]: handler(name, value, **kwargs)
blueman.desktop[1381]: File "/usr/lib/python3/dist-packages/blueman/plugins/applet/GameControllerWakelock.py", line 36, in on_device_property_changed
blueman.desktop[1381]: klass = Device(path).get_properties()["Class"] & 0x1fff
blueman.desktop[1381]: KeyError: 'Class'
According to this blueman bugreport, your syslog shows a bug in the GameControllerWakelock plugin that causes blueman to crash, which is probably the reason why the GUI bugs around. You can disable that plugin, or update to a newer version of blueman to fix that. (For example by installing 2.1-alpha)
However, disabling the plugin will probably not fix your connection problems, only the GUI. The Authentification Error mentioned usually means that the PIN is wrong. The bug report also mentions that they implemented a PIN database that would probably land in 2.1, so upgrading might actually be worth a shot. If your keyboard is not yet in the PIN database, I would propose you create an issue on blueman github and talk to the guys there!
I had a similar problem, I couldn't connect it to Ubuntu 16.04.
In the end, searching and gathering different solutions I got this:
Open in terminal:
bluetoothctl
agent KeyboardDisplay
pairable on
discoverable on
scan on
(search for the MAC of your keyboard)
scan off
pair MAC:of:your:keyboard
(hopefully you will have to give the passkey that will appear in terminal. Write it and then hit the Enter key)
I hope it helps.
Related
Bluetoothctl shows my WF-1000xm3 ear phones connected. But, the earphones do not give the accoustic feedback 'bluetooth connected' and also sound does not work.
Below is the output of bluetoothctl.
$ bluetoothctl connect 14:3F:A6:81:00:38
Attempting to connect to 14:3F:A6:81:00:38
[CHG] Device 14:3F:A6:81:00:38 RSSI: -56
[CHG] Device 14:3F:A6:81:00:38 Connected: yes
Connection successful
I use EndeavourOS and installed PipeWire. The troubleshooting section of the Arch's PipeWire Wiki (https://wiki.archlinux.org/title/PipeWire), covers the problem "No sound after connecting to Bluetooth device". It refers to a udev script (https://gist.github.com/tinywrkb/04e7fd644afa9b92d33a3a99ab07ee9e), from which I copied this terminal comand
(pactl list sinks|grep Name|grep 'bluez.*.a2dp.sink'|sed 's/Name: //'|sed 's/\s//')
Which did not show any available devices.
Any idea, what the issue might be?
I'm using BlueZ 5.49 and trying to connect, pair, and pass information between two different bluetooth devices.
It's seems like i have problem with enforcing security and authentication between the two.
I'm configuring each hci device with:
hciconfig hci0 pscan auth encrypt which as i read, is setting the device to security mode 3.
In addition i'm creating manualy this path in both sides: /var/lib/bluetooth/<local_bdaddr>/<remote_bdaddr>/info with LinkKey.
I've noticed that if i'm creating the path for only one device, and then trying to connect using rfcomm connect from the device without the infofile, the connection succeed, even though the device is lacking the info file which containts the LinkKey.
If i'm trying rfcomm connect from the device with the info file i'm getting Key Exchange Error, which is acceptable since the other device doesn't have the key.
My base line is that it seems that security and authentication are not enforced.
Many Thanks,
Liad
Apparently hci device is by default set to work in Secure Simple Pairing also known
as sspmode. Simple Pairing originaly generated to support devices that can't insert pin code during pairing process (such as headset).
Hence when a device is in sspmode enabled, it use a default pin key - say 0000, and then based on the pin, generating LinkKey to encrypt and authenticate, and thus not truely enforcing authentication as i mentioned before.
The line hciconfig hci0 sspmode disable is disabling the Secure Simple Pairing mode, and finally enforce authentication using the static LinkKey you supply
in the info file which located in /var/lib/bluetooth/<your_mac>/<remote_mac>/info.
I'm trying to set up a connection to a Bluetooth 4.0 LE device on Linux using the BlueZ 4.X DBus interface.
To test this I use the following command:
dbus-send --system --dest=org.bluez --print-reply /org/bluez/<PID of bluetoothd>/hci0 org.bluez.Adapter.CreateDevice string:<MAC of BT device>
This command seems to work most times, giving a result like:
method return sender=:1.238 -> dest=:1.262 reply_serial=2
object path "/org/bluez/9652/hci1/dev_BC_6A_29_26_C2_1C"
and enabling me to interact with the device DBus object.
However, starting from yesterday, this seems to fail very frequently returning the following error:
Error org.bluez.Error.Failed: Operation canceled
When debugging the bluetooth daemon, (using bluetoothd -n -d) I notice the following things when executing the method call:
bluetoothd[340]: src/adapter.c:create_device() BC:6A:29:26:C2:1C
bluetoothd[340]: src/adapter.c:adapter_create_device() BC:6A:29:26:C2:1C
bluetoothd[340]: src/device.c:device_create() Creating device /org/bluez/340/hci0/dev_BC_6A_29_26_C2_1C
bluetoothd[340]: src/device.c:btd_device_ref() 0xb7ad8: ref=1
bluetoothd[340]: src/device.c:device_set_temporary() temporary 1
bluetoothd[340]: src/device.c:btd_device_ref() 0xb7ad8: ref=2
bluetoothd[340]: plugins/mgmtops.c:mgmt_event() cond 1
bluetoothd[340]: plugins/mgmtops.c:mgmt_event() Received 14 bytes from management socket
bluetoothd[340]: plugins/mgmtops.c:mgmt_connect_failed() hci0 BC:6A:29:26:C2:1C status 4
bluetoothd[340]: src/event.c:btd_event_conn_failed() status 0x04
bluetoothd[340]: src/device.c:device_remove() Removing device /org/bluez/340/hci0/dev_BC_6A_29_26_C2_1C
bluetoothd[340]: src/device.c:device_set_temporary() temporary 1
bluetoothd[340]: src/device.c:btd_device_unref() 0xb7ad8: ref=1
bluetoothd[340]: src/device.c:btd_device_unref() 0xb7ad8: ref=0
bluetoothd[340]: src/device.c:device_free() 0xb7ad8
As far as I can see, my Bluetooth dongle sends me an error event (status 4) when I try to connect to the device.
However, when I use hcitool ot gatttool to connect to the device, everything works perfectly.
I found that this happens mostly after I try to connect to the device using a different program (i.e cinnamon-settings), and cancel the connection prematurely. I also noticed this with other programs like bluetooth-properties on Angstrom.
My guess is that Bluez sends the wrong HCI commands to my bluetooth dongle in certain conditions. I think this is because the gui programs try to pair with the device instead of just connecting to it, which may cause BlueZ to think my device is a Bluetooth 2.0 device.
Thus far I seemed to be able to resolve this problem by connecting to my BT device using a gui application, waiting till it fails, and restarting my computer. However, the problem seems to reoccur occasionally, making this very painful.
I have seen this problem on systems running both BlueZ version 4.99 and 4.101.
Does anyone know how I can solve this correctly?
It seems like my predictions where more or less correct. After many hours of debugging the Bluetooth daemon I discovered that connecting to BT LE devices without a preliminary scan causes the daemon to try to connect to the device as a BR/EDR device. This is because the daemon's "internal cache" is filled with the EIR information at the time the device is discovered. If this information is not available when connecting to a LE device the CreateDevice method will fail.
A simple solution is to always make sure to discover devices before connecting to them.
The BlueZ 5 API introduction and porting guide also describes this problem, and how it is solved in BlueZ 5:
Bluetooth Low Energy essentially extended Bluetooth addresses with one extra bit, requiring one to always know whether an address is “random” or “public”. This caused issues with the BlueZ 4 API where the address was given to BlueZ in the CreateDevice and CreatePairedDevice calls. Since the parameter didn’t contain any of this extra random/public information bluetoothd had to maintain an internal cache to look up the necessary info. Another complication to the matter is that the BlueZ D-Bus API doesn’t differentiate between traditional BR/EDR devices and LE devices so there are essentially three possible address types: BR/EDR, LE public and LE random.
I need to develop an application with a bluetooth dongle that makes use of the thermometer profile. The thing is that, after succesfully pair and connect with the remote device, whenever I try to run the test-therometer file, I obtain the following error:
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method "RegisterWatcher" with signature "s" on interface "org.bluez.ThermometerManager1" doesn't exist
I have also tested the test-heartrate, and I obtain something similar:
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod: Method "RegisterWatcher" with signature "s" on interface "org.bluez.HeartRateManager1" doesn't exist
I have successfully tested the dongle with bluetoothctl, so I can discard hardware compatibility issues. I'd like to know if I'm missing something while running the tests.
I'm working under ArchLinux x86_64.
We have a custom embedded device that uses Roving Networks' RN240 bluetooth adapter on an RS232 port to communicate with another device via bluetooth. It is working well, but I am attempting to "bulletproof" the management of the bluetooth connection as there is an occasional hiccup and I need to handle these circumstances.
In the flow I'm working on, I put the adapter into Command mode and get back the proper response:
> CMD
< $$$
I am then able to issue commands to it to Get or Set information. One of the things we do is specify which bluetooth device to pair to using these commands. The device may already have a valid pairing, and is set to Auto Master mode. When the device powers up, it may automatically connect to our other bluetooth device (as designed). I need to know if the dongle has paired when I am attempting to perform certain functions.
The command set specification specifically says that when the Get command
> GK
< 1
is sent to the device (to obtain current connection status), it will respond with a "0" for "Not Connected" or "1" for "Connected"
I am occasionally getting a "4" when the device is either connecting or connected, and I've been unable to isolate why. Once I start getting a "4", I keep getting a "4" every time I inquire after that. I have to power down the dongle (ie: reset my test scenario) to get a different behavior.
I've poked through other Advanced User Guides on Roving Networks' website, and googled as many variations as I can think of to find what this status means. It seems when I get back "4", I can no longer control the Bluetooth Adapter as I need to. I would like to know what "4" means, and what I can do to recover the device so I can make it do what I want to!
Thanks! I appreciate any help.
(For reference, here's the page for this adapter, along with links for downloading the command set: Roving Networks RN240 Bluetooth Adapter)
EDIT: I have heard back from Microchip Engineering Support. Their answer was that "4" is an undocumented state, as it shouldn't be visible to the user. "4" means the chip in in a connecting state, and that if the module is getting into this state, it is recommended that the module be rebooted (with the "R,1" command).