nRF52840 random disconnection

[Dani]

Good morning,

We have a new equipment based on the nRF52840 and s140.

                Just now, a new problem has appeared and it is very strange, as it seems to be a ‘random’ error:

 

                We have already assembled tens of equipment, and most of them are perfectly working with any smartphone (using both your ‘nRF Connect’ application or our own application).

                But, we have a few smartphones that show a strange behavior: they are able to perfectly connect to some of our nRF52840-based equipment, and in a few ones, they are able to connect but they get disconnected after a few seconds. Same equipment is connecting to other smartphones without problems (without disconnecting).

                This is (step by step) what it is happening a few times:

• Equipment (nRF52840) is advertising.
• Smartphone stablish connection with equipment using pin number
• First time, the connection is perfectly working.
• If smartphone is disconnected and connected back again with same equipment (Already bonded), then connection is stablished but smartphone disconnects after 30”, approximately. Same behavior is happening with both nRF connect application and our own application. Looking at log in nRF application we see: ‘Connection terminated by peer (status 19)’or ‘GATT_CONN_TIMEOUT’

 

Why is it happening?

Which is the reason?

How can we solve this?

 

 Could you help us? (For your information, we have set MIN_CONN_INTERVAL to 7.5m and MAX_CONN_INTERVAL to 100ms)

Thank you

[Hung Bui]

Hi Daniel, 

I got the update from Brian Kim about your email discussion. I agree with Brian that the sniffer trace would play a very important role here to solve the issue. I have some comments: 

- Regarding the sniffer trace, I could see the communication because the link was encrypted. What you need to do is to either do Legacy pairing and use the sniffer to follow the initial bonding. Or use LESC but in debug mode. 

- Another option you can try is to turn off bonding and encryption requirement to see if the issue is related to bonding or not. If the issue remain, please capture a sniffer trace. 

- The disconnection happened at second 26th into the connection so it may not related to the 30seconds GAP/GATT timeout.

- Please try to do a chip erase on the defected board and test again.

- Please try to test using one of our example in the SDK, ble_app_proximity for example. 

[Dani]

Hi again,

I have programmed one equipment turning bonding off, and then it is imposssible to connect (please, look at the attached screenshot with nRF Connect).

In order to set it off, I set my variable 'BONDING_WITH_NO_CODE' to 1, and I have implement this in 'peer_manager_init' function:

static void peer_manager_init(void)
{
    ble_gap_sec_params_t sec_param;
    ret_code_t           err_code;

    err_code = pm_init();
    APP_ERROR_CHECK(err_code);

    memset(&sec_param, 0, sizeof(ble_gap_sec_params_t));

    // Security parameters to be used for all security procedures.
		if(BONDING_WITH_NO_CODE)
		{
			sec_param.bond         = 0;    
			sec_param.oob          = 0;
			sec_param.mitm         = 0; 
			sec_param.io_caps      = BLE_GAP_IO_CAPS_NONE;
			sec_param.kdist_own.enc  = 0;
			sec_param.kdist_own.id   = 0;
			sec_param.kdist_peer.enc = 0;
			sec_param.kdist_peer.id  = 0;
		}
		else
		{
			sec_param.bond           = SEC_PARAM_BOND;
			sec_param.oob            = SEC_PARAM_OOB;
			sec_param.mitm           = SEC_PARAM_MITM; //Static Key
			sec_param.io_caps        = SEC_PARAM_IO_CAPABILITIES;    
			sec_param.kdist_own.enc  = 1;
			sec_param.kdist_own.id   = 1;
			sec_param.kdist_peer.enc = 1;
			sec_param.kdist_peer.id  = 1;
		}
		
        
    sec_param.lesc           = SEC_PARAM_LESC;
    sec_param.keypress       = SEC_PARAM_KEYPRESS;    
    sec_param.min_key_size   = SEC_PARAM_MIN_KEY_SIZE;
    sec_param.max_key_size   = SEC_PARAM_MAX_KEY_SIZE;
    

    err_code = pm_sec_params_set(&sec_param);
    APP_ERROR_CHECK(err_code);

    err_code = pm_register(pm_evt_handler);
    APP_ERROR_CHECK(err_code);
}

Furthermore, in this case, in all services, I proceed in the following way:

