BLE Just Works on nrf52832 and NRF Connect

[Midhunjac]

Hi, I am working on something that requires me to use Just Works on nrf52832 custom board. Here is the work sccenario. under normal conditions, my module has a bonding PIN and the user is supposed to enter the PIN on his application to get data. My NRF module is a peripheral and i have enabled following in the prj.conf.

CONFIG_BT_NUS_SECURITY_ENABLED

CONFIG_BT_FIXED_PASSKEY

I have registered the necessary callbacks too.

What I now need to implement is a functionality which allows user to bond without a PIN temporarily after a button press. I assume BLE Just Works is what I need for this purpose. But I am open to any other suggestions or new perspectives to get this done.Thanks in advance.

[Hung Bui]

Hi Midhunjac, 

To be able to change the capability of the device to not have passkey (no display and keyboard) what you need to do is to 

bt_conn_auth_cb_register() with NULL input to remove the callback. Then you recall the bt_conn_auth_cb_register() without the display or confirm or entry callback. 

However we need to look at how you define your characteristics as well. Because in the characteristic definitions you also define the minimum level of security to access the characteristics. If you set it to requires MITM, having Just work bonding would not be enough to allow accessing the characteristics. 
If it's the case you may want to reinitalize the characteristic with new parameter. 

[Midhunjac]

I tried your suggestion but it didnt work. When I tried out what you suggested, the bonding failed. These are the logs.

<inf>: Connected 68:4A:E9:DC:F3:BC (public)
<wrn>: Security failed: 68:4A:E9:DC:F3:BC (public) level 1 err 4
<inf> migration1: Pairing failed conn: 68:4A:E9:DC:F3:BC (public), reason 4
<inf>: Disconnected: 68:4A:E9:DC:F3:BC (public) (reason 19)
<inf>:Disconnected 68:4A:E9:DC:F3:BC (public) :

I am sure it must be a mistake on my side. Can you please take a look at this ? Isn't this how you suggested that I do ? Just to make sure that we are not misunderstanding each other, I am using NCSv2.1.0 and for testing purposes, I have switched to the basic peripheral UART example. So the characteristics of that particular service applies now. What I am testing is if I can bond with the peripheral without a passkey. I am not trying to access any particular characteristic. I just want to bond with the peripheral straight away.

/*some code*/
err = bt_conn_auth_cb_register(NULL);
err = bt_conn_auth_cb_register(&conn_auth_callbacks);
/* some code */

static struct bt_conn_auth_cb conn_auth_callbacks = {
		.cancel = auth_cancel,

};

Tried adding the bt_conn_auth_cb_register() with the passkey display and passkey entry and passkey confirm callbacks set to NULL. That didnt work out too.

[Hung Bui]

Hi Midjunhac, 

I tried to compile with v2.1.0 and it doesn't change the result for me. 
It's strange that deleting setting would cause an issue for you. If you simply to make the button to delete setting /bond and don't change anything in the pairing configuration do you have the issue ? 
Have you tried to test with v2.2.0 ? 
You mentioned you tested on different devkit and got the same result ? 

If you test with my code without any modification do you have the same issue ?

Could you try the attached hex file ? 

0027.zephyr.hex

[Midhunjac]

Hello,

I had tried with v2.2.0 too and there were no changes to my observation. Using buttons do not always create a problem but I have observed problems when I switch back and forth for long times though. You see, ultimately what I want in this project is to control the switching with UART commands on a custom board.Hence, even in the devkit I try to use a similar feature (i.e UART controlled BLE mode switching.) As such, it is of little consequence to me beyond debugging purposes that whether this works fine with buttons. I hope you get the bigger picture. A new problem now is that the buttons in my DK are not working fine as it used to before.

Hung Bui said:

You mentioned you tested on different devkit and got the same result

Not different devkits, different devices. I tried it on another nrf52840 and got the same result.

Hung Bui said:

If you test with my code without any modification do you have the same issue ?

The last time I checked, it was working fine for a majority of cases except when there was a huge number of switching back and forth between modes. But as I told, that is not something I really want.

Hung Bui said:

Could you try the attached hex file ? 

I will let you know about the result.

Thank you.

[Midhunjac]

Hung Bui said:

Could you try the attached hex file ? 

I tried this but seems like my DK buttons have become completely useless. I do not even see the callback prints.There seems to be no effect too. Sorry about that. Is there some other way we can verify this ?

[Hung Bui]

Hi, 
I would assume in your application you will have a button or an UART command that switch the pairing feature. And this doesn't have to be switch back and forth in very short time ? 

Erasing a page in flash taking time, can be up to 90ms. I wouldn't suggest to queueing a lot of erase command in a short period of time. 

If the bond is already erased you don't need to erase the bond again to switch the pairing method. 

[Midhunjac]

hi,

I have a UARt command for the functionality and there will always be more than atleast a couple of seconds delay between the commands. The commands are not queued at all. I was wondering if my problem has anything to do with this older issue . What do you think about that ?

Is there anything else you suggest that might help me?

[Hung Bui]

Hi again, 

I think we need to clarify if the issue related to UART or not. If you test with my example do you see the problem ? 
How do you handle UART ? Do you use EasyDMA ? I don't think it has any problem with erasing setting. 
It's important to see where you call the bond erase command. If you are calling it inside an interrupt handler, I would suggest not to do so. 
You should put the erase in a work thread and start the work in the interrupt handle. So that the bond erase command is called in a thread level. This is similar to uart_work in the example. 

[Midhunjac]

I believe it is due to the UART as mentioned in the other thread. I am not using uARTE and so, I am trying with the work thread. It seems like there are no more crashes but now I have a couple of other problems. When I try to switch to Just Works, it is somewhere ' in the middle' kind of state. It still asks me for passkey but when I enter the passkey, pairing fails due to wrong passkey. So, i guess somehow the old passkey is removed but the method of pairing still exists. Cant seem to get any clue on that behaviour.
Also, the whole unpairing process is taking something like 10 minutes or so to even start.

Edit : I think the delay in unpairing described above is my mistake. From what I observe now, the issue seems to be resolved and I can switch between modes comfortably. Hence, closing the case.

Thank you so much for the support. This thread proved to be useful.