[nRF Connect SDK] Pairing failure

Target nRF52832(nrf52dk_nrf52832)
SDK NCS v2.0.0

original case
(+) [nRF Connect SDK]Force to make pairing(bonding) - Nordic Q&A - Nordic DevZone - Nordic DevZone (nordicsemi.com)

Here is my test step. (Nordic: peripheral role)

1) Nordic begins advertising (custom UUID like peripheral_uart sample)
2) Android app gets predefined bt mac (example 00:16:7F:11:22:36).
There were no BLE scan. and connect to Nordic.

3) Nordic connected and initiate pairing
bt_set_bondable(true);
bt_conn_set_security(conn, BT_SECURITY_L4);

Result
Much of case my Android (MTK) failed to make pairing. (Especially right after android rebooted) 

MTK have told me Nordic should provide solution to resolve this issue.

RTT Viewer
00> Connected secmode 4
00> HS connected
00> HS Connected 00:16:7F:40:1E:D0 (public)
00> D:
00> D: 00:16:7F:40:1E:D0 (public)
00> D: prnd 7d93ec3b4828ce3b4210d054f903653a
00> D: chan 0x20001f54 cid 0x0006
00> D: status 0x8
00> D: chan 0x20001f54 conn 0x20001c90 handle 0 encrypt 0x00 hci status 0x1f
00> Security failed: 00:16:7F:40:1E:D0 (public) level 1 err 9
(Android public mac 00:16:7F:40:1E:D0)

2772.sf650_error_03Nov2022.7z



BTW, Nordic required sniff log for analyzing pairing error. However, I hardly get sniff log.
I can get CONNECT_IND then drops next packets. Do you have any idea?






nrf_sniffer_for_bluetooth_le_4.1.1
wireshark 4.0.1
nRF52DK dev borad
J-Link 6.88a


