This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

The nRF52 bonded device is automatically unbonded when the Android phone is rebooted.

Hello!

I am developing an application which is connecting to an nRF52 board using the Android-BLE-Library implemented by Nordic
The application is doing the following:

  1. Perform an LE scan using Google's recommended Android stock class, which is BluetoothLeScanner, to scan for the board -> as a result the nRF52 board is found by the BluetoothLeScanner
  2. The app is sending a connect request to the nRF52 board -> as a result it successfully connects
  3. Then the application performs a write with response request to a characterisc which require bonding - in my case I am performing a write request to enable the indications on a secure characteristic
  4. Since it is a secure writing, and the board is requesting bonding, the Android framework will automaticaly initiate the bonding - no code required on the Android app side to perform the bond -> as a result the bond succedes and then I get the write response back that the write completed successfully
  5. I check the bonded devices list in the Android Bluetooth setting screen and the nRF52 board is listed
  6. I reboot the phone. When the phone is rebooted I check again the Bluetooth settings screen and the nRF board is still listed

The FW team did the following changes in one monolithic commit, on the FW side:

  • in prj.conf file the following line was added: CONFIG_BT_PRIVACY=y
  • for the secure characteristics, in the BT_GATT_CHARACTERISTIC(...) the 3rd parameter was changed from BT_GATT_PERM_WRITE_AUTHEN into BT_GATT_PERM_WRITE_ENCRYPT for writing and from BT_GATT_PERM_READ_AUTHEN into BT_GATT_PERM_READ_ENCRYPT for reading
  • the initial two steps bonding with numerical confirmation was changed into one step just-works bonding
  • and some othere changes which I couldn't figure out what those means

Now it comes the problem. After these changes all the steps above where successfull except step 6 - after rebooting, the device was not listed anymore in the bonded devices list in Bluetooth settings screen. So before rebooting the device was listed, after rebooting the device was automatically unbonded.

Is it possible that any of the changes the FW team did could lead to this behaviour?
Is it possible that I am doing something wrong on the app side?

Thank you!

