Android pairing pop-up appears twice

RE: Android pairing pop-up appears twice

Anthony Ambuehl — Fri, 29 Oct 2021 15:44:03 GMT

I didn't have time in my budget to do more work on this issue. (I'm a contractor, I don't have unlimited time to chase problems for Nordic) My client agreed this was a minor annoyance that we couldn't fix. If you can capture a trace maybe Nordic will be able to come up with a solution.

RE: Android pairing pop-up appears twice

Simonr — Fri, 29 Oct 2021 11:30:47 GMT

I'm afraid we will need a sniffer trace to get a good look at what's going on over-the-air and what causes this second popup or a way to reproduce it on our end.

It might be best to make a new ticket describing your issue in detail, as this case is getting rather old now and the original poster has been silent for some time. Feel free to link to this case in your new one if you find it relevant.

Best regards,

Simon

RE: Android pairing pop-up appears twice

Andreas48752 — Fri, 29 Oct 2021 10:03:33 GMT

Hi!

I am having the same issue using FreeRTOS and pairing/bonding.

Two Popups are shown on Android.

Does it give any new on this issue?

Thanks, Andreas

RE: Android pairing pop-up appears twice

Erikk — Sat, 10 Jul 2021 22:29:00 GMT

I have encountered a similar issue.

It might be that the android phone just works like that for any kind of connection. For example when trying to connect with a passkey entry I also get two pairing dialogues/notifications. Here the difference is just that the second pairing request is actually required because it shows a PIN or something similar. But with just works the pairing dialogue is also shown, just does not have any PIN or require entering something.

RE: Android pairing pop-up appears twice

Simonr — Wed, 07 Apr 2021 09:21:02 GMT

Sorry about the delayed reply, but we're currently working through the backlog after the Easter vacation.

I see that the link you provided is related to an RTOS, are you using an RTOS like FreeRTOS in your application as well?

I would like to report this internally to the SoftDevice team so they can have a look at what's going on, but could you provide a sniffer trace file so we can get a look at what's going on over the air as well? As of now, I'm not sure how to avoid this second pop-up I'm afraid.

Best regards,

Simon

RE: Android pairing pop-up appears twice

Anthony Ambuehl — Wed, 31 Mar 2021 18:36:20 GMT

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?

RE: Android pairing pop-up appears twice

Anthony Ambuehl — Wed, 31 Mar 2021 18:28:17 GMT

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?

RE: Android pairing pop-up appears twice

Anthony Ambuehl — Wed, 31 Mar 2021 18:21:20 GMT

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?

RE: Android pairing pop-up appears twice

Anthony Ambuehl — Wed, 31 Mar 2021 17:31:21 GMT

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.

RE: Android pairing pop-up appears twice

Simonr — Wed, 31 Mar 2021 10:35:23 GMT

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

RE: Android pairing pop-up appears twice

Anthony Ambuehl — Tue, 30 Mar 2021 23:07:45 GMT

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.

RE: Android pairing pop-up appears twice

Simonr — Mon, 29 Mar 2021 07:30:17 GMT

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

RE: Android pairing pop-up appears twice

Anthony Ambuehl — Fri, 26 Mar 2021 17:27:37 GMT

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.

RE: Android pairing pop-up appears twice

Simonr — Thu, 25 Mar 2021 08:40:55 GMT

Hi again

Is your custom application based on the nRFConnect app, or is it just by chance that they behave similar here? nRFConnect only initiates bonding upon user requests, and from the log you provided it seems like the device trying to initiate bonding right after connecting. You can try letting the app finish discovering services before calling the pairing request, as it seems to be interrupted by service discovery in the nRFConnect log you uploaded.

Best regards,

Simon

RE: Android pairing pop-up appears twice

Anthony Ambuehl — Wed, 24 Mar 2021 16:28:35 GMT

Also, when I pair directly with Android "Pair New Device" in bluetooth settings. I only get the pairing pop-up 1 time.

These are device logs generated while pairing from Android Bluetooth settings:

