BLE OOB - pairing/bonding - local-oob - HCI UART Zephyr issue?


Hi all, Carles,

During the last months I have been doing a lot of research in BLE technologies.

Finally for implementing our use case we came up with the following BLE architecture:

- a Linux embedded device (with Linux Kernel V4.20), more precise a BBB to be used as demonstrator platform before moving to a board with iMX6, running a BLE central application based on the QT BLE framework, as BLE connectivity HW, a Nordic nRF52 DK board is used that runs the RTOS Zephyr (V1.13) HCI_UART SW stack. So between both board there is a HCI_UART connection.

- as demonstrator BLE peripheral I'm using another nRF52 DK board that runs the Zephyr HR peripheral sample applic.

So the BLE central application written in QT C++, monitors the heart rate value that is simulated by the HR peripheral application. 

So far so good...

However I'm now trying to add security to the BLE architecture.

So far QT BLE doesn't explicitly implement any security  for a BLE implementation, in other words no QT API is available (yet?).

My idea is to implement  the BLE pairing outside the QT framework as it is not supported via QT.

However I'm struggling with a number of "things" and possible concepts of OOB when doing the pairing process.

I would love to implement OOB as SSP with possible NFC as method for exchanging OOB info. 

BlueZ on Linux offers a tool like btmgmt.

The idea is before starting implementing code based on this tool or the Bluetooth mgmt socket, to do some fast prototyping with this btmgmt tool in a shell.

However when I run the btmgmt local-oob, I get this output:

So it seems for some reason the HCI stack does not support this.

Could this be related to the Zephyr HCI_UART implementation?

Any help on this topic is very welcome.

More information on the "demonstrator" setup I'm trying to implement is described here:
Hi, I have made a simple BLE setup between two embedded boards both with BLE connectivity. On the Beagle Bone Black with LINUX OS I run a simplified QT BLE central application that connects with a heart rate peripheral application running on a nRF52 DK b...

I would really love to stick to all these technologies (Zephyr/QT BLE/BlueZ) in our BLE design. 

The nRF52 (DK) with the Zephyr as BLE connectivity and as standalone unit for running a peripheral applic based on Zephyr is awesome.

Best regards,



Hi all, Carles,

It seems when trying to set the SSP (Secure Simple Pairing)  via the btmgmt tool  I also get the error message the SSP is not supported for this adapter. 
So it seems when setting up a BLE connectivity with Zephyr HCI_UART, this important "security" capability is not available... 

Also when running the oobtest provided by the BlueZ package, the error message Secure Simple Pairing is NOT supported. Here I do the test on my Ubuntu PC which has 2 BLE adapters the internal one and the external Zephyr HCI_UART/Nordic.

Any idea what is going wrong here? 

Thanks in advance,
Best regards,

Johan Hedberg


On 18 Jan 2019, at 18.20, frv <> wrote:
It seems when trying to set the SSP (Secure Simple Pairing) via the btmgmt tool I also get the error message the SSP is not supported for this adapter.
So it seems when setting up a BLE connectivity with Zephyr HCI_UART, this important "security" capability is not available...

SSP is a BR/EDR feature, whereas Zephyr on Nordic MCUs only supports LE (known as a single-mode controller). So you’re not missing anything essential in this regard. The security feature in LE is called the Security Manager Protocol. On the BlueZ-side you shouldn’t need to enable anything explicitly if you’re running bluetooth (it should do everything necessary for you). If you’re not running bluetooth, or for some other reason want to do things manually, you’d need to enable at least “le” and “sc” with btmgmt.


Johan Hedberg

On 18 Jan 2019, at 21.00, Johan Hedberg <> wrote:
On the BlueZ-side you shouldn’t need to enable anything explicitly if you’re running bluetooth
I meant naturally bluetoothd (stupid auto-correct :)



Hi Johan,

Thanks for clarifying this one out, that is already a great relief. Honestly I'm a little bit stuck with what I want to do about security in my BLE architecture.
So far I was able to combine a number of technologies on different HW boards each running different SW stacks. 
However when trying to start implementing security I'm getting stucked. 

So what I had in mind as proof of concept for my setup:
  • On a BBB running Linux 4.20 I run a BLE central application based on QT BLE SW, connected to this BBB is a nRF52 DK running Zephyr and the hci_uart BLE connectivity stack.
  • On another nRF52 board I'm running the Zephyr  HR demo peripheral application. 
  • The BLE central application can successfully connect to the HR demo application and read out the simulated HR values.

Now I wanted to add security, so far QT BLE has not explicit way of providing this, so I'm having to do it outside the QT BLE stack (unfortunately...).
As I will not have any input or output device for verification, the idea is to implement NFC OOB unless you already say this is not an option. 

So the idea is first to tryout a setup without the NFC functionality for exchanging the data.
Thus my idea was first:
to readout the local OOB of both devices and to exchange them "manually" by running the remote oob command via the btmgmt tool of BlueZ.

However despite the SSP issue I wrongly thought needed to be set. I see that also the btmgmt complains when trying to readout de local oob data.
As mentioned in my previous post, the btmgmt throws an error saying it is not supported to Read Out Local OOB info.

So here ends my story for the moment...

Any "better" idea's how to continue from here.
Honestly I love the concept of the Zephyr BLE connectivity as it allows us to keep on the "open source" BlueZ track. Also being able to use QT for running the BLE stack is a great advantage and speeds up the development work and also the quality of the implementation.
Nevertheless also the Zephyr project is also great way to go in our BLE design we have in mind.  So keep up the good work, we love it!!! 

Thanks in advance for your help on this topic.

Best regards,

Best regards,