Android pairing pop-up appears twice

[Anthony Ambuehl]

I would like to establish bonding between my device and an android phone.

My device is acting as both a central and peripheral.  It functions in peripheral role in relation to the phone.  The mobile app is developed only for Android for now.

Application firmware is developed against SDK 16.

I am using peer_manager.  I call pm_init and pm_sec_params_set with

memset( &sec_param, 0, sizeof( ble_gap_sec_params_t ) );

// Security parameters to be used for all security procedures.
sec_param.bond = 1;
sec_param.mitm = 0;
sec_param.lesc = 1;
sec_param.keypress = 0;
sec_param.io_caps = BLE_GAP_IO_CAPS_NONE;
sec_param.oob = 0;
sec_param.min_key_size = 7;
sec_param.max_key_size = 16;
sec_param.kdist_own.enc = 1;
sec_param.kdist_own.id = 1;
sec_param.kdist_peer.enc = 1;
sec_param.kdist_peer.id = 1;

In the ble event handler for BLE_GAP_EVT_CONNECTED, I call

ble_gap_evt_t const *p_gap_evt = &pEvt->evt.gap_evt;

 pm_conn_secure( p_gap_evt->conn_handle, false );

( I have also tested using pm_handler_secure_on_connection with PM_HANDLER_SEC_DELAY_MS set to 75 and 500 mS )

I am NOTcalling pm_conn_sec_prams_reply at all.

I am calling pm_conn_sec_config_reply with allow_repairing = false

The problem I'm encountering is that the pairing pop-up is appearing twice to the user.  Is there a way to change the connection sequence so this pop-up only occurs 1 time?

[Anthony Ambuehl]

I'm not sure about the source code lineage of the mobile app, its been developed by an 3rd party / outsourced dev team.  I do know it includes Nordic's library for DFU, so perhaps that is causing the bonding behavior.

Is there an event which would indicate service discovery has completed?    I can wait until my devices discovery of the central phone services has completed (device includes a current time service client) but I'm not clear how I would know the phone has completed its discovery.

[Simonr]

Hi

In our SDK we have the BLE_DB_DISCOVERY_COMPLETE event for indicating that the discovery of a service is complete, so try implementing this event before calling the pairing request for instance.

Best regards,

Simon

[Anthony Ambuehl]

A couple of issues with that.

1) BLE_DB_DISCOVERY_COMPLETE only indicates the completion of the discovery of a single service.  If multiple services are requested to be discovered, this event will be emitted multiple times.

2) BLE_DB_DISCOVERY_COMPLETE only relates to discovery from the nRF device, and does not indicate anything about the discovery procedure from the mobile phone.

3) Regardless, our code in the nrf does not call ble_db_discovery_start until either PM_EVT_CONN_SEC_SUCCEEDED or PM_EVT_CONN_SEC_FAILED is received.  We did this to avoid discovery being disturbed by the connection pairing procedure.   

[Simonr]

Hi

As you can see from the nRFConnect log there is a PAIRING_REQUEST from the nRF before and after the service discovery, as it's not able to pair before the services have been discovered it seems. Please try to wait for service discovery before starting pairing instead of the other way around.

The support we have for mobile application development is rather limited I'm afraid, as our expertise/focus lies with our products and are not experts on Android development. 

Best regards,

Simon

[Anthony Ambuehl]

As I explained,  the service discovery from my device does not start until after the initial pm_conn_secure has resulted in a success or failure, therefore it is not the cause of the initial  connection attempt failing.

I'm now wondering if this has something to do with the implementation of the LESC processing for FreeRTOS.  I followed a similar approach that was suggested in this thread https://devzone.nordicsemi.com/f/nordic-q-a/71078/event-driven-nrf_ble_lesc_request_handler/292093#292093  The LESC processing (nrf_ble_lesc_request_handler) is performed from the idle task and therefore sd_ble_gap_lesc_dhkey_reply is asynchronous to other events.