[nRF Connect SDK]Force to make pairing(bonding)

[Tim Hwang]

Target nRF52832(nrf52dk_nrf52832)
SDK NCS v2.0.0

I'm testing NCS 2.0 with Android 12.

Making pairing with Android, I call two API when connected.

bt_set_bondable(true);
bt_conn_set_security(conn, BT_SECURITY_L4);

It worked well so far (under Android 11)

BTW Android 12 make trouble security level 1 error.


[log]
00> HS connected
00> HS Connected 4A:B4:CA:22:85:2D (random)
00> Connection parameters updated.
00> interval: 6, latency: 0, timeout: 500
00> Conn params updated: interval 7 ms, latency 0, timeout: 5000 ms
00> Security failed: 4A:B4:CA:22:85:2D (random) level 1 err 2
00> Disconnected: 4A:B4:CA:22:85:2D (random) (reason 34)

Can I have another option to make pairing automatically?

[Tim Hwang]

BT_HCI_2022_0913_150734.zip

Here is snoop log file pf 13Sep2022_B.

For air log, this issue about making pairing so that we don't use stored LTK at that time, I think.
Or please let me know.

[Kenneth]

My suggestion here is to keep experimenting until you find something that works, e.g. for instance try different security level when bonding does it have an effect, don't initiate security request from the peripheral (it should not be necessary if you for instance set that the charactereritics to require a security level, then it should be initiated by the central in any case), go back to a normal ncs example and check if those fail as-is, compare with your project. 

Once you find something that works it will be easier to understand what is causing the issue hopefully.

Kenneth

[Kenneth]

Hello,

I can't find anything wrong with how the peripheral device behave here, so the problem seem to be on the central side. From what I can see from your description some rather old phones show the issue, and it's not a generic Android 12 issue. The problem seem to only occur on first bonding attempt, and the second one works. It only seem to occur after bootup and after scan BT off/on. I can understand that this may be a hazzle for anyone having those phones, but I don't see any additional tasks I can do on this issue. I think it is a good idea to report it to the phone vendor so they may look into improving it. 

Best regards,
Kenneth

[Tim Hwang]

Okay. I'm waiting for MTK HQ reply. It will be updated when ready.

Thank you.

[Tim Hwang]

• 
  
  MTK asked me why BLE did not response for "LL_FEATURE_REQ" 5 seconds.
  In RTT log, no specific operation was found for 5 seconds
  Can you please explain it?
  
  00> [00:00:00.068,420] <dbg> bt_smp: bt_smp_pkey_ready:
  00> [00:01:19.375,610] <dbg> bt_keys: bt_keys_find_irk: 5D:DF:91:AC:9C:62 (random)
  00> [00:01:19.375,854] <dbg> bt_keys: bt_keys_find_irk: No IRK for 5D:DF:91:AC:9C:62 (random)
  00> [00:01:19.375,915] <dbg> bt_conn: bt_conn_ref: handle 0 ref 1 -> 2
  00> [00:01:19.375,946] <dbg> bt_conn: bt_conn_unref: handle 0 ref 2 -> 1
  00> [00:01:19.375,946] <dbg> bt_conn: bt_conn_ref: handle 0 ref 1 -> 2
  00> [00:01:19.376,037] <dbg> bt_conn: bt_conn_set_state: connecting-adv -> connected
  00> [00:01:19.376,068] <dbg> bt_smp: bt_smp_accept: conn 0x200038a0 handle 0
  00> [00:01:19.376,098] <dbg> bt_smp: bt_smp_connected: chan 0x20003b64 cid 0x0006
  00> [00:01:19.376,464] <dbg> bt_keys: bt_keys_find_addr: 5D:DF:91:AC:9C:62 (random)
  00> [00:01:19.376,800] <inf> peripheral_uart: ####Connected 5D:DF:91:AC:9C:62 (random)
  00> [00:01:19.376,831] <dbg> bt_conn: bt_conn_ref: handle 0 ref 2 -> 3
  00> [00:01:19.377,319] <dbg> bt_conn: bt_conn_prepare_events:
  00> [00:01:19.377,380] <dbg> bt_conn: conn_prepare_events: Adding conn 0x200038a0 to poll list
  00> [00:01:19.377,929] <dbg> bt_conn: bt_conn_prepare_events:
  00> [00:01:19.377,929] <dbg> bt_conn: conn_prepare_events: Adding conn 0x200038a0 to poll list
  00> [00:01:19.378,509] <dbg> bt_conn: bt_conn_prepare_events:
  00> [00:01:19.378,540] <dbg> bt_conn: conn_prepare_events: Adding conn 0x200038a0 to poll list
  00> [00:01:19.378,631] <dbg> bt_conn: bt_conn_unref: handle 0 ref 3 -> 2
  00> [00:01:24.376,220] <dbg> bt_conn: deferred_work: conn 0x200038a0
  00> [00:01:24.376,251] <dbg> bt_conn: send_conn_le_param_update: conn 0x200038a0 features 0x00 params (24-40 0 42)
  [nordic_log.txt]
  
  
