Introduction

This change is needed in order to be able to choose the type of OOB pairing(legacy vs SC) over bluetooth in regards to a device's capabilities.

Problem description

Some systems can support only legacy OOB pairing while others only LE SC OOB pairing.
Since there is only one OOB presence flag, no distinction is made between these two in the current code, and some pairing incompatibilities arise.
For example a device that has SC=1 and only supports legacy OOB pairing, will trigger LE SC OOB pairing, which it doesn't support.

Proposed change

A new API function bt_set_legacy_oob_data_flag will be added for devices to signal the OS that they are capable only of legacy OOB pairing.
The existing API function bt_set_oob_data_flag will change its name to bt_set_lesc_oob_data_flag and it will be used to inform the OS that the device is capable of doing LE SC OOB pairing.
The code will now advertise the OOB flag depending on the state SC flag and what type of OOB pairing it supports.
Thus a correct pairing method decision will be taken.

Detailed RFC

New function, bt_set_legacy_oob_data_flag will set legacy_oobd_present bool flag in order to inform OS that device supports legacy OOB pairing.

Function bt_set_lesc_oob_data_flag (renamed from bt_set_oob_data_flag) will set le_sc_oobd_present bool flag in order to inform OS that device supports LE SC OOB pairing.

The code will set OOB flag in advertise info in the following cases:

• SC==1 && le_sc_oobd_present==1
• SC==0 && legacy_oobd_present==1

When deciding the pairing method:

• in case of legacy pairing, legacy OOB pairing will be chosen if both of devices have OOB flag advertised
• in case of SC pairing, LE SC OOB pairing will be chosen if at least one device has advertised the OOB flag

Dependencies

API change affects also the BT console code

Concerns and Unresolved Questions

• change was not tested on this OS version(but on v2.2.1)

Alternatives