if(BONDING_WITH_NO_CODE)
{
	BLE_GAP_CONN_SEC_MODE_SET_OPEN(&attr_md.read_perm);
	BLE_GAP_CONN_SEC_MODE_SET_OPEN(&attr_md.write_perm);			
}		
else
{
	BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM(&attr_md.read_perm);
	BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM(&attr_md.write_perm);
}

Hope to go ahead with the solution.

Best regards,

Dani.

[Dani]

Good afternoon,

I'm just looking around this issue, as we need to have the solution implemented ASAP.

In the 'ble_evt_handler' function, I have implemented the BLE_GATTC_EVT_TIMEOUT and BLE_GATTS_EVT_TIMEOUT in the same way, as follows:

case BLE_GATTC_EVT_TIMEOUT:
            // Disconnect on GATT Client timeout event.            
            err_code = sd_ble_gap_disconnect(p_ble_evt->evt.gattc_evt.conn_handle,
                                             BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
            APP_ERROR_CHECK(err_code);
						
            break;

        case BLE_GATTS_EVT_TIMEOUT:
            // Disconnect on GATT Server timeout event.            
            err_code = sd_ble_gap_disconnect(p_ble_evt->evt.gatts_evt.conn_handle,
                                             BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
            APP_ERROR_CHECK(err_code);
						
            break;

When the disconnection appears, the equipment receives the BLE_GATTS_EVT_TIMEOUT event.

If I comment the functions implemented in this event, the problem with the disconnection disappears.

Is it a good workaround? What is exactly the difference between these two events? Which other problems can raise if I comment the implementation of the BLE_GATTS_EVT_TIMEOUT  event?

Best regards,

Dani

[Hung Bui]

Hi Daniel, 

I'm sorry for the late reply. It was Norway's national day yesterday.
The BLE_GATTC_EVT_TIMEOUT, BLE_GATTS_EVT_TIMEOUT happen when a read/write from the client or an indication from the server doesn't have a reply from the peer device. So it must be something wrong with the peer device and the default behavior is to disconnect. It's most likely the peer device is not able to handle the command and can't reply for some reason. 

If you remove the disconnect request as in the code, the connection can remain but we don't know what's wrong with the peer device and the peer may have unexpected behavior. 

In your application do you do any write request, read request or indication ? 

My suggestion is to try again with no bond and capture a sniffer trace. We really need to know what happen of the the air. Please try to capture the sniffer when you couldn't connect. 

I suspect that if there is no bond involved the issue will not occurs. In that case you may need to consider using Legacy bonding instead of LESC, this way the sniffer can follow the legacy bonding and can get the bond information to decrypt the connection when they are connected after bonding.. 

[Dani]

Thank you so much.

I will try to catch that trace with sniffer.

In what regards legacy bonding: which is the parameter I have to set instead of LESC? (Some messages above, I specified how bonding is setup)

Kind regards,

Dani

[Hung Bui]

Hi Dani, 

If you want to disable LESC you can set SEC_PARAM_LESC = 0 in peer_manager_init().

And to make it easier for the sniffer set : 

sec_param.io_caps      = BLE_GAP_IO_CAPS_NONE;

Please keep other settings as-is.

[Dani]

First of all I have set SEC_PARAM_LESC = 0 with no bonding, I have tried to connect to nRFConnect Application. After discovering services, my device should constantly send information to smartphone, and now, it is not receiving nothing.

Please, look at attached log output from nRFConnect tool

Fullscreen Log 2022-05-18 14_36_46.txt Download

nRF Connect, 2022-05-18
A-SMART 2 (F9:4F:3C:FA:8E:43)
V	14:35:20.700	Connecting to F9:4F:3C:FA:8E:43...
D	14:35:20.700	gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferred PHY = LE 1M)
D	14:35:22.804	[Broadcast] Action received: android.bluetooth.device.action.BOND_STATE_CHANGED, bond state changed to: BOND_BONDING (11)
D	14:35:22.808	[Callback] Connection state changed with status: 0 and new state: CONNECTED (2)
I	14:35:22.808	Connected to F9:4F:3C:FA:8E:43
D	14:35:22.833	[Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED
D	14:35:22.854	[Broadcast] Action received: android.bluetooth.device.action.PAIRING_REQUEST, pairing variant: PAIRING_VARIANT_CONSENT (3)
I	14:35:23.460	Connection parameters updated (interval: 7.5ms, latency: 0, timeout: 5000ms)
I	14:35:24.040	Connection parameters updated (interval: 45.0ms, latency: 0, timeout: 5000ms)
D	14:35:26.169	[Broadcast] Action received: android.bluetooth.device.action.BOND_STATE_CHANGED, bond state changed to: BOND_BONDED (12)
I	14:35:26.169	Device bonded
D	14:35:26.179	wait(1600ms)
V	14:35:27.793	Discovering services...
D	14:35:27.793	gatt.discoverServices()
D	14:35:27.805	[Callback] Services discovered with status: 0
I	14:35:27.805	Services discovered
V	14:35:27.845	Generic Access (0x1800)
- Device Name [R W] (0x2A00)
- Appearance [R] (0x2A01)
- Peripheral Preferred Connection Parameters [R] (0x2A04)
- Central Address Resolution [R] (0x2AA6)
Generic Attribute (0x1801)
- Service Changed [I] (0x2A05)
   Client Characteristic Configuration (0x2902)
Unknown Service (00001000-0000-1000-8000-00805f9b34fb)
- Unknown Characteristic [R W] (00001001-1212-efde-1523-785feabcd123)
- Unknown Characteristic [N R] (00001002-1212-efde-1523-785feabcd123)
   Client Characteristic Configuration (0x2902)
Unknown Service (00002000-1212-efde-1523-785feabcd123)
- Unknown Characteristic [R W] (00002001-1212-efde-1523-785feabcd123)
- Unknown Characteristic [N R] (00002002-1212-efde-1523-785feabcd123)
   Client Characteristic Configuration (0x2902)
Unknown Service (00003000-1212-efde-1523-785feabcd123)
- Unknown Characteristic [R W] (00003001-1212-efde-1523-785feabcd123)
- Unknown Characteristic [N R] (00003002-1212-efde-1523-785feabcd123)
   Client Characteristic Configuration (0x2902)
Unknown Service (00004000-1212-efde-1523-785feabcd123)
- Unknown Characteristic [R W] (00004001-1212-efde-1523-785feabcd123)
- Unknown Characteristic [N R] (00004002-1212-efde-1523-785feabcd123)
   Client Characteristic Configuration (0x2902)
Unknown Service (00005000-1212-efde-1523-785feabcd123)
- Unknown Characteristic [R W] (00005001-1212-efde-1523-785feabcd123)
Unknown Service (00006000-1212-efde-1523-785feabcd123)
- Unknown Characteristic [N R] (00006002-1212-efde-1523-785feabcd123)
   Client Characteristic Configuration (0x2902)
Secure DFU Service (0xFE59)
- Secure Buttonless DFU [I W] (8ec90004-f315-4f60-9fb8-838830daea50)
   Client Characteristic Configuration (0x2902)
D	14:35:27.845	gatt.setCharacteristicNotification(00002a05-0000-1000-8000-00805f9b34fb, true)
D	14:35:27.848	gatt.setCharacteristicNotification(00001002-1212-efde-1523-785feabcd123, true)
D	14:35:27.849	gatt.setCharacteristicNotification(00002002-1212-efde-1523-785feabcd123, true)
D	14:35:27.850	gatt.setCharacteristicNotification(00003002-1212-efde-1523-785feabcd123, true)
D	14:35:27.852	gatt.setCharacteristicNotification(00004002-1212-efde-1523-785feabcd123, true)
D	14:35:27.853	gatt.setCharacteristicNotification(00006002-1212-efde-1523-785feabcd123, true)

I have also saved the sniffer trace following next procedure (Attached):Android_Pairing_without_bonding_18_05_22.pcapng

- Device advertising

- Device connected using nRFConnect (with Wireshark all frames appear as empty, and as I have said, looking at nRFConnect, no services information is given)

- Device is disconnected from nRFConnect and it starts advertising again

Hope it helps

Dani

[Dani]

Hi Hung,

The configuration of the characteristic using BLE_GAP_CONN_SEC_MODE_SET_ENC_NO_MITM, must it apply to both CCCD and attribute values?

Dani

[Hung Bui]

Hi Dani, 
Yes , correct. This is so that you don't need to bond with MITM and the sniffer can be easier to decrypt the connection.