How do I implement "Just Works" pairing & verify it's functioning properly?

[AuFries]

I modified the BLE fundamentals lesson 5 exercise 2 example (github repo) for my purposes. This uses a generated passkey for pairing with accept lists.

I removed the passkey stuff and followed the bt_conn_auth_cb changes specified in this old post. 

static struct bt_conn_auth_cb conn_auth_callbacks = {
        .passkey_display = NULL,
        .passkey_confirm = NULL,
        .cancel = auth_cancel,
        .pairing_confirm = NULL,
};

Those were the only changes I made to the example code, although the SDK has changed a lot since then. I also have it configured for allowing 1 maximum connection at a time and 5 total paired. 

Whenever I pair once then disconnect and try to pair again with the same device or any other device, the firmware is unable to. On an android phone I get an error popup stating "incorrect PIN or passkey".

Are there any public examples which have just works with accept lists? How do I configure it for just works? The functionality I desire is the device pairing easily  (up to 5) and using this method for it's miniscule security.

[Kenneth]

Hello,

I think you are on the right track here already, the only other change I would suggest it how you setup the characteristics and services, for instance I can find that by default one is setup to require BT_GATT_PERM_WRITE_AUTHEN, this will not work if you only support just works, ref:
https://github.com/NordicDeveloperAcademy/bt-fund/blob/main/lesson5/blefund_less5_exer2_solution/src/lbs.c#L90 

Kenneth

[AuFries]

Hi Kenneth, i'm using a custom service which does not contain BT_GATT_PERM_WRITE_AUTHEN. The screenshotted issue and attempt to pair other devices is due to my ignorance of BLE. The other devices, of course, won't be able to connect due to the accept list unless I initiate open advertising. I've fixed this so it will open-advertise whenever I click a button until the maximum number of bonds are hit. In that case, it will then switch to accept list advertising.

However, I do have some other stuff I need help with. Since the peripheral is not aware of when the central deletes the bond, it cannot pair again as a new bond is treated distinctly and does not match the stored information on the peripheral. The `on_security_changed` and 'pairing_failed' callbacks are triggered when this occurs. 

I saw this ticket you answered a while back with the same question. Which of these configs am I supposed to use to resolve this? 

Also I'm wondering: would this issue occur if the central address was private (not static)? Is the address what's used for matching stored bond information in accept lists?

Also, is there a way to require pairing before accessing and attempting to write to characteristics? For example, some central can connect and never pair, which blocks other devices from pairing unless I increase the number of allowed simultaneous connections. Is this only capable with AUTHEN and higher level security?

Thanks

[AuFries]

These configs resolved it.

CONFIG_BT_ID_UNPAIR_MATCHING_BONDS=y
CONFIG_BT_SMP_ALLOW_UNAUTH_OVERWRITE=y