nRF52840 random disconnection

Hi Daniel, 

Sorry for the late answer we have another public holiday last week. 

When you set bond = 0 the peers will not exchange/store bond information and every time they connect it's like connect to a new device, hence new pairing. 

I'm not so sure why you got GATT INSUF AUTHORIZATION as it's not related to the process. Unless you have a change in attribute table (for example you add or remove a service/characteristic etc)

If you do : 

SEC_PARAM_LESC=0
sec_param.mitm = 0;
sec_param.io_caps = BLE_GAP_IO_CAPS_NONE;

Would the issue disappear ? 

You don't really have to implement handle for PM_EVT_CONN_SEC_PARAMS_REQ , if pm_conn_sec_params_reply() is not called the default sec param configuration (in your main.c) will be used.

Regarding your code, I noticed this: 

 BLE_GAP_SEC_STATUS_CONFIRM_VALUE is not an event, please remove the code that handle it. 

Inside BLE_GATTC_EVT_HVX: This event is for both notification and indication (from the phoen) If you don't do indication, you should not call sd_ble_gattc_hv_confirm() and you may want to check which attribute handle it addresses to make sure if the notification/indication is to your characteristic. 

As I mentioned, please try to reduce your functionality to narrow down where the issue can be. 

Also if you do SEC_PARAM_LESC=0 and MITM=1, (legacy pairing with passkey) I assume you still see the error ? 

If it's the case, please use the sniffer and track the connection, you would need to input the passkey into "Legacy Passkey" .

I tested here and it is more reliable than the SC LTK option that I suggested earlier. 

Hi Hung,

As you suggested, if I do:

SEC_PARAM_LESC=0

sec_param.mitm=0

sec_param.io_caps = BLE_GAP_IO_CAPS_NONE

, then the issue disappears: I'm asked (As normal) every time to pair, but device connects without problems.

I have also removed BLE_GATTC_EVT_HVX implementation.

Furthermore, I have saved a trace taking into account following parameters:

sec_param.bond           = 1;
sec_param.oob            = 0;
sec_param.mitm           = 1; //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           = 0;
sec_param.keypress       = 0;    
sec_param.min_key_size   = 7;
sec_param.max_key_size   = 16;

And I have done the test with my equipment #A and two smartphone devices:

- Device #1: Xiaomi Mi8

- Device #2:  Samsung Galaxy TabA SM-T580

Before starting testing I have desincrhonized my equipment #A from both Smartphone and Tablet.

Then, these are the steps I have followed, that are all saved in the attached trace:

• Wireshark: I have entered the key for my equipment #A: 6-digit pin code to start saving the trace
• Using nRF Connect from Device #1:
  • I have connected to the equipment #A
  • I have been asked to enter the code
  • Connection is stablished and does not disconnect
• I have manualy disconnected the equipment #A from Device #1 (disconnect option in nRF Tool): equipment #A starts advertising again
• I have proceeded in the same way with Device #2:
  • I have connected to the equipment #A
  • I have been asked to enter the code
  • Connection is stablished and does not disconnect
• I have manualy disconnected the equipment #A from Device #2 (disconnect option in nRF Tool): equipment #A starts advertising again
• I have taken the Device #1 again and I have selected 'Connect' to the same equipment #A:
  • It connects (bonding already done before) but:
    • It disconnects after about 30"
    • Looking at the trace, the 'bad MIC' message has appeared this time
• I have stopped saving the trace at this point

This full sequence is provided in the attached trace.

Hope it helps to find out the reason of this disconnection.

Regards,

Dani

Hi Dani, 
Could you explain why you want to test with 2 central devices here ? 
If you only test with one single central would the issue appear ? 

The sniffer is not designed to store bond information for 2 different central. 

I think it's the best to train you to use our sniffer and would know when the connection is decrypted properly by the sniffer or not. 
I attached here the sniffer trace that I used my phone to test with the gls example. 
It's the stock example from SDK v17.1 the only modification I made was to change 

#define SEC_PARAM_LESC                  0 

So what it does is Legacy pairing with passkey. 

Next I use my phone to connect and pair, I have to enter the passkey printed on UART (please test using a DK) to the sniffer and the phone. 

After that I can see the initial bonding happen in the sniffer and can see all packets (check the time and packet number): 

Then I disconnect then connect again:

You can see that after the START_ENC_RSP I don't have the "encrypted packet decrypted incorrectly". This means the reconnection and re-encrypt can be decrypted by the sniffer. 

Before testing please make sure you unplug and plug the dongle and reset wireshark before testing. 

Also you may want to use this filter: !(btle.data_header.length == 0) to filter out empty packets. 

Please test using only one single central. 

Hi again,

As I told you, the problem with Xiaomi Mi8 seems to appear when I connect to it (bonding already done) after having been connected to an other device: now, I have bonded to Mi8 and I have connected and disconnected (manually) so many times, and it has been impossible to get disconnected after 30".

But then, I have done the same test with the Galaxy Tab A tablet: first time (when bonding) there are no problems with connection. But when trying to connect a second time, GATT_CONN_TIMEOUT is received in the nRF tool log --> Please, find attached this trace.

Regards.

Dani