[00:00:10.922,000] <info> app: phone connected. conn_handle: 0x1
[00:00:10.998,000] <info> app: PM security params requested
[00:00:11.000,000] <info> app: PM security params requested
[00:00:11.000,000] <info> app: phone security param request
[00:00:11.044,000] <info> app: ATT mtu_central=247 mtu_peripheral=247
[00:00:11.179,000] <info> app: ATT mtu_central=247 mtu_peripheral=247
[00:00:11.179,000] <info> app: phone Data len: tx_octets=251 rx_octets=27 tx_uS=2120 rx_uS=328
[00:00:11.560,000] <info> nrf_ble_lesc: Calling sd_ble_gap_lesc_dhkey_reply on conn_handle: 1
[00:00:11.719,000] <info> app: phone Conn intvl: min=6 max=6
[00:00:12.541,000] <info> app: phone Conn intvl: min=36 max=36
[00:00:13.070,000] <info> peer_manager_handler: Connection secured: role: Peripheral, conn_handle: 1, procedure: Bonding
[00:00:13.071,000] <info> app: PM secured connection
[00:00:13.074,000] <info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Bonding data, action: Update
[00:00:13.076,000] <info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Peer rank, action: Update
[00:00:13.080,000] <info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Local database, action: Update
[00:00:14.059,000] <info> app: Current Time Service not found on server.

Its interesting the "PM security params requested" comes twice but extremely close together in time. This message is produced when PM_EVT_CONN_SEC_PARAMS_REQ is sent.

RE: Android pairing pop-up appears twice

Anthony Ambuehl — Wed, 24 Mar 2021 15:43:14 GMT

I have been testing with android nRFConnect and the pairing pop-up does show up 2x.. the same as in our custom app.

Here is the log from android nRFConnect.

nRF Connect, 2021-03-24

Cala597f (ED:F7:F5:AE:59:7F)

I 08:29:28.677 [Server] Server started

V 08:29:28.682 Battery Service (0x180F)

- Battery Level [N R] (0x2A19)

Client Characteristic Configuration (0x2902)

Unknown Service (a8914000-b3de-1e8c-f647-5d1eafad4e89)

- Battery Level [N R] (0x2A19)

Client Characteristic Configuration (0x2902)

Device Information (0x180A)

- Manufacturer Name String [R] (0x2A29)

- Model Number String [R] (0x2A24)

- Serial Number String [R] (0x2A25)

- Hardware Revision String [R] (0x2A27)

- Firmware Revision String [R] (0x2A26)

- Software Revision String [R] (0x2A28)

Unknown Service (a8910000-b3de-1e8c-f647-5d1eafad4e89)

- Unknown Characteristic [R W] (a8910001-b3de-1e8c-f647-5d1eafad4e89)

- Unknown Characteristic [R W] (a8910002-b3de-1e8c-f647-5d1eafad4e89)

- Unknown Characteristic [N R W] (a8910002-b3de-1e8c-f647-5d1eafad4e89)

Client Characteristic Configuration (0x2902)

- Unknown Characteristic [R W] (a8910002-b3de-1e8c-f647-5d1eafad4e89)

- Battery Power State [N R W] (0x2A1A)

Client Characteristic Configuration (0x2902)

V 08:29:28.896 Connecting to ED:F7:F5:AE:59:7F...

D 08:29:28.896 gatt = device.connectGatt(autoConnect = false, TRANSPORT_LE, preferred PHY = LE 1M)

D 08:29:28.978 [Server callback] Connection state changed with status: 0 and new state: CONNECTED (2)

I 08:29:28.978 [Server] Device with address ED:F7:F5:AE:59:7F connected

I 08:29:28.978 [Server] MTU changed to 247

D 08:29:29.013 [Callback] Connection state changed with status: 0 and new state: CONNECTED (2)

I 08:29:29.013 Connected to ED:F7:F5:AE:59:7F

D 08:29:29.013 [Broadcast] Action received: android.bluetooth.device.action.ACL_CONNECTED

