Can't connect Logitech K830 - no PIN prompt [LE]

[Pat McGowan]

Cannot connect a Logitech Illuminated Living Room keyboard to a device running bluez5. There are two versions of the keyboard, a unifying receiver version, and a Bluetooth version. The latter has a BT symbol on the 'del' key. To put the BT version in pairing mode, power on the keyboard, then briefly hold the FN and 'del' key together and release. A green LED at the top right of the keyboard should start flashing quickly.

Once in pairing mode, the device will become visible on desktop using the BT settings UI, however it's *never* shown in the UI on a device running the latest Touch ( OTA9.1+ ). Note, this includes devices running a silo version of bluez 5.37, including both arale and krillin. On both devices, the keyboard *is* viewable using bluetoothctl.

It should be noted that LE keyboard support on touch should be a considered a missing feature.

Here's the reported attributes of the device from my macair running 15.10 + bluez 5.37:

Device DF:08:A9:A0:13:93
  Name: K830
  Alias: K830
  Appearance: 0x03c1
  Icon: input-keyboard
  Paired: yes
  Trusted: no
  Blocked: no
  Connected: yes
  LegacyPairing: no
  UUID: Generic Access Profile (00001800-0000-1000-8000-00805f9b34fb)
  UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
  UUID: Device Information (0000180a-0000-1000-8000-00805f9b34fb)
  UUID: Battery Service (0000180f-0000-1000-8000-00805f9b34fb)
  UUID: Human Interface Device (00001812-0000-1000-8000-00805f9b34fb)
  UUID: Vendor specific (00010000-0000-1000-8000-011f2000046d)
  Modalias: usb:v046DpB335d0010

From bluetoothctl on both my laptop and my desktop, I'm able to pair, trust and connect the device, and info reflects these changes, however the device never actually connects, it's LED remains blinking fast, and the keyboard cannot be used.

Note, before pairing, I issued the command 'agent KeyboardOnly' and 'default-agent'.

[Pat McGowan (pat-mcgowan)]

With test packages for blue5.37 the laptop thinks it successfully paired with the keyboard but the keyboard is unresponsive and does not indicate its paired

I turned the keyboard off and on and when trying to reconnect bluetoothd crashed

[Tony Espy (awe)]

A couple of updates...

 - I've verified that the keyboard is indeed a low-energy device.

 - I'm able to see the device on my MacAir running 15.10 + the latest 5.37 bluez packages both in the indicator, and via bluetoothctl

 - I cannot successfully pair with the device from the indicator or bluetoothctl

 - At some point, 'bluetoothctl info' shows that the device is paired & connected, however the keyboard BT indicator is still blinking, which means the keyboard is still in pairing mode, and it cannot be used.

 - When I attempt to connect using gattool, I get the following error:

Attempting to connect to DF:08:A9:A0:13:92
Error: connect error: Transport endpoint is not connected (107)

I also see the following error messages in my syslog:

Jan 25 12:06:24 shrike bluetoothd[949]: Unable to register GATT service with handle 0x0046 for device DF:08:A9:A0:13:92
Jan 25 12:06:24 shrike bluetoothd[949]: Report Map read failed: Attribute requires authentication before read/write
Jan 25 12:06:24 shrike bluetoothd[949]: Protocol Mode characteristic read failed: Attribute requires authentication before read/write
Jan 25 12:06:24 shrike bluetoothd[949]: HID Information read failed: Attribute requires authentication before read/write
Jan 25 12:06:25 shrike bluetoothd[949]: Read Report Reference descriptor failed: Attribute requires authentication before read/write

 - I was able to use the device with my new iMac, which is running El Capitan. When I pair the keyboard, I'm prompted for a PIN code.

So, it looks like PIN authentication isn't being handled properly for this keyboard.

[Tony Espy (awe)]

Also, I have yet to be able to reproduce the crash...

[Pat McGowan (pat-mcgowan)]

In comment #3 I should have mentioned that prior to the crash on reconnect, it actually prompted me for a PIN code that the UI generated, and the keyboard stopped blinking although it did not work with the laptop. I was never again able to get the pin prompt in a number of retries at pairing.

[Tony Espy (awe)]

Added a task for ubuntu-system-settings as LE devices aren't considered at all by Bluetooth settings.

[Simon Fels (morphis)]

I went again through the logs and came across the following:

 [ 1044.196326] Bluetooth: SMP security requested but not available

which is then followed by a lot messages like:

 Jan 20 08:53:28 samsung930X3G bluetoothd[3988]: Report Map read failed: Attribute requires authentication before read/write
 Jan 20 08:53:28 samsung930X3G bluetoothd[3988]: Error reading Report value: Attribute requires authentication before read/write

What this basically means is that the security checks inside the kernel stack failed and we couldn't build a secured and trusted connection which then in the end means the mouse wont connect properly and fails to work.

