PASSKEY

[katyon]

 I’ve downloaded     nRF5_SDK_11.0.0_89a8197 and starting with examples from \examples\ble_peripheral\???\pca10040\s132\arm5_no_packs\

 I would like the other device to request a passkey (constant) at pairing (the passkey on my side is constant - no display needed)

After   gap_params_init();I’ve added the following code:

 

{

 static ble_opt_t optS;

   static uint8_t passw[]="123456";           

 optS.gap_opt.passkey.p_passkey=passw;

   err_code =sd_ble_opt_set(BLE_GAP_OPT_PASSKEY, &optS);

}

 

err_code returned :  0  

 

Still the module will pair and communicate without requesting a passkey.

I've tried to find an answer in Q&A . in some answers there was a reference to fields : io_caps,mitm. cant make out what does it mean. 

(these fields belong to structs relevant to services, not pairing)

 

Thanks for any help

   Yona

[Vidar Berg]

Hi Yona,

You can change the permission/security level on the BLE characteristics to require MITM pairing. The central does not need to pair with the device if security level is set to "open".

E..g, change BLE_GAP_CONN_SEC_MODE_SET_OPEN(&attr_md.read_perm) to BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM (&attr_md.read_perm) if you want to limit read access to a certain characteristic. 

 

[katyon]

thank you for the answer.

making this change - finally  "produces"  the  events:

BLE_GAP_EVT_SEC_PARAMS_REQUEST,   BLE_GAP_EVT_AUTH_STATUS

how should I deal with them ?

(as the cellphone application does not know that passkey is needed- so reading the characteristic results in a  BLE disconnection)

Yona

[Vidar Berg]

Hi, 

Do you get invalid param if your remove BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM(&cccd_md.read_perm);? You only need BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM(&cccd_md.write_perm); to require authentication for notifications. 

[katyon]

Hi

Do you get invalid param?    yes

if I dont     BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM(&cccd_md.read_perm)   everything works

meaning: read+write demand a passkey. notify dosnt.

for example: my characteristic   is read+notify.

upon power up + BLE connection/pairing... I will get notifys without any request for PASSKEY. 

then: when trying to read  for the 1st time (notify & read - return the same data)- I'm required to enter a passkey

(ONLY THEN)

thats why I tried to mess  with cccd_md.

Yona

[katyon]

maybe there is a work around this  (cant force NOTIFY to demand a passkey - if PASSKEY was not entered yet)

if I can see at some location - how the pairing+security are doing (MITM+PASSKEY+...)

then I can NOTIFY / output a READ only if pairing+security are cleared

Yona

[Vidar Berg]

Hi,

Notifications are enabled by writing to the 0x2 to the CCCD so it is the write operation that should require authentication. It's not possible  to require authentication for reading of the CCCD, and that is why the softdevice returns the invalid param error. Note that CCCD only contains the configuration value, not the characteristic value. Also worth noting that this configuration is persistent across connections when the devices are bonded.

The characteristic value permissions are set on attr_md.read_perm  and  attr_md.write_perm if you use ble_hrs.c::heart_rate_measurement_char_add()as reference. 

[katyon]

Hi again

eventually I found   the variable    m_connection_table[0].state

it contains the connection state- so if passkey not cleared - I can avoid notifys.

now if I may- a new issue:     sd_flash_write,sd_flash_page_erase

calling sd_flash_write returns (after 20uS)  0x00 (probably NRF_SUCCESS)

than (after 2870uS) at   sys_evt_dispatch i receive  sys_evt=2    ( probably NRF_EVT_FLASH_OPERATION_SUCCESS)

STILL nothing is written to flash.

maybe you have a clue to what I'm doing wrong.

using nRF5_SDK_11.0.0_89a8197  SW package.

thanks again

YONA

[Vidar Berg]

Hi,

It sounds like you're doing it correctly.  sys_evt=2 means  NRF_EVT_FLASH_OPERATION_SUCCESS, so it should have worked. Did you make sure to read out the flash content after the NRF_EVT_FLASH_OPERATION_SUCCESS event?  

[katyon]

sorry sorry sorry.

my mistake was somewhere else.

thanks again for your patience.

YONA

[Vidar Berg]

No worries, thanks for letting me know. 

Vidar

[katyon]

Hi again.

new issue:

the guys writing the application on the cell phone are bringing this up.

I might have 1-20 BLE devices in a given location. all of them would be seen by the cellphone application.

each of my BLE devices has a different TYPE (say up to 10 types ).

the TYPE of a given device might change (not very often)  .

the application "would like" to search all devices ,sort only my devices, show a list of them, each with an icon. the icon is the TYPE of the device.

my suggestion was to use appearance.

so every time my TYPE changed- I'll use sd_ble_gap_appearance_set to change it.

their complaint is that in order for them to know all TYPES, they need to READ the appearance characteristic for each of my devices, and that would take them too long.

their suggestion is to have a service that its uuid will be a function of the device's TYPE.

in that way- I'll will have one (an empty) service that its uuid will a function of the TYPE. 

in that way- all that's needed from them is to scan services , sort those that belong to me , and understand (from the uuid ) there TYPES.AVOIDING the need to actually preform  a READ into these services (characteristics).

the thing is- I don't see a function for service delete,characteristic delete, change of uuid.

How can I solve this? what would you do?

thanks

yona

[Vidar Berg]

Hi,

It's not possible to update Services and characteristics on the fly. You need to disable then enable the softdevice and re-initialize the new BLE services. However, you can update your advertisement payload using ble_advdata_set() regardless of what services/characteristics you have. Also, the appearance may be included in the advertisement packet: ble_advdata_t::include_appearance