V 08:29:29.017 Discovering services...

D 08:29:29.017 gatt.discoverServices()

D 08:29:29.080 [Broadcast] Action received: android.bluetooth.device.action.BOND_STATE_CHANGED, bond state changed to: BOND_BONDING (11)

D 08:29:29.093 [Broadcast] Action received: android.bluetooth.device.action.PAIRING_REQUEST, pairing variant: PAIRING_VARIANT_CONSENT (3)

I 08:29:29.659 Connection parameters updated (interval: 7.5ms, latency: 0, timeout: 5000ms)

D 08:29:30.363 [Callback] Services discovered with status: 0

I 08:29:30.364 Services discovered

V 08:29:30.385 Generic Access (0x1800)

- Device Name [R W] (0x2A00)

- Appearance [R] (0x2A01)

- Peripheral Preferred Connection Parameters [R] (0x2A04)

- Central Address Resolution [R] (0x2AA6)

Generic Attribute (0x1801)

Secure DFU Service (0xFE59)

- DFU Packet [WNR] (8ec90002-f315-4f60-9fb8-838830daea50)

- DFU Control Point [N W] (8ec90001-f315-4f60-9fb8-838830daea50)

Client Characteristic Configuration (0x2902)

Battery Service (0x180F)

- Battery Level [N R] (0x2A19)

Client Characteristic Configuration (0x2902)

Unknown Service (a8911000-b3de-1e8c-f647-5d1eafad4e89)

- Unknown Characteristic [N R] (a8911001-b3de-1e8c-f647-5d1eafad4e89)

Client Characteristic Configuration (0x2902)

Unknown Service (a8912000-b3de-1e8c-f647-5d1eafad4e89)

- Unknown Characteristic [R] (a8912001-b3de-1e8c-f647-5d1eafad4e89)

- Unknown Characteristic [R] (a8912002-b3de-1e8c-f647-5d1eafad4e89)

- Unknown Characteristic [R] (a8912003-b3de-1e8c-f647-5d1eafad4e89)

- Unknown Characteristic [R] (a8912004-b3de-1e8c-f647-5d1eafad4e89)

- Unknown Characteristic [R] (a8912005-b3de-1e8c-f647-5d1eafad4e89)

- Unknown Characteristic [R] (a8912006-b3de-1e8c-f647-5d1eafad4e89)

Device Information (0x180A)

- Manufacturer Name String [R] (0x2A29)

- Model Number String [R] (0x2A24)

- Serial Number String [R] (0x2A25)

- Hardware Revision String [R] (0x2A27)

- Firmware Revision String [R] (0x2A26)

- Software Revision String [R] (0x2A28)

Unknown Service (a8910000-b3de-1e8c-f647-5d1eafad4e89)

- Unknown Characteristic [N R W] (a8910001-b3de-1e8c-f647-5d1eafad4e89)

Client Characteristic Configuration (0x2902)

- Unknown Characteristic [N R W] (a8910002-b3de-1e8c-f647-5d1eafad4e89)

Client Characteristic Configuration (0x2902)

- Unknown Characteristic [N R] (a8910004-b3de-1e8c-f647-5d1eafad4e89)

Client Characteristic Configuration (0x2902)

- Unknown Characteristic [N R] (a8910005-b3de-1e8c-f647-5d1eafad4e89)

Client Characteristic Configuration (0x2902)

- Unknown Characteristic [R W] (a8910006-b3de-1e8c-f647-5d1eafad4e89)

- Unknown Characteristic [R] (a8910003-b3de-1e8c-f647-5d1eafad4e89)

- Battery Power State [N R] (0x2A1A)

Client Characteristic Configuration (0x2902)

- Unknown Characteristic [N R W] (a8910007-b3de-1e8c-f647-5d1eafad4e89)

Client Characteristic Configuration (0x2902)

- Unknown Characteristic [N R W] (a8910008-b3de-1e8c-f647-5d1eafad4e89)

Client Characteristic Configuration (0x2902)

