I'm trying to pair my RasPi with the new Microsoft Universal Foldable Keyboard, which requires BT 4.0 LE HCI connectivity from the host. On my Pi it is provided by CSR based Bluetooth 4.0 dongle. Scanning works, but pairing and connecting don't. What goes wrong?

How things stand currently

I'm running Raspbian on a Pi 2, with the latest raspberrypi-bootloader/kernel allowed by my Adafruit PiTFT (1.20150904-1) and BlueZ 5.34 stack.

hcitool lescan recognizes the keyboard when it's set in pairing mode.

C4:E0:1E:08:DC:D3 UniversalFoldableKb
C4:E0:1E:08:DC:D3 (unknown) 

but when I try the pairing command bluez-simple-agent hci0 C4:E0:1E:08:DC:D3, while having plain bluez-simple-agent running in another session on the Pi, it merely states:

Creating device failed: org.bluez.Error.ConnectionAttemptFailed: Page Timeout

At the same time hcidump gives:

2015-09-19 02:02:31.779409 > HCI Event: Command Status (0x0f) plen 4 Create Connection (0x01|0x0005) status 0x00 ncmd 1
2015-09-19 02:02:36.902080 > HCI Event: Connect Complete (0x03) plen 11
status 0x04 handle 0 bdaddr C4:E0:1E:08:DC:D3 type ACL encrypt 0x00
Error: Page Timeout

My understanding is the bluez-simple-agent doesn't know that it's supposed to use the HID-over-GATT (LE HID) profile. There might be other factors too, see Other experiments below for secondary indications.

There was a curious message while checking dmesg

Bluetooth: SMP security requested but not available

which might indicate a separate problem with BT devices after updating raspberrypi-bootloader and kernel from 3.18 to whatever's in the 1.20150904-1 package. I don't know if these things are related.

Other experiments

After a precautionary hcitool hci0 down; hcitool hci0 up, hcitool leinfo states Could not create connection: Connection timed out. hcidump shows:

2015-09-19 02:14:03.593773 > HCI Event: Command Status (0x0f) plen 4
LE Create Connection (0x08|0x000d) status 0x00 ncmd 1

And apparently something hangs, because now I have to cycle the interface to have anything work again. Same with hcitool lecc, the connection just times out without any extra information and the interface must be cycled to recover it.


Please let me know if I've overlooked some log or some other such resource - I will then update my question with the relevant bits.

3 Answers 3


The message you have seen in dmesg:

Bluetooth: SMP security requested but not available

this is a known kernel issue and this is fixed in the Raspberry Pi Kernel with this commit: https://github.com/raspberrypi/linux/commit/d8949aad3eab5d396f4fefcd581773bf07b9a79e

In the current noobs install you have kernel 4.1.19 that does not yet contain the fix, but you can perform a kernel upgrade running


You will get a update to a kernel that contains the fix (in my case it was 4.4.7).

This should remove the dmesg error message.

To get the keyboard running I uninstalled gui-bluetooth modules and restarted the PI to work only with bluetoothctl.

[bluetooth]# agent KeyboardDisplay   
[bluetooth]# default-agent   
[bluetooth]# scan on   
[bluetooth]# scan off   
[bluetooth]# pair <device> 

This time bluetoothctl should show you the password that you needed to type in on the keyboard (+ return). After pairing your can connect and trust the device as usual and you should be able to type on the MS Foldable Keyboard.

  • I am running in exactly the same issue, but I already have !conn->smp check right before l2cap_chan_lock. Function smp_ready_cb (which sets conn->smp) is still called ~100-200 us too late and therefore smp_conn_security prints error "SMP security requested but not available". Is there any way to delay a bit?
    – Bojan P.
    Commented Apr 13, 2020 at 21:25

The other answers didn't work for me, so after going on a wild goose chase and compiling bluez from source (which didn't work) I reverted back to bluez 5.23-2+rpi2, and I remembered reading that adding the --experimental parameter to bluez enables Bluetooth LE support. So I edited /etc/systemd/system/dbus-org.bluez.service and added --experimental to the end of the ExecStart line, rebooted the Pi, and found that I could then pair using bluetoothctl.

I have since switched to Raspbian testing (stretch) and found that I needed to downgrade bluez to the same version in order for my keyboard to keep working.


I ran into similar problems using the rpi 3 and found the following:

I tried to use blueman to set up the keyboard but while it found the device and attempted to connect, it failed.

Instead I used bluetoothctl from the cm:

pi@raspberrypi:~ $ bluetoothctl
[NEW] Controller B8:27:EB:98:79:A3 raspberrypi [default]
[NEW] Device 28:18:78:F9:03:5C Universal Mobile Keyboard

[bluetooth]# power on
Changing power on succeeded
[bluetooth]# agent on
Agent registered
[bluetooth]# scan on
Discovery started
[CHG] Controller B8:27:EB:98:79:A3 Discovering: yes
[CHG] Device 28:18:78:F9:03:5C RSSI: -59
[CHG] Device 28:18:78:F9:03:5C RSSI: -82
[CHG] Device 28:18:78:F9:03:5C RSSI: -55

Once i confirmed the address of the keyboard I tried to connect to it:

[bluetooth]# connect 28:18:78:F9:03:5C
Attempting to connect to 28:18:78:F9:03:5C
[CHG] Device 28:18:78:F9:03:5C Connected: yes
[CHG] Device 28:18:78:F9:03:5C Modalias: usb:v045Ep0802d0092
[CHG] Device 28:18:78:F9:03:5C UUIDs:
[CHG] Device 28:18:78:F9:03:5C Connected: no
Failed to connect: org.bluez.Error.Failed

But this failed too!

I then tried to pair the device:

[bluetooth]# pair 28:18:78:F9:03:5C
Attempting to pair with 28:18:78:F9:03:5C
[CHG] Device 28:18:78:F9:03:5C Connected: yes
[agent] Passkey: 038594
[agent] Passkey: 038594
[agent] Passkey: 038594
[agent] Passkey: 038594
[agent] Passkey: 038594
[agent] Passkey: 038594
[agent] Passkey: 038594
[CHG] Device 28:18:78:F9:03:5C Paired: yes
Pairing successful
[CHG] Device 28:18:78:F9:03:5C Connected: no

I then tried to connect again and this time it worked :-)

[bluetooth]# connect 28:18:78:F9:03:5C
Attempting to connect to 28:18:78:F9:03:5C
[CHG] Device 28:18:78:F9:03:5C Connected: yes
Connection successful

Finally I set the device to be trusted:

[bluetooth]# trust 28:18:78:F9:03:5C
[CHG] Device 28:18:78:F9:03:5C Trusted: yes
Changing 28:18:78:F9:03:5C trust succeeded

It must be working OK as I'm using the BT keyboard to type this!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.