Parents
  • Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    00> HS:Advertising successfully started
    00> D: 55:A6:42:65:6B:D0 (random)
    00> D: No IRK for 55:A6:42:65:6B:D0 (random)
    00> D: conn 0x20001c88 handle 0
    00> D: chan 0x20001f4c cid 0x0006
    00> D: 55:A6:42:65:6B:D0 (random)
    00> Connected secmode 4
    00> HS connected
    00> HS Connected 55:A6:42:65:6B:D0 (random)
    00> D:
    00> D: 55:A6:42:65:6B:D0 (random)
    00> D: created 0x200029dc for 55:A6:42:65:6B:D0 (random)
    00> D: prnd 23a14c89ca6eb11b5c0c56610146bb35
    00> Connection parameters updated.
    00> interval: 6, latency: 0, timeout: 500
    00> Conn params updated: interval 7 ms, latency 0, timeout: 5000 ms
    00> W: Ignoring unexpected request
    00> W: Ignoring unexpected request
    00> D: chan 0x20001f4c cid 0x0006
    00> D: status 0x8
    00> D: 55:A6:42:65:6B:D0 (random) (keys 0x0000)
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    sniff.7z

    sniff log is uploaded as well as rtt log.
    Your message will be forwarded to MTK HQ again.

    I have no idea what made following error. Can you please find in sniff log?
    00> D: chan 0x20001f4c conn 0x20001c88 handle 0 encrypt 0x00 hci status 0x1f

  • Hi Tim,

    Sorry but I feel confused a bit about your situation here.

    I am not sure how that case is related to this current question. Could you please elaborate?

    Much of case my Android (MTK) failed to make pairing. (Especially right after android rebooted) 

    MTK have told me Nordic should provide solution to resolve this issue.

    Does MTK mean MediaTek?

    What reasoning did they give to believe Nordic should provide the solution to resolve this issue?

    On my end, I attempted to pair using bt_conn_set_security() as you did, and both my Android phone and my Windows PC can bond with the device without any problem.
    Pairing at Security Level 4 like you are trying to do also require an out of band verification method. On your RTT log I don't see signs of this happened. What did you do to achieve this?

    Tim Hwang said:
    I have no idea what made following error. Can you please find in sniff log?
    00> D: chan 0x20001f4c conn 0x20001c88 handle 0 encrypt 0x00 hci status 0x1f

    That is not an error. It is most likely just a log from smp.c. See sdk-zephyr/smp.c.

    Finally, I would like to ask for a few pieces of information to understand the situation better:

    What is your current setup?
    What module did you enable logging to acquire the RTT log you shared?
    Is there a specific sample are you experimenting on?
    What SDK version are you on?
    These pieces of information help making sense out of the logs you provided.

    Best regards,

    Hieu

  • Hello Hieu.

    1. NFC
    I could reproduce this issue without NFC tagging. Let's discuss later. It is not root reason; I think.

    2. Just works (key exchange)
    1)We do need authenticated/LE secure connection. let's discuss later as well.
    If Key exchange is a matter, we always see this issue. But it is not. What do you think about that?

    2) Here is pairing sequence in success case.

    Here is failure case.
    Nordic sent security request.
    MTK sent "Pairing request", but Nordic did not send "Pairing response" 
    No "Pairing response", No user confirmation.




    3. "hci status value 0x1f"
    Let's focus it first. I believe you can give me any explanation.
    then I'll forward it to MTK.




  • I test again with more log option.

    1. Pairing request was received after 5 seconds.

    2. RTT log at failure log.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    00> [00:01:02.722,015] <dbg> bt_hci_core: bt_recv: buf 0x2000ca88 len 33
    00> [00:01:02.722,381] <dbg> bt_hci_core: rx_work_handler: Getting net_buf from queue
    00> [00:01:02.722,412] <dbg> bt_hci_core: rx_work_handler: buf 0x2000ca88 type 1 len 33
    00> [00:01:02.722,412] <dbg> bt_hci_core: hci_event: event 0x3e
    00> [00:01:02.722,442] <dbg> bt_hci_core: hci_le_meta_event: subevent 0x0a
    00> [00:01:02.722,869] <dbg> bt_hci_core: bt_hci_le_enh_conn_complete: bt_hci_le_enh_conn_complete status 0x00 handle 0 role 1 peer 47:95:91:6C:DF:D7 (random) peer RPA 00:00:00:00:00:00
    00> [00:01:02.723,052] <dbg> bt_hci_core: bt_hci_le_enh_conn_complete: local RPA 00:00:00:00:00:00
    00> [00:01:02.723,297] <dbg> bt_keys: bt_keys_find_irk: 47:95:91:6C:DF:D7 (random)
    00> [00:01:02.723,541] <dbg> bt_keys: bt_keys_find_irk: No IRK for 47:95:91:6C:DF:D7 (random)
    00> [00:01:02.723,602] <dbg> bt_conn: bt_conn_ref: handle 0 ref 1 -> 2
    00> [00:01:02.723,632] <dbg> bt_conn: bt_conn_unref: handle 0 ref 2 -> 1
    00> [00:01:02.723,663] <dbg> bt_conn: bt_conn_ref: handle 0 ref 1 -> 2
    00> [00:01:02.723,724] <dbg> bt_adv: bt_le_adv_resume: Host cannot resume connectable advertising (-12)
    00> [00:01:02.723,754] <dbg> bt_conn: bt_conn_set_state: connecting-adv -> connected
    00> [00:01:02.723,785] <dbg> bt_l2cap: l2cap_accept: conn 0x20005870 handle 0
    00> [00:01:02.723,846] <dbg> bt_l2cap: bt_l2cap_chan_add: conn 0x20005870 chan 0x20006174
    00> [00:01:02.723,876] <dbg> bt_l2cap: l2cap_connected: ch 0x20006174 cid 0x0005
    00> [00:01:02.723,876] <dbg> bt_smp: bt_smp_accept: bt_smp_accept 5811 conn 0x20005870 handle 0
    00> [00:01:02.723,907] <dbg> bt_l2cap: bt_l2cap_chan_add: conn 0x20005870 chan 0x20005b2c
    00> [00:01:02.723,907] <dbg> bt_smp: bt_smp_connected: bt_smp_connected: chan 0x20005b2c cid 0x0006
    00> [00:01:02.724,029] <dbg> bt_l2cap: bt_l2cap_chan_add: conn 0x20005870 chan 0x2000c124
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    It seems Pairing response was sent but Android did not receive it.
    Can you please review rtt log?

  • Hi Tim,

    Tim Hwang said:
    1. NFC
    I could reproduce this issue without NFC tagging. Let's discuss later. It is not root reason; I think.

    You misunderstood. I mentioned NFC as an example of an out-of-band (OOB) verification method. NFC should not be the problem here.

    Tim Hwang said:
    If Key exchange is a matter, we always see this issue. But it is not. What do you think about that?

    The problem is exactly that: I don't know what to think about that.

    Please take a look back at your videos. What I see are

    - Incorrect passkey error message from the "not-good" video.
    - Passkey pop-up in the "okay" video
    - Very short time between passkey pop-up and the connection is made in the "okay" video. Too short for actual passkey to be entered by a normal human.

    The combination of those makes no sense at all.

    That is why I hope a sniffer log containing the encrypted pairing packets would help me see what is wrong here.

    I might guess that your Android device asks for passkey, but doesn't handle the passkey well, sometime consider "no" passkey as good, sometime doesn't. Without a sniffer, I can't be sure.

    Therefore, if possible, please look into getting me that sniffer log with the pairing procedure. Preferably one of a success case, and one of a failure case.

    I will look at your RTT log Tue and Wed. Unfortunately, I am partially out of office both days, so my follow-up might be delayed until end of Thursday.

    Best regards,

    Hieu 

  • Hello. 

    1. ...How do you enter the passkey in your device?...
    device (Nordic BLE) already disconnected before BLE(Nordic) have chance to check passkey.

    2. RTT log: new log
    00> [00:00:12.557,952] <dbg> bt_hci_core: bt_hci_cmd_send_sync: rsp 0x2000cba0 opcode 0x2032 len 0

    00> [00:00:12.557,952] <dbg> bt_conn: bt_conn_unref: handle 0 ref 3 -> 2
    00> [00:00:17.624,084] <dbg> sdc_hci_driver: event_packet_process: Event (0x05) len 4
    00> [00:00:17.624,176] <dbg> bt_hci_core: bt_recv: buf 0x2000ca88 len 6

    hci.h

    I think I found reason of hci status value 0x1f.

    "Event (0x05)" in HCI log means that BT_HCI_EVT_DISCONN_COMPLETE.
    What kind of this disconnection? It seems it is link loss timeout (12.557 ~ 17.624).
    In my test, many of failure case had around 5 seconds delay.

    How can we know about that? What is your opinion?

  • Hi Tim,

    Regarding the long RTT Log posted on 7 Nov, here are what I found:

    Fullscreen
    1
    2
    3
    4
    00> [00:01:11.915,771] <dbg> bt_hci_core: hci_disconn_complete_prio: hci_disconn_complete_prio status 0x00 handle 0 reason 0x28
    ...
    00> [00:01:11.916,229] <dbg> bt_hci_core: hci_event: event 0x05
    00> [00:01:11.916,259] <dbg> bt_hci_core: hci_disconn_complete: status 0x00 handle 0 reason 0x28
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    These lines indicate that the connection was terminated with reason 0x28, which is BLE_HCI_INSTANT_PASSED.
    This means some time sensitive event didn't happen when it should. There are many root causes. Some possible ones are too much radio-noises or logging too much.

    Fullscreen
    1
    2
    00> [00:01:11.917,785] <wrn> peripheral_uart: Security failed: 47:95:91:6C:DF:D7 (random) level 1 err 9
    00> [00:01:11.918,029] <inf> peripheral_uart: Pairing failed conn: 47:95:91:6C:DF:D7 (random), reason 9
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    These lines indicate that Pairing/Security failed with reason 9, which is BT_SECURITY_ERR_UNSPECIFIED.
    The error code means that Security did not fail due to any of these reasons:
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    /** Authentication failed. */
    BT_SECURITY_ERR_AUTH_FAIL,
    /** PIN or encryption key is missing. */
    BT_SECURITY_ERR_PIN_OR_KEY_MISSING,
    /** OOB data is not available. */
    BT_SECURITY_ERR_OOB_NOT_AVAILABLE,
    /** The requested security level could not be reached. */
    BT_SECURITY_ERR_AUTH_REQUIREMENT,
    /** Pairing is not supported */
    BT_SECURITY_ERR_PAIR_NOT_SUPPORTED,
    /** Pairing is not allowed. */
    BT_SECURITY_ERR_PAIR_NOT_ALLOWED,
    /** Invalid parameters. */
    BT_SECURITY_ERR_INVALID_PARAM,
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    The above symptoms and diagnoses also match quite well with your 8 Nov comment.

    Overall, what I derived are:
    - Some key time-sensitive packet missed its "instant" and the pairing process failed.

    BLE_HCI_INSTANT_PASSED is pretty rare in development environment, where the devices in a connection are usually physically close. If possible, please observe several more reproduction of the issue to see if the same disconnection reason happens.

    - If BLE_HCI_INSTANT_PASSED happens consistently, at least one sniffer log with the pairing procedure, preferably two or three logs, are required to pinpoint the exact problem.

    - A sniffer log captured when the device RTT log is turned down to normal (info) level is also helpful (to rule out the possibility that the log processing caused the timing issue).

