CTS compatibility issues in disconnection after bonding (Disconnected reason 0x16)

RE: CTS compatibility issues in disconnection after bonding (Disconnected reason 0x16)

Ben — Thu, 27 Jan 2022 01:20:05 GMT

Hi,

Got it. We also update android OS version to 12 on pixel 5. (Version is same as pixel 6). Google pixel 5 is difference with pixel 6. It supports CTS feature.

Thank you for your help again.

RE: CTS compatibility issues in disconnection after bonding (Disconnected reason 0x16)

Edvin — Wed, 26 Jan 2022 14:17:26 GMT

I see. Then I guess it is the line 430 in main.c that was triggered then:

        case BLE_CTS_C_EVT_DISCOVERY_FAILED:
            NRF_LOG_INFO("Current Time Service not found on server. ");
            // CTS not found in this case we just disconnect. There is no reason to stay
            // in the connection for this simple app since it all wants is to interact with CT
            if (p_evt->conn_handle != BLE_CONN_HANDLE_INVALID)
            {
                err_code = sd_ble_gap_disconnect(p_evt->conn_handle,
                                                 BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
                APP_ERROR_CHECK(err_code);
            }
            break;

This is a special case in Bluetooth Low Energy, because usually it is the peripheral that holds the services and the central is the client, but in this case it is the central that "owns" the service, and the peripheral is the client. If the phone doesn't provide the Current Time Service, then this application will disconnect in the above snippet. However, the behavior of the application is completely up to you. If you still want to connect to the phone and use other services, then you are perfectly fine to so so.

Best regards,

Edvin

RE: CTS compatibility issues in disconnection after bonding (Disconnected reason 0x16)

Ben — Wed, 26 Jan 2022 12:08:08 GMT

Hi,

It looks like google pixel 6 issue. I try use other product with CTS to connect with pixel 6. That also doesn't update time. I think I should avoid disconnect after not support this service.

Thank you for your assistance.

RE: CTS compatibility issues in disconnection after bonding (Disconnected reason 0x16)

Ben — Wed, 26 Jan 2022 07:40:04 GMT

Hi,

In previous call stack information, I set break point at all case of BLE_GAP_EVT_DISCONNECTED.

In setting breakpoint at all sd_ble_gap_disconnect(), I use pca10040e s112 example code, except no used function in pm_hanlder_disconnect_on_sec_failure and pm_handler_disconnect_on_insufficient_sec . It's triggered at BLE_CTS_C_DISCONVERY_FAILED of on_cts_c_evt. That means the phone don't have this service?

In previous test, I always use pca10040e example. I try to program hex file directly on nRF52 DK recently.(ble_app_cts_c_pca10040e_s112.hex and ble_app_cts_c_pca10040_s132.hex). Both of them have disconnection result.

Thank you.

RE: CTS compatibility issues in disconnection after bonding (Disconnected reason 0x16)

Edvin — Tue, 25 Jan 2022 12:37:20 GMT

Hello,

Thank you for the detailed video and the new sniffer trace.

From the trace, I can't see anything that would indicate that they are bonding twice, so it could be the phone acting weird (that would not be the first time).

It is the nRF that decides to disconnect in packet number. 2344 in the sniffer trace (ble_cts_c_sniffer_filter_nordic_video1.pcapng). I see that you have some screenshot from the callstack in your original post. What does it point to? Is that just the disconnected event?

The softdevice will never initiate a disconnection itself with the reason Remote User Terminated Connection (0x13). So it has to be done from the application somewhere. Can you please try to set a breakpoint at all the calls to sd_ble_gap_disconnect() and see if any of them are reached when the devices disconnect?

Just for debugging purposes. Does it also happen on the unmodified pca10040e example?

Best regards,

Edvin

RE: CTS compatibility issues in disconnection after bonding (Disconnected reason 0x16)

Ben — Tue, 25 Jan 2022 01:42:22 GMT

Hi Edvin,

In above results, I use example code (ble_app_cts_c) to test it. I didn't modify the code. Before test, I use nRF connect desktop tool to erase nrf52 DK, and forget BLE device on google pixel 6. The cts_init is not existed security selection. When I want to disable SEC_PARAM_BOND, that will run error handler. On original code, the sniffer doesn't pick up the key.

The attached files are a process video and sniffer log which I perform it. In my condition, the pixel mobile phone always pops up pairing twice. In info column of sniffer, I see that rcvd pairing response: AuthReq: Bonding | Initator key. Please check it.

devzone.nordicsemi.com/.../bandicam-2022_2D00_01_2D00_25-09_2D00_02_2D00_02_2D00_870.mp4

devzone.nordicsemi.com/.../ble_5F00_cts_5F00_c_5F00_sniffer_5F00_filter_5F00_nordic_5F00_video1.pcapng

Thank you.

RE: CTS compatibility issues in disconnection after bonding (Disconnected reason 0x16)

Edvin — Mon, 24 Jan 2022 14:21:10 GMT

Hello,

I believe that these sniffer traces are not made from the initial connection between the devices, right?

Try to delete the bonding information between the mobile phone and the nRF. On the mobile phone it is typically done in Settings -> Bluetooth. On the nRF the easiest way is to erase the flash using "nrfjprog --eraseall" (nrfjprog = nRF Command Line Tools), and reflash the application.

If you are using "just works" bonding, then the sniffer should pick up the keys the first time they connect and pair, but if you have some MITM (such as a passkey) you need to enter this passkey into the sniffer as well before you enter it on your phone.

Enter the passkey here (red circle):

When the sniffer either receives the keys from your input, or pick it up from the packets, you should no longer see the "decrypted incorrectly" messages that you can also see in the screenshot above.

Best regards,

Edvin

RE: CTS compatibility issues in disconnection after bonding (Disconnected reason 0x16)

Ben — Mon, 24 Jan 2022 03:31:36 GMT

Hi,

Here is my test result.

Are you able to get the Current Time from the CTS before they disconnect?

I set a global variable in ble_cts_c_evt_t which doesn't update time before disconnect.

Do they disconnect again if you try to connect after they are bonded?

Yes.

Which device is initiating the disconnect? The nRF or the mobile phone?

I'm not sure which device is initiating the disconnect (nrf52 or falling phone)? I just see device enter BLE_GAP_EVT_DISCONNECTED in ble_evt_handler. Do you have any suggestions to check this?

Please check attachments. I'm not familiar with sniffer. If there are wrong data, please tell me.

Thank you.

devzone.nordicsemi.com/.../ble_5F00_cts_5F00_c_5F00_sniffer.pcapng devzone.nordicsemi.com/.../ble_5F00_cts_5F00_c_5F00_sniffer_5F00_filter_5F00_nordic_5F00_cts.pcapng devzone.nordicsemi.com/.../ble_5F00_cts_5F00_c_5F00_sniffer_5F00_filter_5F00_nordic_5F00_cts_5F00_process_5F00_in_5F00_bonding.pcapng

RE: CTS compatibility issues in disconnection after bonding (Disconnected reason 0x16)

Edvin — Fri, 21 Jan 2022 14:14:40 GMT

Hello,

I don't have any of the "failing" phones. Are you able to get the Current Time from the CTS before they disconnect? Do they disconnect again if you try to connect after they are bonded? Which device is initiating the disconnect? The nRF or the mobile phone?

Can you please try to capture a sniffer trace of one of the connections that disconnect? You can use the nRF Sniffer for Bluetooth LE for this.

Please upload the sniffer trace as a .pcapng here.

Best regards,

Edvin