• Pairing_failed.7z

[Kenneth]

I assume because due to the master does not send anything for 100 events (~5seconds):

The LL_FEATURE_RSP is sent on the first next connection event after LL_FEATURE_REQ is received, in this case there is 100 event gap without any communication from the central.

Best regards,
Kenneth

[Tim Hwang]

Thanks for updating.

Let me tell you test steps.
1. Nordic BLE start advertisement.
2. Android(Nordic app) begin scan.
3. Android(Nordic app) select "Bond" menu.

First of all, I will forward your opinion to MTK immediately.
BTW, from sniff.pcap file, Master is Android and slave is Nordic BLE, I think. Or let me know.
(Slave address 00:16:7f:ab:cd:20 is nordic ble)

In addition, my company's RF guy measured if MTK(Android)'s 2.4GHz meets the requirement. And he said it's okay. 

Thank you.

[Kenneth]

Hello,

It's always the central (master) that must send the first packet on a connection event. The peripheral (slave) can only send data after the master send a packet. 

In this case you can see that the central (master) does not send any packet for 100 connection events by looking at the "Event counter" column. So this must be a bug of some sort on the phone side.

Kenneth

[Tim Hwang]

We are still waiting for MTK reply. 
Thanks.

[Tim Hwang]

I'm sorry that last your message had been removed while I delete duplicated my message.

------------------------------------------------------------------------------------------------------------------------------
MTK reply: 

The log provided by your company from beginning, as well as the latest linked log,

It can be seen that the DUT initiated the security requsest, and the peer has not responded to DUT. After a period of time, the connection is disconnected. The entire pair time of smp cannot exceed 30s. It is impossible for MTK to re-modify the timeout time for each acl cmd. Since your customer finds out that the delay is estimated by the peer,MTK suggest that it should analyze from the peer.
------------------------------------------------------------------------------------------------------------------------------


Your last message

Tim Hwang said:

BTW, Can I have workaround for changing auth timeout as 30 seconds?

No.

Tim Hwang said:

It can be seen that the DUT initiated the security requsest, and the peer has not responded to DUT.

But that can be removed, and I believe we have already discussed removing it, but from my understanding you are seeing the same even when removed? Did they have an explaination to why removing it show the same issue?

Best regards,
Kenneth

 ------------------------------------------------------------------------------------------------------------------------------

[Tim Hwang]

For workaround, I understand it.

Here is test steps and my explanation.

sample:\nrf\samples\bluetooth\peripheral_uart
1) launch sample
2) MTK search Nordic and send "request pairing" at "REF" time.
3) Pairing request was sent from MTK to Nordic at 9.371. It causes timeout.
4) I request to MTK for fixing delayed "pairing request".
5) MTK's reply is that Nordic can handle it. because "The entire pair time of smp cannot exceed 30s"
..."MTK suggest that it should analyze from the peer.")


6) What is your opinion about that? Is it acceptable?

[Kenneth]

Tim Hwang said:

..."MTK suggest that it should analyze from the peer.")

Can you share that specific log with me?

Kenneth