Reply
  • Hi Tim,

    Regarding the long RTT Log posted on 7 Nov, here are what I found:

    Fullscreen
    1
    2
    3
    4
    00> [00:01:11.915,771] <dbg> bt_hci_core: hci_disconn_complete_prio: hci_disconn_complete_prio status 0x00 handle 0 reason 0x28
    ...
    00> [00:01:11.916,229] <dbg> bt_hci_core: hci_event: event 0x05
    00> [00:01:11.916,259] <dbg> bt_hci_core: hci_disconn_complete: status 0x00 handle 0 reason 0x28
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    These lines indicate that the connection was terminated with reason 0x28, which is BLE_HCI_INSTANT_PASSED.
    This means some time sensitive event didn't happen when it should. There are many root causes. Some possible ones are too much radio-noises or logging too much.

    Fullscreen
    1
    2
    00> [00:01:11.917,785] <wrn> peripheral_uart: Security failed: 47:95:91:6C:DF:D7 (random) level 1 err 9
    00> [00:01:11.918,029] <inf> peripheral_uart: Pairing failed conn: 47:95:91:6C:DF:D7 (random), reason 9
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    These lines indicate that Pairing/Security failed with reason 9, which is BT_SECURITY_ERR_UNSPECIFIED.
    The error code means that Security did not fail due to any of these reasons:
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    /** Authentication failed. */
    BT_SECURITY_ERR_AUTH_FAIL,
    /** PIN or encryption key is missing. */
    BT_SECURITY_ERR_PIN_OR_KEY_MISSING,
    /** OOB data is not available. */
    BT_SECURITY_ERR_OOB_NOT_AVAILABLE,
    /** The requested security level could not be reached. */
    BT_SECURITY_ERR_AUTH_REQUIREMENT,
    /** Pairing is not supported */
    BT_SECURITY_ERR_PAIR_NOT_SUPPORTED,
    /** Pairing is not allowed. */
    BT_SECURITY_ERR_PAIR_NOT_ALLOWED,
    /** Invalid parameters. */
    BT_SECURITY_ERR_INVALID_PARAM,
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    The above symptoms and diagnoses also match quite well with your 8 Nov comment.

    Overall, what I derived are:
    - Some key time-sensitive packet missed its "instant" and the pairing process failed.

    BLE_HCI_INSTANT_PASSED is pretty rare in development environment, where the devices in a connection are usually physically close. If possible, please observe several more reproduction of the issue to see if the same disconnection reason happens.

    - If BLE_HCI_INSTANT_PASSED happens consistently, at least one sniffer log with the pairing procedure, preferably two or three logs, are required to pinpoint the exact problem.

    - A sniffer log captured when the device RTT log is turned down to normal (info) level is also helpful (to rule out the possibility that the log processing caused the timing issue).