Parents
  • Hi,

    I think we might need an on air sniffer log here to find the problem. Maybe you can do that with nRF sniffer tool if you have an nRF52-DK you can use for sniffer. Some other questions while waiting for your sniffer log

    1. Does the problem also occur if you disconnect and reconnect the peripheral before step 6?

    2. I have been working on this problem in a different case, I want to find out if your issue is related. To confirm please comment out the line bt_conn_set_security() that is found in bt_gatt_connected() in gatt.c and repeat your setup. Please do this test first.

    Edit: Do make sure you re-bond after doing the change in step 2.

    Best regards,
    Kenneth

  • Hi Kenneth,

    Does the problem also occur if you disconnect and reconnect the peripheral before step 6?

    Before rebooting the phone, the connection is stable. The app reconnects every time with no problems.

    I have been working on this problem in a different case, I want to find out if your issue is related.

    That post is for one of our issues. One of my colleagues from the FW team posted it and my colleague said that the fix Nordic suggested is already integrated in the FW code. This issue doesn't trigger any error while connecting or while bonding as the issue in the link. So it is not the same issue.

    To confirm please comment out the line bt_conn_set_security() that is found in bt_gatt_connected() in gatt.c and repeat your setup. Please do this test first.

    My FW colleague told me this code is also already in.

    think we might need an on air sniffer log here to find the problem. Maybe you can do that with nRF sniffer tool if you have an nRF52-DK you can use for sniffer.

    I will ask my FW colleagues to take the sniffer log and attach it to this ticket.

    Thank you!

  • Here is a third log where encryption seemingly succeed, but the bug was still triggered. Unfortunately it seems that the sniffer failed to capture the encryption keys. And despite several more runs the sniffer failed each time

    I've also added a fourth log, it is an bt snoop log from android from a run where the bug was triggered. If I'm reading it correctly, then encryption succeed in that case.


    Please let me know if there is anything else you need in order to be able to help us solve this bug.

    firstTriggeredButEncrypted.pcapng


    btsnoop�� ?u��� ?u�� ?u��� ?u�<� ?u��3��
    � ?u�!3� ?u�{� ?u��		�� ?u�	
    
    � ?u�
    	�DnFP�� ?u��GG� ?vD�������������?���a���� ��������� ?v�� ?v������?[�� ?v�V� ?v
    �V� ?v�m� ?v
    �m� ?v�� ?v?� ?vN� ?v�U� ?v�S�� ?v�S�( a � ?v{z� ?v]z� ?v� � ?v � �� ?v"' 
    
    � ?v$- �� ?v$� � ?v&� ������ ?v'1 � ?v)� �}� ?v*W* � ?v,f*  � ?v-�/ � ?v/�/ ��B��B� ?v1�# � ?v4e# H� ?v5�: 		� ?v7�: r� ?v9; � ?v;C; � ?v;� � ?v>� � ?v@��������=� ?vCr� ?vC�� ?vFl� ?vI) � ?vL�) � ?vM. �� ?vO. � ?vO^E� ?vQ_E� ?vQ�G� ?vSwG� ?vS�C� ?vVC� ?vVW$Z� ?vX$� ?vXs � ?vZ� ?vZ\� ?v^�� ?v_5S�� ?va�S�( a � ?vbg��� ?vhN���� ?vj��wbt� ?vre��� ?vr�R�	wbt�� ?vx�R� ?vx� � ?v{4 �mw����� ?v{iR�	wbt�� ?v��R
    
    � ?v�) E���m� ?v�j � ?{�&`� ?{�&��� ?{}R�	wbt�� ?{�R��� ?{�R�	wbt�� ?{"SR��� ?{r�R�	wbt	�� ?{x�R��� ?{y�R�	wbt
    �� ?{IR��� ?{�R�	wbt
    
    �� ?{��R� ?{��:3��� ?{�E:� ?{��� ?{��� ?{�� ?{�+� ?{�`� ?{��� ?{�G� ?{�1� ?{��� ?{��� ?{��� ?{�a��� ?{��R�	wbt
    �� ?{��R��� ?{��R�	wbt
    �� ?{��R��� ?{�R�	wbt
    �� ?{�:R��� ?{��R�	wbt
    �� ?{��R��� ?{�R�	wbt
    �� ?{�oR��� ?{�/R�	wbt
    2�� ?{�NR� ?{��� ?{�� ?{�X� ?|�� ?|E� ?|
    2��� ?|
    pR�	wbt
    /2�� ?|R��� ?|%�R�	wbt
    -/2�� ?|-R��� ?|-�R�	wbt
    -/2�� ?|2�R� B���W�		� B���W�''� B�]W�#�eZ֤ɭ�H��{�V����������������
    
    � B��W�� B��W����'
    
    � B�
    *W�� B��A � B�A 
    
    � B��B � B��B 
    
    � B�OB � B�J�B � B�K�A ��� B�NeA � B�N�A ��� B�P�A 
    
    � B�QB � B�S\B 00� B�H��-Vf�����	bcdef�eZ֤ɭ�H��{�V� B��\W�
    
    � B�ʅW�
    
    � B��_B � B��B � B�%A ��� B��A � B�7zC f���`0(�� B�?�C ""� B��>
    f���$�� B�� � B�M � B�U�>%A� B�WO� B�o�� B��>HH		� B��>� B���>HH� B�FMY7� B���	&� B��r� B��� 	&� B��-� B��� �� B��� � B��� B��� 	� B��� � B�� C.�%��� B��� � B�� �wg�F�� B��i � B�ý >s���� B��� � B��+ ����|d�PJJ� B��EA���ܚM��~!��☪!$��f~��`yg����t6������������l��_q�HF
    �c� Cd�  � C Aa�'͔��9�����Y���1  � C$`�;�u�%����b3�9m훒\�B���M� C
    �^������[��cz� C< vɟ�@��ոS�5��� C D � C#$ z�&�gzFL� C#� � C&M ��4��� C'>z�&�gzFL��4��� C��� Cq� .YЛ�I���2Q�t�$�� Cv�
    3�Mu�<��SRش� C
    
    � C�>
    �� Cּ 
    �(=�>n�]%5�E  � C�f ��9ת!@��`��� C� � C�Q� Cc@�o(}��-�b�r�� Cg	�DnFP�� C:�� C	�iW�		� C	�?W�
    
    � C	�vW�	,�,�
    
    � C	��W�� C	�VW�@�
    
    � C	�-W�� C	��A ��� C	�'A 
    
    � C	ņB � C	��B 
    
    � C	�(B � C	�QB � C	͙A ��� C	��A � C	�A ��� C	�A 
    
    � C	ӏB � C	�rB ++� C
    �3' 'f���c@�o(}��-�b�r�� C
    �6	&� C
    �8' � C
    ��N f���� C
    �-N 
    
    � C
    ��B � C
    ”� C
    ÈB � C
    �A ��� C
    �A � C
    ǎ- � C
    �d- 
    
    � C
    ��B � C
    �B 
    
    � C
    �w � C
    �U��*� C
    ��� C� 
    		bcdef� C)��(� C7�� CU� 	� CXV��(� Cr�� C�� ?f8�����Iꐀ�� C����(� C�?� C�'  ';� C̵(��(� C�� Co (0
    1346� C�7��(� C"F� C@u 7=צ�N�ơLW��c�� CC�>��(� C\�� Cz� >A��`tR����L��S�� C|B��(� C�T� C�� 	B
    � C�h(� C��� C�c 	
    � C��(� C�� C*o 	 *
    )+� C,Z(� CF�� Ce� 
    		*+� Cg(� C��� C�k 	
    � C�D	� C�v� C٦ 
    )� C�	(� C�H� C2� 		
    � C59	(� CPk� Cl� 	
    *
    *� Cn-
    (� C��� C�� 
    		*� C��(� C��� C�� 	
    � C��(� C��� C 	
    � C!�(� C;y  � CXi 	%q�˿J��K&_��� CY�(� Ct�  � C� 	v�� �r��O��j�I � C��(� C�T� CӁ 	
    � CՇ	� C�I� CI 
    )� C	� C%.� CB� 
    )� CE�(� C]�� C�� 	
    � C�c(� C�1� C�� 
    		*� C��(� Cӥ� C� 	
    � C�y	� C@� C-A 
    )� C/�(� CI�� Ce� 	
    � Cj�(� C�P� C�� 	�*�*� C�](� C��� C�w 	
    � C� '(� C�/� C3O 	 
    � C6� '(� CPZ� Cn� 	!"++$"%,+� Cs[%'(� C��� C� 	%
    � C�/	##� C�� C�� 
    #)� C�	&'� C�� C:� 
    &)')� C=3(0(� CW�� Cu� 	(
    � Cx(0(� C�*� C�� 	)*$*+,)*� C��,0(� C�� C%� 	-.&*/0'*� C'V00(� CD\� C_� 	0
    � Cb[13(� C|�� C�	 	1
    � C��13(� C�� Cԡ 
    		2
    3*� C��33(� C��� C� 	3
    � C+46(� C,k� CJ� 	4
    � CL?46(� C��� C�P 
    		56*� C�-66(� C�~� C�f 	6
    � C޾7=(� C��� C� 	7
    � C{7=(� C3�  � CR� 	89�ڦ�N�ơLW��c�� CT�9=(� Cny  � C�� 	;<&�mgi��H�#��
    � C��<=(� C�R� C�p 	<
    � C�0	::� C�� C� 
    :)� C	==� CT� C;� 
    =)� C<�>A(� CY~� Cvj 	>
    � Cx[>A(� C�  � C�� 	?@H|�t&��N��(x.�� C��@A(� C�%� C� 	@
    � C�F	AA� C	�� C&W 
    A)� C*� $$�� C+�	� C-� � C`�
    
    � C~� � C�
    � C�I� C� 
    bcdef� C�
    � Cժ� C�� D
    
    � C�x>
    $�� CA<5 (*� CAE�
    � CAKC (*� CAN � CBK�
    
    � CG��>
    $*� Ce�oW�
    
    � Ce�W�
    
    � Ce�/B � Ce��B � Ce�A ��� CfRA � CfbW�		� Cf�W�
    
    � Cf <W�	,�,�
    
    � Cf"�W�� Cf"�W�@�
    
    � Cf%!W�� Cf(�A ��� Cf+A 
    
    � Cf+~B � Cf-�B 
    
    � Cf3�B � CfWdB � CfXkA �f� Cf[�A � Cf\fA �f� Cf^�A 
    
    � Cf_0B � CfhpB � C�W�		� C‚W�� C��W�
    ����
    
    � C��W�� C��W� �
    
    � C�W�� C�ZW�����
    
    � C��W�� C�IW��
    
    � C��W�
    � C�sW�����
    
    � C��W�� C�6W��
    
    � C��W�� C��W�	����
    
    � C��W�� C�3W�	�
    
    � C�oW�� C��W�
    L����
    
    � C��W�� C�W�
     �
    
    � C�_W�
    
    
    � C��B � C�$kB � C�%A ��� C�'hA � C�(�A ��� C�+�A 
    
    � C�,sB � C�.�B � C�;�W�
    
    � C�HW�� C�O�W�
    
    � C�R+W�� C�T�W�
    
    � C�W%W�
    � C�Z0W�	
    
    � C�]�W�� C�dW�
    
    
    � C�f�W�
    
    � C�pB � C��B � C��A �f� C��A � C��A �f� C��A 
    
    � C�&B � C� �B 77� HxX��4�0f�����k�g����,�`77� Hyb��4�0f�����l�g��77� H|�i�4�0f�����o�g�l�� H|��� H}4J f���� H}LR ..� H}M�C *0(�0(�� H}WCC � H�61Y�� H�L�Y���0J+

  • The reason we are not able to decrypt the connection is due to LE secure connection is used (with diffie-hellman), unfortunately such connection can't be decrypted.

    However, I can find that the slave send a security request upon re-connection here, ref:

    This means (or at least suggests) that if the nRF52 is the peripheral device, then this FW have not followed the:

    "I have been working on this problem in a different case, I want to find out if your issue is related. To confirm please comment out the line bt_conn_set_security() that is found in bt_gatt_connected() in gatt.c and repeat your setup. Please do this test first."

    Can you double check with your collegues what may be calling bt_conn_set_security() here in the project, if not done by the bt_gatt_connected() in gatt.c?

  • This means (or at least suggests) that if the nRF52 is the peripheral device, then this FW have not followed the:
    Can you double check with your collegues what may be calling bt_conn_set_security() here in the project, if not done by the bt_gatt_connected() in gatt.c?


    That patch isn't integrated into our build system yet, since we need to patch the OS.
    Because of that some builds have it, others don't.

    I have previously tested this bug both with and without this patch, and the behavior was the same in both cases. Which is the reason it was (accidentally) left disabled when running the logs in this case.

  • Please enable the patch before bonding, and use the patch. It may influence the issue in some way.

    If you can disable LE secure connection (and instead use just works) for security it could be interesting to see if the issue also exists. With just works it would be possible to decrypt the link also.

    Kenneth

  • Please enable the patch before bonding, and use the patch. It may influence the issue in some way.

    Here is an updated capture with the patch applied. The bug was triggered in the same manner as above

     withPatchAplliedTriggered.pcapng



    If you can disable LE secure connection (and instead use just works) for security it could be interesting to see if the issue also exists.


    Could you instruct me in how to do that? I know I can use e.g BT_SMP_SC_PAIR_ONLY to disable 'legacy just works', but I can't see any option to disable 'le just works'
    thanks

Reply Children
  • Poorp said:
    Here is an updated capture with the patch applied. The bug was triggered in the same manner as above

     This log doesn't show the re-connect though. 

    Poorp said:
    Could you instruct me in how to do that? I know I can use e.g BT_SMP_SC_PAIR_ONLY to disable 'legacy just works', but I can't see any option to disable 'le just works'
    thanks

    Can you try to comment out CONFIG_BT_TINYCRYPT_ECC and possible add CONFIG_BT_ECC=n. I guess I should try this myself first.

    Kenneth

  •  This log doesn't show the re-connect though. 

    What do you mean "the reconnect"? In the steps to perform the bug there is only one connection, the inital on-boarding. After that the device is turned off and left off. Only the phone is turned on when the bond is deleted.

    Can you try to comment out CONFIG_BT_TINYCRYPT_ECC and possible add CONFIG_BT_ECC=n. I guess I should try this myself first.

    I'll try that and report back

  • If one of the devices are out of range and/or turned OFF, then there will a disconnect, until the peer again is in-range or turned ON, then there will be re-connect. I assume that you first see an issue on the re-connect?

    Kenneth

  • If one of the devices are out of range and/or turned OFF, then there will a disconnect, until the peer again is in-range or turned ON, then there will be re-connect. I assume that you first see an issue on the re-connect?


    No, I should have been more clear. The short version is

    1) Phone and one device are bonded/connected
    2) device is turned off and never turned on again (so no more traffic)
    [At this point the Phone still has the bond, and can reconnect if the device is turned on again (which it never is, but we tested]
    3) Phone is rebooted, once it has started again the bond is gone

    It is also worth noting that this bug does not happen if one uses nrf connect to trigger bonding by writing to one of the attributes. Only if it is done by our app



    Can you try to comment out CONFIG_BT_TINYCRYPT_ECC and possible add CONFIG_BT_ECC=n. I guess I should try this myself first.


    That fails to compile due to smp requiring them, I didn't investigate further than the compilation error. So there may be a workaround

    subsys/bluetooth/host/libsubsys__bluetooth__host.a(smp.c.obj): in function `bt_smp_init':
    /home/censored/.local/opt/ncs/zephyr/subsys/bluetooth/host/smp.c:5564: undefined reference to `bt_pub_key_gen'

  • I assume that you first see an issue on the re-connect?

    As I said before, disconnect/reconnect works just fine. No errors triggered.

    So before rebooting the phone, I tried disconnect/reconnect dozens of times and it just worked fine. The reconnection always happened successfully.

    When the phone is rebooted then the bond is removed and that is the issue that the device is not bonded anymore (not present anymore int bonded devices list on Android side).

    If one of the devices are out of range and/or turned OFF

    The issue happens even when is just one device connected.

Related