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?

[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.

[Anthony Ambuehl]

The second pairing pop-up only occurs when nrf_ble_lesc_request_handler() processes the LESC request and sd_ble_gap_lesc_dhkey_reply() is called.

Is it possible the softdevice is not handling the LESC reply correctly?

I haven't tested the LESC example yet, maybe this double pairing pop-up issue always occurs with Nordic's imlementation of LESC key processing?

[Anthony Ambuehl]

I have confirmed the ble_app_multirole_lesc_s140_pca10056 example gets the pairing pop-up twice.  The second pairing pop-up presents a PIN code.  This is not very useful since the PCA10056 does not have a display or keyboard inputs.

Our device also lacks a display and inputs.

For a device implementing "Just Works" with LESC key's.. is there a way to avoid this double pop-up?

[Anthony Ambuehl]

I also confirmed with an unmodified SDK17, in the ble_central_and_peripheral/experimental/ble_app_multirole_lesc example the pairing pop-up is sent twice with the second pop-up including a PIN number.

In my application with no I/O capabilities is there anyway to not have the second pop-up since there is no ability to enter a PIN?