Peer Manager fails to save bond

RE: Peer Manager fails to save bond

darrenji — Mon, 09 Jul 2018 23:50:44 GMT

One can use the same construct to wait for the peer manager to init fds, and then init locally. This seems... awkward. Is the best practice to assume fds has been initialized by the peer manager and just not do it if the app is going to make fds calls itself?

    peer_manager_init();

    wait_for_fds_ready();

    NRF_LOG_INFO("App Initializing fds...");
    m_fds_initialized = false;

    err_code = fds_init();
    APP_ERROR_CHECK(err_code);

    wait_for_fds_ready();

RE: Peer Manager fails to save bond

darrenji — Mon, 09 Jul 2018 21:07:39 GMT

Apparently there is more to this, because when I init fds in my own code, it prevents fds from working. If I don't init, it works fine.

/**@brief   Wait for fds to initialize. */
static void wait_for_fds_ready(void)
{
    while (!m_fds_initialized)
    {
        sd_app_evt_wait();
    }
}

    err_code = fds_init();/    APP_ERROR_CHECK(err_code);

    /* Wait for fds to initialize. */
    wait_for_fds_ready();

I took this directly from fds SDK example.

Seems like still there is something wrong if fds can't properly handle double-init and fails silently.

RE: Peer Manager fails to save bond

darrenji — Fri, 06 Jul 2018 17:32:56 GMT

OK I finally figured out the problem, and realize now that I should have started with this approach. I went back in the git history to the very first version of my app that claimed to be able to bond with the central and found that it still worked. So I tried different commits binary search style until I found the one that broke fds. It turns out to be makefile related. About a month ago, to try to reduce the makefile size and complexity (and the code size), I went through and removed everything that didn't break the build. It turns out that the application needs

$(SDK_ROOT)/components/softdevice/common/nrf_sdh_soc.c \

even though the app will compile and run without it and generates no errors or warnings.

When I put that file back in the build, all of my fds problems went away.

If this code is required for proper functioning, it seems like there should be some warning generated if you remove it.

RE: Peer Manager fails to save bond

Hung Bui — Fri, 06 Jul 2018 15:29:55 GMT

Hi Darren,

The connection parameter looks fine.

Could you send a simplified version of your peripheral that reproduce the issue. Or you can modify the proximity application to add some fds command to store some data. Similar to what we have here.

RE: Peer Manager fails to save bond

darrenji — Fri, 06 Jul 2018 14:42:10 GMT

Hello,

Here are the settings I'm using now

#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(7.5, UNIT_1_25_MS)          /**< Minimum acceptable connection interval. */
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(30, UNIT_1_25_MS)         /**< Maximum acceptable connection interval. */
#define SLAVE_LATENCY                   0                                       /**< Slave latency. */
#define CONN_SUP_TIMEOUT                MSEC_TO_UNITS(4000, UNIT_10_MS)         /**< Connection supervisory time-out (4 seconds). */

I don't think this is the root of the problem though. What I discovered yesterday is that my app can use fds to store data, if I *don't* enable the soft device first... the filesystem events flow as expected and the write succeeds. However, when the soft device is enabled, my app cannot write data with fds, even if there is no active connection to a central. This is very weird indeed.

It would be quite a lot of work to modify our central, so I'm hoping I can find the answer another way.

Searching online, I've seen many references to this problem from an earlier version of the SDK. For example: this and this and this

But with the current SDK doesn't appear to work this way since there isn't a softdevice_sys_evt_handler_set().

RE: Peer Manager fails to save bond

Hung Bui — Fri, 06 Jul 2018 08:53:51 GMT

Hi Darren,

It's a very strange issue that you have. Could you try to use the same central to test with the unmodified ble_app_proximity ? I would suggest to try with a fresh copy of the SDK. Maybe you need to modify your central a little bit to work with ble_app_proximity.

What else you can try is to use a phone (use nRFConnect app) to connect to your device and bond to the device to see if bond info is stored or not.

Which connection parameter your central use ? We have this case where flash write api failed when the connection timeout was too short, maybe it's related ?

However, in your case , the API failed silently without anytime out, this is very strange. If you can provide a simple central and peripheral code that can reproduce the issue, it would be great help.

Regarding the qwr module, it's queued write assistance module we add to all the examples. It's not needed for all application, only needed if queued write is used. You can remove it.

RE: Peer Manager fails to save bond

darrenji — Thu, 05 Jul 2018 20:55:35 GMT

I have spent many hours tracing the execution of fds and can now see what is failing, but not why. When I write my config data, the write request is passed down into nrf_fstorage_sd.c. The queue_process() function tries to write the header (FDS_OP_WRITE_HEADER_BEGIN) and calls write_execute(). The write_execute() function calls sd_flash_write() which returns NRF_SUCCESS, but the soft device doesn't generate an event, so the fstorage state machine cannot continue to process the write. There is a comment in nrf_fstorage_sd.c in the switch() case that handles the return value from write_execute():

            /* The operation was accepted by the SoftDevice.
             * If the SoftDevice is enabled, wait for a system event. Otherwise,
             * the SoftDevice call is synchronous and will not send an event so we simulate it. */

