zero out LESC and KEYPRESS fields in PAIRING REQUEST PDU if peer's BLE verison is not 4.2

[tiamo]

currently(sdk_12.1.0_0d23e2a, s132_nrf52_3.0.0_softdevice), nrf52832 can't pairing with windows 10.1607(build 14393.479), if we set lesc bit in ble_gap_sec_params_t.

windows' bluetooth stack does not support BLE4.2, it interprets the AuthReq byte in pairing request pdu as a whole byte, assuming that the upper 5bits are all 0s, means that the max valid value for AuthReq is 5, windows uses IOCaps and this byte instead of the MIMT bit to select pairing method (popup a dialog to let user input passkey or display a passkey to user). so if we set LESC bit, the AuthReq would be 0x0d(with MIMT and BONDING), windows would interpret it as an invalid value, and select the default pairing method 'Just Works', and pairing failed.

yes, it is a bug, m$ should fix it.

but we can zero out LESC and KEYPRESS fields in PAIRING REQUEST PDU in the first place if peer's BLE version is not 4.2, we knows peer's version in LL_VERSION_IND pdu, 0x08 means BLE4.2

[tiamo]

currently we can call pm_sec_params_set in BLE_GAP_EVT_SEC_PARAMS_REQUEST event with lesc bit cleared if peer's lesc is not set.

note that pm_sec_params_set should be called before pm_on_ble_evt

[Jørgen Holmefjord]

Hi tiamo,

Was this intended as information to other users, or did you have a question? As you say, this is a bug in Win10, and should be fixed by MS. This is not something we can easily workaround. Note that it is possible to have different versions on the different layers of BLE, so your fix might not always work for all hardware/drivers. LL_VERSION_IND is dependent on both drivers and hardware.