This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

nRF52840 random disconnection

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

Parents
  • 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. 

  • 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.

  • 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

  • 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. 

  • Hi,

    I have been doing some tests without bonding and with BLE_GAP_CONN_SEC_MODE_SET_ENC_NO_MITM, and with SEC_PARAM_LESC=0. In CCCD in all services I have implemented this:

    BLE_GAP_CONN_SEC_MODE_SET_OPEN(&cccd_md.read_perm);
    BLE_GAP_CONN_SEC_MODE_SET_ENC_NO_MITM(&cccd_md.write_perm);

    Now, equipment is not disconnecting.

    Please find attached a sniffer trace doing the following procedure:

    - Equipment advertising

    - Equipment connected and receiving data

    - Equipment disconnects and starts advertising again

    So, from that point, how to find the solution to the problem I have? I need to use bonding, and I'm using a 6 digit-pin.

    DaniAndroid_Pairing_without_bonding_No_MITM_19_05_22.pcapng

  • Hi Dani, 
    It's possible for the sniffer to track Legacy pairing with Passkey. You just need to enter the passkey in the Sniffer menu and click the "Arrow" button (before input that into your phone):

    But I found this method is not very reliable as the central and peripheral may change the LTK in further re-connections. 


    It's also possible to track LESC pairing if you can find the LTK key. And I found this is a more reliable solution. 


    To print the LTK out you can edit security_dispatcher.c in sec_info_request_process () as follows: 

        NRF_LOG_INFO("LTK: length =%d 0x",p_enc_info->ltk_len);
        for(int i=0;i<p_enc_info->ltk_len;i++) NRF_LOG_INFO("%x ",p_enc_info->ltk[i]);

    You need to input the LTK into wireshark, and need to pay attention to the endianess. Basically if the log print out this (after you disconnect and reconnect to bonded device): 


    You need to input this to the sniffer and click the arrow button: 

  • Hi Hung,

    Should I see the LTK info through the log of the nRF Connect tool?

    I'm not seeing it.

    Dani

Reply Children
Related