Double pairing request with android

[Erikk]

I am testing several phones with a specific App that I connect to my nRF52832. Some phones pair nicely but others do not pair as expected. They display two pairing requests.

- I have checked that my BLE device only sends one pairing request which is the case
- I tried increasing the PM_HANDLER_SEC_DELAY_MS and also setting it to zero but in both cases we would still get two pairing requests

- I allow repairing of already bonded peers

- As described here: https://devzone.nordicsemi.com/f/nordic-q-a/76912/double-pairing-prompt-in-android this behavior might be due to having several services and being peripheral. In my setting the nRF acts as central and connects to the phone which is in peripheral role. Then the phone exposes services as server which the nRF discovers as client. The nRF also exposes services. 

What could be the reason we get two pairing requests with some android phones?

When I log the connection trace I get the following messages:

[ovrebekk]

Hi 

Do you have access to a Bluetooth sniffer in order to sniff the communication occurring over the air?
Then it is much easier to figure out what is happening in the background. 

Even without an expensive high end sniffer (Ellisys, FrontLine etc) it is possible to use a Nordic devkit as a cheap Bluetooth sniffer, as explained here. 

In the mean time I will check with our Android developers if this is a known issue. 

Best regards
Torbjørn

[Erikk]

Thank you for your response.

I do use the nRF Dongle with wireshark as a sniffer tool. The problem is that because I am using LESC the sniffer cannot follow the encrypted connection. I read that both devices would need to be in "Secure Connections debug mode" (https://infocenter.nordicsemi.com/index.jsp?topic=%2Fug_sniffer_ble%2FUG%2Fsniffer_ble%2Fsniffing_actions.html)

However, I cannot put the android device into secure connections debug mode as far as I know? Maybe I will need to use the android debugging capabilities?

[ovrebekk]

Hi 

I found an old case which seems to discuss the same issue, but it doesn't seem like a solution was found unfortunately. 

Most of the Android expertise is also on holiday, just to complicate it further ;)

Tomorrow I will do some testing with the phones I have available here, trying to figure out what the difference is between phones that show this issue and those that don't. Hopefully that can give some more clues. 

Best regards
Torbjørn

[Erikk]

Ok thank you.

You can try with the nRF Desktop App Bluetoot Low Energy Application. There just connect to a Samsung (also double request) or Pixel phone. Then bond and specify "no keyboard, no display" to use "just works" (parameters as specified here). The phone should show two pairing requests.

[ovrebekk]

Hi

Have you been able to reproduce the issue based on one of the standard SDK examples?

As an example, should I be able to use the ble_app_hrs_c example on the nRF5 side, and set up the peripheral on the phone in the nRF Connect app?

I tried this without being able to reproduce the issue, but at the moment I am testing on my own Huawei P20 Pro, which might behave differently compared to the Samsung and the Pixel you have tested with. 

Best regards
Torbjørn

[Erikk]

Hi,

I have tested the ble_app_hrs_c with the Samsung Galaxy A51 and the Redmi 8 which had the double pairing request problem with my nRF device.

-> They both show the same behaviour with a double pairing request in the nRF Connect App. 

Can we therefore conclude that its a problem in the BLE stack of these phones?

[ovrebekk]

Hi

I am pretty sure this is an issue on the Android side, yes. 

I guess the question now is whether or not a workaround exists. Some times it is possible to avoid issues like this by changing something in the sequence of events after establishing a connection, which the central device might be able to influence. 

Best regards
Torbjørn

[Erikk]

what I do is to bond immediately when a new device that I connected to is found with the function below. do you see an issue with that?

ret_code_t pm_conn_secure(uint16_t conn_handle, bool force_repairing)
{
    VERIFY_MODULE_INITIALIZED();

    ret_code_t err_code;

    err_code = sm_link_secure(conn_handle, force_repairing);

    if (err_code == NRF_ERROR_INVALID_STATE)
    {
        err_code = NRF_ERROR_BUSY;
    }

    return err_code;
}

[ovrebekk]

Hi 

Do you mean that this is a device with which you have previously bonded?

This is a bit different from the way it is normally done if you are doing it after connecting to a new device that you haven't previously bonded with. Then it is customary to wait for the client (normally the phone) to try to access a protected characteristic, and have it start pairing and bonding when the access fails with the INSUFICIENT_AUTHENTICATION error. 

Best regards
Torbjørn