There is already an upstream bug about this problem at https://bugzilla.kernel.org/show_bug.cgi?id=104011 sadly without an solution other than reverting the change on the kernel side introduced this problem.

@Pat: You're seeing this with your MX4 right? I will build a kernel then for it which has the suggested kernel side change reverted just to see if that helps us in this particular situation.

[Simon Fels (morphis)]

Ok, there seems to be another problem I didn't respected yet. Powering a controller with hciconfig will bring it into a state where not all subsystems are initialized required for LE support. We still have a udev rule in our bluez package included which will try to power a bluetooth controller via hciconfig which is really not what we should do as described before. Starting with bluez 5.35/.36 there is a new option bluez itself provides for this which defines a config element in /etc/bluetooth/main.conf to do the same but the right way.

I am not sure if this udev rule comes into our way here but it feels a bit like it does.

@Pat/Tony: Would be good if you can try the following:

sudo mount -o remount,rw /
sudo rm /lib/udev/rules.d/50-bluetooth-hci-auto-poweron.rules
echo "[Policy]" >> sudo tee -a /etc/bluetooth/main.conf
echo "AutoEnable=true" >> sudo tee -a /etc/bluetooth/main.conf

I've also pushed this change up at https://code.launchpad.net/~bluetooth/bluez/fix-ctrl-enablement-on-detection as that is something we need to fix anyway.

If that doesn't help also try removing all bluetooth state information by

sudo rm -rf /var/lib/bluetooth/*

and then reboot the device.

[Pat McGowan (pat-mcgowan)]

I tried the instructions in comment #9 with a smart mouse, the mouse was not visible in the UI, and I could not pair it (authentication failed) in bluetoothctl

[Simon Fels (morphis)]

@Pat: Did you saved any logs from that attempt?

[Launchpad Janitor (janitor)]

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

[Pat McGowan (pat-mcgowan)]

Tried the above settings with the test kernel, the indicators and settings tell me bt is off.
Note that the echo did not take effect and I manually edited the main.conf file

[Pat McGowan (pat-mcgowan)]

phablet@ubuntu-phablet:~$ hciconfig -a
hci0: Type: BR/EDR Bus: UART
 BD Address: 38:BC:1A:18:B5:CD ACL MTU: 1021:8 SCO MTU: 244:4
 DOWN
 RX bytes:778 acl:0 sco:0 events:52 errors:0
 TX bytes:3483 acl:0 sco:0 commands:52 errors:0
 Features: 0xbf 0x3e 0x8d 0xfe 0xdb 0xff 0x5b 0x87
 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
 Link policy: RSWITCH SNIFF
 Link mode: SLAVE ACCEPT

phablet@ubuntu-phablet:~$ sudo hciconfig hci0 up
phablet@ubuntu-phablet:~$ hciconfig
hci0: Type: BR/EDR Bus: UART
 BD Address: 38:BC:1A:18:B5:CD ACL MTU: 1021:8 SCO MTU: 244:4
 UP RUNNING
 RX bytes:1423 acl:0 sco:0 events:85 errors:0
 TX bytes:4183 acl:0 sco:0 commands:85 errors:0

Now its up but it does not see the mouse in pairing mode

[Pat McGowan (pat-mcgowan)]

log while trying to pair the mouse

[Simon Fels (morphis)]

@Pat: One important thing: Don't use hciconfig up <dev> anymore. Even if its still there and works to some degree that will only initialize the controller partly as its using an old kernel API. Use bluetoothctl only to power on/off bluetooth:

$ bluetoothctl
[bluetooth]# power on
Changing power on succeeded

As in this case you don't see an LE device this comes from the fact that we power on bluetooth via hciconfig.

[Pat McGowan (pat-mcgowan)]

Unduping to track the lack of the PIn prompt specific to this bug

[Pat McGowan (pat-mcgowan)]

Working with updated bluez in silo 68

Settings needs to now look for the characteristic "appearance" rather than class for devices that support the Generic Access Profile. The BLE device reports appearance as 0x03c1 or 961 which is HID keyboard per
https://developer.bluetooth.org/gatt/characteristics/Pages/CharacteristicViewer.aspx?u=org.bluetooth.characteristic.gap.appearance.xml

[Konrad Zapałowicz (kzapalowicz)]

@Pat

you may want to try silo 60 - it shall enable displaying BLE devices on the u-s-s level.

[Pat McGowan (pat-mcgowan)]

After forgetting the device and rebooting, the BLE keyboard was discovered and paired using a pin prompt dialog.

Prior to rebooting I saw some odd behavior such as prompt dialog not going away or the discovery not happening. But this silo is a great improvement.

[Konrad Zapałowicz (kzapalowicz)]

Fix for U-S-S is merged: https://code.launchpad.net/~kzapalowicz/ubuntu-system-settings/ubuntu-system-settings/+merge/301370