<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://devzone.nordicsemi.com/cfs-file/__key/system/syndication/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Can´t pair again after disconnection</title><link>https://devzone.nordicsemi.com/f/nordic-q-a/95532/can-t-pair-again-after-disconnection</link><description>Hello, 
 I have a custom peripheral and a custom central device. I based my code on central_uart and central_hids. 
 The central scans for the peripheral, and once found (by UUID) connects, an sets security to L4 (paired and encrypted, using fixed password</description><dc:language>en-US</dc:language><generator>Telligent Community 13</generator><lastBuildDate>Tue, 10 Jan 2023 10:48:46 GMT</lastBuildDate><atom:link rel="self" type="application/rss+xml" href="https://devzone.nordicsemi.com/f/nordic-q-a/95532/can-t-pair-again-after-disconnection" /><item><title>RE: Can´t pair again after disconnection</title><link>https://devzone.nordicsemi.com/thread/404048?ContentTypeID=1</link><pubDate>Tue, 10 Jan 2023 10:48:46 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:f14706a9-f4a2-476e-9402-f6d83926f701</guid><dc:creator>Joao Dullius</dc:creator><description>&lt;p&gt;Thanks for all the explanations!&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Can´t pair again after disconnection</title><link>https://devzone.nordicsemi.com/thread/404047?ContentTypeID=1</link><pubDate>Fri, 06 Jan 2023 08:14:53 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:a33504ad-8a0e-4e0c-b88f-abe2f6e81d63</guid><dc:creator>Einar Thorsrud</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;You always need to call settings_load() after reset when using settings. This is also the case when using&amp;nbsp;CONFIG_BT_SETTINGS=y, as described in the &lt;a href="https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.2.0/kconfig/index.html#CONFIG_BT_SETTINGS"&gt;documentation&lt;/a&gt;.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Can´t pair again after disconnection</title><link>https://devzone.nordicsemi.com/thread/404046?ContentTypeID=1</link><pubDate>Thu, 05 Jan 2023 18:10:00 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:35b33508-a926-43ba-b103-35ed41947353</guid><dc:creator>Joao Dullius</dc:creator><description>&lt;p&gt;Hi Einar,&lt;/p&gt;
&lt;p&gt;Thanks. I think I has a misconception on pairing vs bonding, but now it is clear.&lt;/p&gt;
&lt;p&gt;I was able to solve the reconnecting issue in two ways:&lt;/p&gt;
&lt;p&gt;1) By only using pairing, but not bonding.&lt;/p&gt;
&lt;p&gt;The&amp;nbsp;&lt;span&gt;CONFIG_BT_BONDABLE=n did the trick to force the central to restart the pairing every time the peripheral reconnects.&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;2) By using bonding:&lt;/span&gt;&lt;/p&gt;
&lt;p&gt;&lt;span&gt;I modified the peripheral, and added the following in prj.conf:&lt;/span&gt;&lt;/p&gt;
&lt;div&gt;
&lt;div&gt;&lt;span&gt;#Enable to Save BLE Settings&lt;/span&gt;&lt;/div&gt;
&lt;div&gt;&lt;span&gt;CONFIG_BT_SETTINGS&lt;/span&gt;&lt;span&gt;=y&lt;/span&gt;&lt;/div&gt;
&lt;div&gt;&lt;span&gt;CONFIG_FLASH&lt;/span&gt;&lt;span&gt;=y&lt;/span&gt;&lt;/div&gt;
&lt;div&gt;&lt;span&gt;CONFIG_FLASH_PAGE_LAYOUT&lt;/span&gt;&lt;span&gt;=y&lt;/span&gt;&lt;/div&gt;
&lt;div&gt;&lt;span&gt;CONFIG_FLASH_MAP&lt;/span&gt;&lt;span&gt;=y&lt;/span&gt;&lt;/div&gt;
&lt;div&gt;&lt;span&gt;CONFIG_NVS&lt;/span&gt;&lt;span&gt;=y&lt;/span&gt;&lt;/div&gt;
&lt;div&gt;&lt;span&gt;CONFIG_SETTINGS&lt;/span&gt;&lt;span&gt;=y&lt;/span&gt;&lt;/div&gt;
&lt;/div&gt;
&lt;div&gt;&lt;span&gt;&amp;nbsp;&lt;/span&gt;&lt;/div&gt;
&lt;div&gt;&lt;span&gt;And on my main.c I did:&lt;/span&gt;&lt;/div&gt;
&lt;div&gt;
&lt;div&gt;
&lt;div&gt;&lt;span&gt;&amp;nbsp; &amp;nbsp; &lt;/span&gt;&lt;span&gt;if&lt;/span&gt;&lt;span&gt; (&lt;/span&gt;&lt;span&gt;IS_ENABLED&lt;/span&gt;&lt;span&gt;(CONFIG_SETTINGS)) {&lt;/span&gt;&lt;/div&gt;
&lt;div&gt;&lt;span&gt;&amp;nbsp; &amp;nbsp; &amp;nbsp; &amp;nbsp; &lt;/span&gt;&lt;span&gt;settings_load&lt;/span&gt;&lt;span&gt;();&lt;/span&gt;&lt;/div&gt;
&lt;div&gt;&lt;span&gt;&amp;nbsp; &amp;nbsp; }&lt;/span&gt;&lt;/div&gt;
&lt;/div&gt;
&lt;/div&gt;
&lt;p&gt;&lt;span&gt;Question: On this (2) scenario, do I need to do the CONDIF_SETTINGS and the settings_load(), or would CONFIG_BT_SETTINGS=y be enough?&lt;/span&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Can´t pair again after disconnection</title><link>https://devzone.nordicsemi.com/thread/404045?ContentTypeID=1</link><pubDate>Wed, 04 Jan 2023 15:09:01 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:3a1717f5-f963-455c-ae28-bf30cb705c86</guid><dc:creator>Einar Thorsrud</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
[quote user="Joao Dullius"]Based on that, can we assume the issue is on the central side? [/quote]
&lt;p&gt;Not necessarily. Are you only pairing (establishing a single encrypted session), or are you bonding as well (where the keys should be used for consecutive connections)? If you are only pairing, it wold seem the central is in error (as it looks like it has kept the bonding information). But if you are bonding, the issue seems to be with the peripheral, as it should keep the bonding information and use that the next time.&lt;/p&gt;
[quote user="Joao Dullius"]Is there anyway to do the opposite from&amp;nbsp;&lt;span&gt;CONFIG_BT_SMP_ALLOW_UNAUTH_OVERWRITE=y, and force the central to do the bonding from scratch, doing all the .password_entry on both sides again?&lt;/span&gt;[/quote]
&lt;p&gt;If you want to do that on every connection, then simply don&amp;#39;t bond (but pair). If you never want to bond, add&amp;nbsp;CONFIG_BT_BONDABLE=n to your prj.conf.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Can´t pair again after disconnection</title><link>https://devzone.nordicsemi.com/thread/404044?ContentTypeID=1</link><pubDate>Tue, 03 Jan 2023 16:06:16 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:24adf455-e7d1-44bc-ad98-d64286b7329c</guid><dc:creator>Joao Dullius</dc:creator><description>&lt;p&gt;Hi Einar, thanks for the quick response.&lt;/p&gt;
&lt;p&gt;I&amp;#39;m pairing using fixed passwords sent in .passkey_entry callback.&lt;/p&gt;
&lt;p&gt;I did some additional testing:&lt;/p&gt;
&lt;p&gt;1) When paired, if I only reset the peripheral, the central gets the error code (2) when trying to pair again.&lt;/p&gt;
&lt;p&gt;2) When paired, if I erase the peripheral memory (recover board) and reprogram it, I get error code (2) also.&lt;/p&gt;
&lt;p&gt;3) When paired, if I reset the central, when it goes live again the devices will re-pair properly by .passkey_entry callbacks.&lt;/p&gt;
&lt;p&gt;Based on that, can we assume the issue is on the central side? When the peripheral resets, the central thinks it will get back live with the previous bonding settings, which is not the case.&lt;/p&gt;
&lt;p&gt;Is there anyway to do the opposite from&amp;nbsp;&lt;span&gt;CONFIG_BT_SMP_ALLOW_UNAUTH_OVERWRITE=y, and force the central to do the bonding from scratch, doing all the .password_entry on both sides again?&lt;/span&gt;&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Can´t pair again after disconnection</title><link>https://devzone.nordicsemi.com/thread/404043?ContentTypeID=1</link><pubDate>Tue, 03 Jan 2023 14:41:42 GMT</pubDate><guid isPermaLink="false">137ad170-7792-4731-bb38-c0d22fbe4515:c7d39ff8-092c-48ba-98ac-ee43b3b42eab</guid><dc:creator>Einar Thorsrud</dc:creator><description>&lt;p&gt;Hi,&lt;/p&gt;
&lt;p&gt;The error code (2) is&amp;nbsp;BT_SECURITY_ERR_PIN_OR_KEY_MISSING. Is the slave just reset or is the flash erased (or at least the bonding info)? If so, that could explain the error. And in that case, the fix would be either to not delete the bonding info on the peer, or add&amp;nbsp;CONFIG_BT_SMP_ALLOW_UNAUTH_OVERWRITE=y to allow repairing in case the peer has lost the bonding information (this is not without down-sides though, as it would allow an attacker to replace an existing bond with by spoofing the peer address and pairing).&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>