- Unknown Characteristic [N R W] (a8910009-b3de-1e8c-f647-5d1eafad4e89)

Client Characteristic Configuration (0x2902)

- Unknown Characteristic [N R W] (a891000a-b3de-1e8c-f647-5d1eafad4e89)

Client Characteristic Configuration (0x2902)

Unknown Service (a8913000-b3de-1e8c-f647-5d1eafad4e89)

- Unknown Characteristic [N R W] (a8913001-b3de-1e8c-f647-5d1eafad4e89)

Client Characteristic Configuration (0x2902)

- Unknown Characteristic [N] (a8913002-b3de-1e8c-f647-5d1eafad4e89)

Client Characteristic Configuration (0x2902)

- Unknown Characteristic [R] (a8913003-b3de-1e8c-f647-5d1eafad4e89)

- Unknown Characteristic [R W] (a8913004-b3de-1e8c-f647-5d1eafad4e89)

- Unknown Characteristic [N] (a8913005-b3de-1e8c-f647-5d1eafad4e89)

Client Characteristic Configuration (0x2902)

Unknown Service (a8914000-b3de-1e8c-f647-5d1eafad4e89)

- Unknown Characteristic [N] (a8914001-b3de-1e8c-f647-5d1eafad4e89)

Client Characteristic Configuration (0x2902)

I 08:29:30.463 Connection parameters updated (interval: 45.0ms, latency: 0, timeout: 5000ms)

D 08:29:32.504 [Broadcast] Action received: android.bluetooth.device.action.PAIRING_REQUEST, pairing variant: PAIRING_VARIANT_CONSENT (3)

D 08:29:35.257 [Broadcast] Action received: android.bluetooth.device.action.BOND_STATE_CHANGED, bond state changed to: BOND_BONDED (12)

I 08:29:35.257 Device bonded

It seems the bonding is being re-started when the connection parameters update.

RE: Android pairing pop-up appears twice

Simonr — Wed, 24 Mar 2021 13:41:37 GMT

First off, can we try to narrow this issue down to either the Android app or the nRF application? Do you see these two pop-ups if you use the nRFConnect app for Android or the default Bluetooth Settings on your Android phone? If not, this would point to the issue being on the Android side, but if you see it on the nRFConnect app as well, it should be due to something the nRF is doing.

Please also upload the log on the Android side when using the nRFConnect app so we can get some more details. I can't see anything wrong with the pm_handler_secure_on_connection log at least.

Best regards,

Simon

RE: Android pairing pop-up appears twice

Anthony Ambuehl — Tue, 23 Mar 2021 23:32:38 GMT

Here are logs while using pm_handler_secure_on_connection with a delay of 75 ms

[00:00:03.515,000] <info> app: phone connected. conn_handle: 0x1
[00:00:03.572,000] <info> app: ATT mtu_central=247 mtu_peripheral=247
[00:00:03.590,000] <info> app: PM security params requested
[00:00:03.752,000] <info> app: ATT mtu_central=247 mtu_peripheral=247
[00:00:03.752,000] <info> app: phone Data len: tx_octets=251 rx_octets=27 tx_uS=2120 rx_uS=328
[00:00:04.158,000] <info> app: phone Conn intvl: min=6 max=6
[00:00:04.964,000] <info> app: phone Conn intvl: min=36 max=36
[00:00:06.992,000] <info> app: PM security params requested
[00:00:06.993,000] <info> app: phone security param request
[00:00:07.284,000] <info> nrf_ble_lesc: Calling sd_ble_gap_lesc_dhkey_reply on conn_handle: 1
[00:00:09.423,000] <info> peer_manager_handler: Connection secured: role: Peripheral, conn_handle: 1, procedure: Bonding
[00:00:09.423,000] <info> app: PM secured connection
[00:00:09.426,000] <info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Bonding data, action: Update
[00:00:09.429,000] <info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Peer rank, action: Update
[00:00:09.432,000] <info> peer_manager_handler: Peer data updated in flash: peer_id: 0, data_id: Local database, action: Update