[QN9090]How to auto pair again to an peripheral which used to be bonded but removed from peripheral?

[yyjdelete]

I tried example `hid_device_freertos` and `hid_host_freertos` in qn9090 sdk 2.6.11 with 2 qn9090 boards, and I just modify the device example to add the below code right after `BleConnManager_GapCommonConfig()` to simulate the bond was removed on the peripheral side.

```

Gap_RemoveAllBonds();
Gap_ClearWhiteList();

```

Step:

1. Flash device and host;

2. Run for the first time, see host bond with device.

3. Reset only the device( to make the bond info in peripheral be removed)

4. See the host connect to the device but failed again and again.

Expected:

The host should auto pair and bond to device again.

Actual:

Always failed.

It's also strange seems there is already some code to handle `gConnEvtPairingNoLtk_c`, and `Gap_SendSlaveSecurityRequest` does success on device side, but I never receive `gConnEvtSlaveSecurityRequest_c` from host side in the case.

```

case gConnEvtPairingNoLtk_c:
{
#ifndef gCentralInitiatedPairing_d
/* Slave does not have the LTK for peer Master. Re-initiate pairing. */
res = Gap_SendSlaveSecurityRequest(peerDeviceId, &gPairingParameters);
PRINTF("Gap_SendSlaveSecurityRequest from gConnEvtPairingNoLtk_c: %d\n", res);
#endif
}

```

Logs:

Device(peripheral) side:

```

BleApp_ConnectionCallback: 0x0(gConnEvtConnected_c)
Gap_SendSlaveSecurityRequest from gConnEvtConnected_c: 0(gBleSuccess_c)

BleApp_ConnectionCallback: 0x13(gConnEvtLeDataLengthChanged_c)

BleApp_ConnectionCallback: 0x1A(gConnEvtPairingNoLtk_c)
Gap_SendSlaveSecurityRequest from gConnEvtPairingNoLtk_c: 0(gBleSuccess_c)

BleApp_ConnectionCallback: 0xD(gConnEvtDisconnected_c)

BleApp_GenericCallback: 3(gAdvertisingParametersSetupComplete_c)
BleApp_GenericCallback: 4(gAdvertisingDataSetupComplete_c)
BleApp_AdvertisingCallback: 0(gAdvertisingStateChanged_c)

...(REPEAT)...

```

Host(Central) side:

```

BleApp_ConnectionCallback: 0x0(gConnEvtConnected_c)

BleApp_ConnectionCallback: 0x13(gConnEvtLeDataLengthChanged_c)

BleApp_ConnectionCallback: 0x4(gConnEvtAuthenticationRejected_c)
BleApp_ConnectionCallback: 0xD(gConnEvtDisconnected_c)
BleApp_ConnectionCallback: 0xC(gConnEvtPairingComplete_c)

BleApp_ConnectionCallback: 0x0(gConnEvtConnected_c)

...(REPEAT)...

```

[yyjdelete]

Infact, central has no event for this.

Finally, it works well after I remove `Gap_SendSlaveSecurityRequest`(the one in `case gConnEvtPairingNoLtk_c`, not the one in `case gConnEvtConnected_c`) in `BleConnManager_GapPeripheralEvent`, central will send a new pair request after be rejected.

I tried to capture with nRF BLE sniffer and wireshark, and found that for some unknown reason, the below pkg will be send from peripheral to central only if I removed the `case gConnEvtPairingNoLtk_c`?

@Gavin_Jia @Christine_Li  >Is this a bug for qn9090 BLE sdk?

```
Control Opcode: LL_REJECT_EXT_IND (0x11)
Reject Opcode: LL_ENC_REQ (0x03)
Error Code: PIN or Key Missing (0x06)
```

[Christine_Li]

Hi, @yyjdelete 

Thanks for your feedback.

It sounds like a bug(on the surface), but I prefer to test it on my local side.

If I can also reproduce it then I will create an internal case to confirm whether is a bug or as designed.

Best regards,

Christine.

[Christine_Li]

Hi, @yyjdelete 

For right now, we don't have BLE sniffer capture to get OTA logs.

Can you please help to provide the full HCI and OTA logs for both success and failed scenarios?

And also please help to make sure there is no other changes in Central side(host side.) We can compare it together to see whether this "Gap_SendSlaveSecurityRequest" has influence on re-pairing.

Best regards,

Christine.

[yyjdelete]

1. no changes on host side. (source attached, can see git commit logs for details)
2. not sure how to get a hci log with qn9090, will try to see if I can make a capture with my android phone as host and qn9090 as device later.

[Christine_Li]

Hi, @yyjdelete 

BT HCI log using the bt_snoop definition , you can enable BT log in app_config.h.

Thanks for your corporation.

If you can provide HCI log and synced time with OTA logs , will be much appreciated!

Best regards,

Christine.​

[Gavin_Jia]

Hi @yyjdelete ,

Thanks for your patience.

The behavior you are presenting is the expected one according to the source code of the hid_host application. In fact, the SDK examples are the only simple examples that are designed for specific use cases. If you modify the use case (i.e. adding support for bonding info removal), then you should update the application code accordingly.

Regarding the HID example, it is very basic about the bonding table management, and it is not coded to remove devices from it. If you modify the peripheral behavior (hid_device), then you should also modify the host side accordingly. In fact, if you look at the `BleApp_ConnectionCallback() ` function in hid_host.c, you will see that it will automatically try to encrypt the connection, and will never remove the bond if it fails.

So, what you should do is:

• Catch the "gConnEvtPairingNoLtk_c" event and add the code to remove the device from the bonding table on the master side,
• Then, restart the pairing.

Hope you are doing well!

Best regards,

Gavin

[Christine_Li]

Hi, @yyjdelete 

Based on Gavin's answer, do you have any other queries on this ticket?

Best regards,

Christine.