BLEGapSecStatus.confirm_value on passkey bonding.

RE: BLEGapSecStatus.confirm_value on passkey bonding.

Alex — Thu, 02 May 2019 17:34:47 GMT

Hello, I'd like to use ble_gap_auth_key_reply() to send a fixed passkey as well. Any luck with this?

RE: BLEGapSecStatus.confirm_value on passkey bonding.

Einar Thorsrud — Tue, 08 Jan 2019 12:58:18 GMT

Hi,

The passkey is forwarded to the SoftDevice by the connectivity firmware running on the nRF device (which receives it via UART from the pc-ble-driver). I was interested in checking the pass key at this point. It should be corrupted already here, since we know that the pc-ble-driver and connectivity firmware itself works (by using nRF Connect). You could verify by debugging or adding some logging in conn_mw_ble_gap_auth_key_reply() in the connectivity firmware? Perhaps seeing how the passkey is corrupted could give some hint.

RE: BLEGapSecStatus.confirm_value on passkey bonding.

mstratford_c — Fri, 04 Jan 2019 16:50:12 GMT

Hi, I'm just getting back to working on this again. Is there a way to see from the Nordic SDK (I'm using a nrf52 dev board running the glucose service peripheral example in SDK 15.2) to see what the other side is receiving pass-code wise? As far as I can see it's hidden within the softdevice itself. I can confirm that NRF Connect on PC with passcode bonding works fine. As far as I can see, ble_adapter.py does all this in the authenticate() function correctly. www.nordicsemi.com/.../group_ble_gap_central_bonding_pk_periph_oob_msc

RE: BLEGapSecStatus.confirm_value on passkey bonding.

Einar Thorsrud — Mon, 10 Dec 2018 07:08:45 GMT

Hi,

I was wondering if you could debug on the nRF side, which is based on the SDK connectivity firmware with some patched from the pc-ble-driver. How to patch it and build it is described here. I do not expect there to be any issues on that side though, as the connectivity firmware itself and pc-ble-driver support passkey entry and that works. This can easily be verified by simply using nRF Connect Bluetooth Low Energy, which uses pc-ble-driver (with the js wrapper) under the hood.

RE: BLEGapSecStatus.confirm_value on passkey bonding.

mstratford_c — Thu, 06 Dec 2018 13:24:24 GMT

Hi there, i'm not seeing an obvious instructions for building those into some firmware I can debug in Keil 5? Could you elaborate a little more please? Cheers!

RE: BLEGapSecStatus.confirm_value on passkey bonding.

Einar Thorsrud — Tue, 04 Dec 2018 13:53:14 GMT

I see. Can you debug on the nRF side, and see if all looks good in conn_mw_ble_gap_auth_key_reply() in conn_mw_ble_gap.c?

RE: BLEGapSecStatus.confirm_value on passkey bonding.

mstratford_c — Mon, 03 Dec 2018 14:36:28 GMT

Hi there, I've just checked this, it's giving me a 6 element array of 0x30-0x39, as required. I'd like to mention, this code did/does work perfectly with the old nrf51-ble-driver_win_0.5.0. Given I've tried this with multiple Bluetooth devices, of which work fine with passcodes on my phone, I think it's an issue with the Softdevice / DLL driver layer provided with the python pc-ble-central-py PIP/github package. Cheers.

RE: BLEGapSecStatus.confirm_value on passkey bonding.

Einar Thorsrud — Wed, 28 Nov 2018 14:38:49 GMT

Ah, yes. I missed that when I read the question. In that case it seems you are successfully providing six bytes, but for some reason they are corrupted. Can you do the conversion with util.list_to_uint8_array(key).cast() before the call to driver::sd_ble_gap_auth_key_reply(), just so you can verify that it is what you would expect? It should be a ASCII string with only 0-9, so each byte in the array should be between 0x30 and 0x39.

RE: BLEGapSecStatus.confirm_value on passkey bonding.

mstratford_c — Wed, 28 Nov 2018 14:15:17 GMT

The auth_status returns as BLEGapSecStatus.confirm_value according to the driver. All I can see is infocenter.nordicsemi.com/.../group___b_l_e___g_a_p___s_e_c___s_t_a_t_u_s.html

RE: BLEGapSecStatus.confirm_value on passkey bonding.

Einar Thorsrud — Wed, 28 Nov 2018 14:12:17 GMT

Hi,

This looks sensible, though I have not tested myself. What is the auth_status you get?