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

[Ben]

Hi Sir/Miss,

I import cts (current time service) as previous topic which is as link.

I have a compatibility issue in different phone.

The tested conditions are as below:

Apple

iPhone 11 (iOS15.1) with nRF connect - OK

iPhone 12 (iOS15.1) with nRF connect - OK

Android

Google pixel 5 (android OS 11) with nRF connect - OK

Google pixel 6 (android OS 12) with nRF connect - Disconnect after pairing and bonding

Redmi note 7 (android OS 10) with nRF connect - Disconnect after pairing and bonding

That is same result as original CTS example (ble_app_cts_c) in nRF52 DK PCA10040.

I use SDK 17.0.2 and softdevice s112 in nrf52810.

I see the disconnected reason is 22 (0x16).

And, call stack window is as below in IAR. It looks like observer issue?

How to avoid disconnection in these android phone?

Please help.

Thank you. 

[Edvin]

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

[Ben]

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.

ble_cts_c_sniffer.pcapngble_cts_c_sniffer_filter_nordic_cts.pcapngble_cts_c_sniffer_filter_nordic_cts_process_in_bonding.pcapng

[Edvin]

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

[Ben]

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.

ble_cts_c_sniffer_filter_nordic_video1.pcapng

Thank you.

[Edvin]

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

[Ben]

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.

[Ben]

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.

[Edvin]

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

[Ben]

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.