Because the soft device is enabled, the code is waiting for a system event, and never gets one.

I did the same trace exercise when pairing, and the store of the bond fails for the same reason, no event is generated.

Do you have any advice about how to figure out why the soft device is not posting file system events but seems to otherwise work?

RE: Peer Manager fails to save bond

darrenji — Thu, 05 Jul 2018 17:15:40 GMT

I have one more specific question... I based my app on the proximity app so the code is basically identical with respect to pairing/bonding. One question I have is why when the BLE_GAP_EVT_CONNECTED event happens, nrf_ble_qwr_conn_handle_assign() is called. There are no comments in the example that explain why it would need queued writes. There are no other references to qwr in the app. Is it necessary for something else in the sd? If I remove the calls and take queued write manager out of the makefile, no symbols are missing. I've searched the sdk and online but can't find any obvious explanations. I'm not using long writes in any characteristics.

RE: Peer Manager fails to save bond

darrenji — Thu, 05 Jul 2018 16:33:07 GMT

Hello,

Yes I do have SEC_PARAM_BOND = 1. I'm not pairing to a phone, but to our own device. Our Central device has been working for 3 years bonding successfully to another peripheral.

What I'm seeing with the nRF is that fds fails silently. The high level call to write returns SUCCESS, but the actual asynchronous write to flash never happens and no event or error is reported. I've seen this both with the peer manager's internal write to save the bond data, and with my own call to fds to write config data.

It seems like no matter what I'm doing, fds shouldn't fail silently.

RE: Peer Manager fails to save bond

Hung Bui — Thu, 05 Jul 2018 08:12:25 GMT

Hi Darrenji

Sorry that I misunderstood your issue.

I assume you have set SEC_PARAM_BOND = 1 to enable bonding, not just pairing.

I would suggest you to use the same phone to test with one of our example, the ble_app_proximity for example to make sure the central handle bonding properly.

I don't think it would be a problem storage your own data with fds and have the peer manager working at the same time.

Please enable debugging to get more log from the peer manager unit. You need to add DEBUG in the preprocessor symbols and enable logging either by RTT or UART.

RE: Peer Manager fails to save bond

darrenji — Wed, 04 Jul 2018 16:31:28 GMT

Hello and thanks for the quick response.

I have set allow_repairing to true during my testing and it doesn't make any difference. In any case it shouldn't matter because the problem is not that the pairing fails, it's that the key data isn't being saved. In other words, I can delete all bonds on the nRF device (so it should not recognize any previously paired devices) and still when creating a new bond the key data isn't saved.

My steps are:

1. Delete all bonds on both central and peripheral

2. Pairing initiated and succeeds, get a correct and working connection.

3. power cycle the peripheral; on reconnect peripheral won't connect with error PM_CONN_SEC_ERROR_PIN_OR_KEY_MISSING.

4. back to step 1 above.

So my issue is not that pairing fails, it's that re-connecting after pairing fails because the peripheral didn't save the bond even though write_buf_store() is being called after pairing.

As I mentioned, my app is also using fds. Is there anything I need to be sure to do or not do when using fds in order to not interfere the with Peer Manager's use of fds?

RE: Peer Manager fails to save bond

Hung Bui — Wed, 04 Jul 2018 12:16:09 GMT

Hi,

We would need to know what you set in your conn_sec_config when calling pm_conn_sec_config_reply().

If you have a look at our example, ble_app_proximity for example you can see we set allow_repairing = false inside pm_evt_handler():

case PM_EVT_CONN_SEC_CONFIG_REQ:
{
// Reject pairing request from an already bonded peer.
pm_conn_sec_config_t conn_sec_config = {.allow_repairing = false};
pm_conn_sec_config_reply(p_evt->conn_handle, &conn_sec_config);
} break;

This mean, if the central lose bond information, the device would reject re-bonding. The reason for this is to avoid attacker force a device to delete original bond information and force a new bond where they can be sniff the bonding process or to be MITM.

If you set allow_repairing = true, the device supposed to replace old bond information with new one. I would need you to reproduce the issue with our example so we can try here.

RE: Peer Manager fails to save bond

darrenji — Wed, 04 Jul 2018 01:05:29 GMT

I fixed this in my code, hoping that would solve the problem: https://devzone.nordicsemi.com/f/nordic-q-a/35426/fds-example-conflicts-with-peer-manager

But after erasing all of flash and reprogramming the soft device, no luck.

I forgot to mention originally that I'm using fds to save a few bytes of calibration data, and there appears to be an order-of-init issue with fds. if I init BLE and peer manager before I init ads, I can't write to flash successfully. But if I init fds first it works. In neither case does the peer manager save data every time. oy.