Children
  • P.s: Could you also try using the nRF Connect app to perform the pairing? The app can produce some potentially helpful logs from the phone side.

  • Thanks for updating.
    I'll upload the nRF Connect app log as soon as it is ready.

  • Just in case, you also saw my longer reply where I ask if you can see if more reproductions of the issues result in the same disconnect reason 0x28, and where I asked for the sniffer trace again, right?

  • 1. nRF Connect app log

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    nRF Connect, 2022-11-14
    Nordic_UART_Service (00:16:7F:11:22:36)
    V 14:27:21.563 Connecting to 00:16:7F:11:22:36...
    D 14:27:21.564 gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferred PHY = LE 1M)
    D 14:27:22.357 [Callback] Connection state changed with status: 133 and new state: DISCONNECTED (0)
    E 14:27:22.357 Error 133 (0x85): GATT ERROR
    I 14:27:22.357 Disconnected
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    2. 
    Just in case, you also saw my longer reply where I ask if you can see if more reproductions of the issues result in the same disconnect reason 0x28, and where I asked for the sniffer trace again, right?
    -> Can you please explain your mention? 
    I repeated this test and found reason was 0x5 or 0x28. 

  • Hi Tim,

    Regarding your nRF Connect app log

    As you can see, in the log, the connection didn't even happen successfully. So that log shows an entirely new kind of failure compared to the ones you have shown me...

    For your reference of what normal looks like, here are a few logs I quickly created myself. Just my Android phone, and a peripheral_uart sample modified just like you described.

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    nRF Connect, 2022-11-14
    hivo c297913 (FF:26:0E:1A:CB:4D)
    D 13:17:09.449 gatt.close()
    D 13:17:09.454 wait(200)
    V 13:17:09.657 Connecting to FF:26:0E:1A:CB:4D...
    D 13:17:09.658 gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferred PHY = LE 1M)
    D 13:17:11.814 [Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
    D 13:17:11.841 [Callback] Connection state changed with status: 0 and new state: CONNECTED (2)
    I 13:17:11.841 Connected to FF:26:0E:1A:CB:4D
    V 13:17:11.846 Discovering services...
    D 13:17:11.846 gatt.discoverServices()
    I 13:17:12.107 Connection parameters updated (interval: 7.5ms, latency: 0, timeout: 5000ms)
    I 13:17:12.172 PHY updated (TX: LE 2M, RX: LE 2M)
    D 13:17:12.492 [Callback] Services discovered with status: 0
    I 13:17:12.492 Services discovered
    V 13:17:12.498 Generic Attribute (0x1801)
    - Service Changed [I] (0x2A05)
    ···Client Characteristic Configuration (0x2902)
    - Client Supported Features [R W] (0x2B29)
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    SEGGER J-Link V7.70d - Real time terminal output
    J-Link OB-SAM3U128-V2-NordicSemi compiled Jan 20 2022 16:43:31 V1.0, SN=683326383
    Process: JLink.exe
    [00:00:00.000,183] <dbg> bt_hci_core: bt_hci_driver_register: Registered SoftDevice Controller
    --- 471 messages dropped ---
    [00:00:00.057,525] <dbg> bt_hci_core: bt_hci_cmd_create: buf 0x20008f6c
    [00:00:00.057,617] <dbg> bt_hci_core: bt_hci_cmd_send_sync: buf 0x20008f6c opcode 0x200a len 4
    [00:00:00.057,647] <dbg> bt_hci_core: process_events: count 2
    [00:00:00.057,739] <dbg> bt_hci_core: process_events: ev->state 4
    [00:00:00.057,769] <dbg> bt_hci_core: send_cmd: calling net_buf_get
    [00:00:00.057,769] <dbg> bt_hci_core: send_cmd: calling sem_take_wait
    [00:00:00.057,861] <dbg> bt_hci_core: send_cmd: Sending command 0x200a (buf 0x20008f6c) to driver
    [00:00:00.057,891] <dbg> bt_hci_core: bt_send: buf 0x20008f6c len 4 type 0
    [00:00:00.057,891] <dbg> sdc_hci_driver: hci_driver_send:
    [00:00:00.057,983] <dbg> sdc_hci_driver: cmd_handle:
    [00:00:00.058,258] <dbg> sdc_hci_driver: hci_driver_send: Ex0m
    [00:00:09.221,893] <dbg> bt_hci_core: hci_cmd_done: opcode 0x2016 status 0x00 buf 0x20008f6c
    --- 46 messages dropped ---
    [00:00:09.222,259] <dbg> bt_conn: bt_conn_prepare_events:
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    [00:00:00.000,183] <dbg> bt_hci_core: bt_hci_driver_register: Registered SoftDevice Controller
    --- 469 messages dropped ---
    [00:00:00.051,727] <dbg> bt_hci_core: bt_hci_cmd_create: buf 0x20008f6c
    [00:00:00.051,818] <dbg> bt_hci_core: bt_hci_cmd_send_sync: buf 0x20008f6c opcode 0x200a len 4
    [00:00:00.051,849] <dbg> bt_hci_core: process_events: count 2
    [00:00:00.051,940] <dbg> bt_hci_core: process_events: ev->state 4
    [00:00:00.051,940] <dbg> bt_hci_core: send_cmd: calling net_buf_get
    [00:00:00.051,971] <dbg> bt_hci_core: send_cmd: calling sem_take_wait
    [00:00:00.052,062] <dbg> bt_hci_core: send_cmd: Sending command 0x200a (buf 0x20008f6c) to driver
    [00:00:00.052,062] <dbg> bt_hci_core: bt_send: buf 0x20008f6c len 4 type 0
    [00:00:00.052,093] <dbg> sdc_hci_driver: hci_driver_send:
    [00:00:00.052,154] <dbg> sdc_hci_driver: cmd_handle:
    [00:00:00.052,459] <dbg> sdc_hci_driver: hci_driver_send: Exit: 0
    [00:00:00.052,459] <dbg> bt_hci_core: process_events: ev->state 0
    [00:00:00.052,581] <dbg> sdc_hci_driver: event_packet_process: Command Complete (0x200a) status: 0x00, ncmd: 1, len 4
    [00:00:00.052,642] <dbg> bt_hci_core: bt_recv: buf 0x20008f6c len 6
    [00:00:00.052,673] <dbg> bt_hci_core: hci_cm
    [00:00:00.053,039] <dbg> bt_conn: bt_conn_prepare_events:
    [00:00:00.053,070] <dbg> bt_hci_core: hci_tx_thread: Calling k_poll with 2 events
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    nRF Connect, 2022-11-14
    hivo c297913 (FF:26:0E:1A:CB:4D)
    D 13:10:15.605 gatt.close()
    D 13:10:15.612 wait(200)
    V 13:10:15.813 Connecting to FF:26:0E:1A:CB:4D...
    D 13:10:15.813 gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferred PHY = LE 1M)
    D 13:10:16.231 [Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
    D 13:10:16.253 [Callback] Connection state changed with status: 0 and new state: CONNECTED (2)
    I 13:10:16.253 Connected to FF:26:0E:1A:CB:4D
    V 13:10:16.266 Discovering services...
    D 13:10:16.266 gatt.discoverServices()
    I 13:10:16.473 Connection parameters updated (interval: 7.5ms, latency: 0, timeout: 5000ms)
    I 13:10:16.539 PHY updated (TX: LE 2M, RX: LE 2M)
    D 13:10:16.700 [Callback] Services discovered with status: 0
    I 13:10:16.700 Services discovered
    V 13:10:16.708 Generic Attribute (0x1801)
    - Service Changed [I] (0x2A05)
    ···Client Characteristic Configuration (0x2902)
    - Client Supported Features [R W] (0x2B29)
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    Regarding my comment: devzone.nordicsemi.com/.../395213

    I have explained there what I observed, and why I request at least one sniffer log with the pairing procedure, if not two or three.


    Regarding your following statement: 

    Tim Hwang said:
    I repeated this test and found reason was 0x5 or 0x28. 

    Do you mean HCI event 0x5, or do you mean HCI event 0x5 and the reason is also 0x5?

    HCI Event 0x5 means BT_HCI_EVT_DISCONN_COMPLETE. It just means a disconnection. It doesn't say why there was a disconnection.

    If you see both reason 0x5 (BT_HCI_ERR_AUTH_FAIL) and reason 0x28 (BT_HCI_ERR_INSTANT_PASSED), and you have the above nRF Connect app log, then your system is showing at least three different kinds of failure with the same setup.

    That is going to be extremely complicated to analyze.

    In this situation, we will need a lot more data, you will have to be very methodical in recording your logs. You need to record both

    - Android log
    - Device RTT log
    - Sniffer traces

    And they need to be organized so both you and I can tell which is what.

    Before you send more logs, I have a few questions/requests

    1. Can your Android app or device consistently successfully pair with any BLE device? A BLE mouse, for example?
    2. Can your current nRF52 device consistently successfully pair with any Android/iOS/Windows device?
    3. Are you working in an environment with a lot of 2.4GHz signals?
    4. Is there any reason why you push aside my request for sniffer logs with the pairing procedure?
    5. Can you also zip up and send us the modified peripheral_uart project which you are using? You can use west build -t clean to remove all build artifacts to keep the file light.

    If you send more data, please try to categorize them by the kind of failure (disconnect reasons), group both Android, RTT, and sniffer trace together for each test/each failure.

    There is just nothing much I can do with fragmented info...