Hello,
I have a question regarding pairing in the SDK.
The software on our board is waiting for pairing requests.
A smartphone app connects to the board and starts the pairing request.
The IO capabilities of the Dialog board are configured as "display only".
So currently the phone can do a pairing request using the PIN code displayed by the board, and it works correctly.
But the problem is that the phone can also do a pairing request without PIN code and it works too.
Is it possible to accept only pairing requests with PIN code and deny the others?
Thanks,
Andy
Device:
Hi apoudret,
What do you mean that the phone is able to connect without the pin ? If for example the device asks you for a pin and you just ignore it from the phone side the device still remains connected until you issue a disconnection ? Or the device will just disconnect after a few seconds ? The device will accept the connection and if the implemenation requires security then the security request will happen while connected, if the security requirements of the link doesn't match the device's requirements it will just disconnect, you can take as an example the bms project of the SDK, as is it will require a pass key, if the device doesn't receive a pairing response within 30 seconds it will just disconnect.
Thanks MT_dialog
Hello,
The characteristic in my BLE service was created using permission ATT_PERM_WRITE_ENCRYPT instead of ATT_PERM_WRITE_AUTH. Because of this some devices could pair without entering a PIN code ("just works" pairing).
However I have an other issue. Sometimes I want the user to be able to write this characteristic without being paired, and sometimes I want him to be able to do this only if he is paired.
I tried to use the function ble_gatts_set_characteristic_prop to change the permission of the characteristic (switching between ATT_PERM_WRITE and ATT_PERM_WRITE_AUTH). However when I do this my characteristic becomes invalid. If I check with nRF Connect for example, I can see that the characteristic UUID changed. Because of this the smartphone can not find the characteristic anymore (since it looks up for it using it's UUID).
Is there something I should know when using ble_gatts_set_characteristic_prop? The initial UUID is a 128 bit UUID and after this function call it becomes a 16 bit UUID.
I was looking for a workaround to this issue: is it possible to destroy my service and create it again?
Hi apoudret,
Seems that there is something wrong with the functions ble_gatts_set_characteristic_prop() and ble_gatts_get_characteristic_prop() (on the 1.0.12 SDK), i am checking with the SDK team on this, i will let you know as soon as i ve got more info on this. As far as i am aware there is no valid API that would allow you to easily destroy and recreate the database this time using the required permissions during runtime, i am also checking this with the team.
Thanks MT_dialog
Thank you for your answer, it would be very nice if you could get back to me when you have more information on this issue (or a workaround).
Hi apoudret,
I 've issued an internal ticket on that, i will reply as soon as i have an answer from the SDK team.
Thanks MT_dialog
Hello,
Do you have any update on this issue?
Thanks
Hi apoudret,
No, still no news from the SDK team, this might take a while.
Thanks MT_dialog
Hi apoudret,
Just had some feedback on that please make following changes in the below functions:
In the above functions you will find the following line of code:
gcmd->handle = cmd->handle + 1;please replace that line with thisgcmd->handle = cmd->handle;apparently the function was requesting and setting the wrong handle, this should fix the issue.
Thanks MT_dialog
Hello MT_dialog,
In this case when I call the ble_gatts_set_characteristic_prop() function, should I give the characteristic handle or the attribute value handle?
I did your change on the SDK but my problem remains.
- If I give the characteristic handle, nothing happens the permissions are not changed
- If I give the attribute value handle, the permissions are changed but the characteristic UUID is also changed (it becomes a 16bit UUID)
Thanks
Hi apoudret,
I have not tested this on the central side only through the debugger on the DK just to check that the permissions are changed, tested on a central device i can reproduce your issue and see what you are mentioning, that the change affects the UUID of the characteristic, still checking on a solution for that. The handle that you should pass to the function is the attribute of the value.
Thanks MT_Dialog
Hello MT_dialog,
Thanks for your answer.
I'd be glad if you could get back to me when you have a solution regarding the UUID issue.
Thanks
Hi apoudret,
Still no news from the SDK team on this for a proper fix, but i trust that we have found a work around in order to be able to change the permissions and properties of a characteristic without messing with the UUID, instead of using the ble_gatts_set_characteristic_prop() function please check the 3 lines of code below for changing permissions and properties of a characteristic.
att_perm_type test_perm;
struct attm_elmt elmt;
test_perm = prop_to_rwperm (GATT_PROP_READ| GATT_PROP_WRITE | GATT_PROP_NOTIFY) | perm_to_rwperm(ATT_PERM_READ_AUTH|ATT_PERM_WRITE)|
(PERM_UUID_128 << PERM_POS_UUID_LEN) ; //This will set the proper properties and permssions that will later be assigned to the attribute.
status = attmdb_get_attribute(mcs_glob->mc_var_value_h, &elmt); //Get the attribute
elmt.info.att->perm = test_perm; //Set a new set of permissions to the targeted attribute.
I hope this will help.
Thanks MT_dialog
Thanks MT_dialog, your workaround works like a charm.
Do you know if the same thing can be done on descriptors?
Hi apoudret,
Almost, i have this working on my side for the descriptors:
test_perm = perm_to_rwperm(ATT_PERM_READ_AUTH);
status = attmdb_get_attribute(mcs_glob->mc_descriptor, &elmt);
elmt.info.att->perm = test_perm;
Thanks MT_dialog
Thank you MT_dialog this is working perfectly.