What I miss in the device manager

RE: What I miss in the device manager

Hung Bui — Fri, 23 Jan 2015 14:01:17 GMT

Hi Marcel,

8 IRK is the limit of the hardware block on the nRF51, please see section 4.6 in the Product Spec. So in total there are 8 public addresses and 8 IRK supported by the hardware (the current implementation in firmware may limit you to 8 total for both).

BLE_GAP_ADV_FP_FILTER_CONNREQ with an empty whitelist means no one can connect, therefore it as you said doesn't make sense. The first time when whitelist is empty , any one should be able to connect and pair. If you want to avoid being connected by unwanted device, you can use RSSI as a filter. Or the best is to use a Faraday cage (e.g microwave oven ) when pairing to avoid eavesdropping if you don't have OOB for pairing.

If you only want to advertise, and allow no-one to connect, you can advertise with BLE_GAP_ADV_TYPE_ADV_NONCONN_IND type.

Btw, if you have different question, please create a new case.

RE: What I miss in the device manager

Marcel Mulder — Wed, 21 Jan 2015 08:36:06 GMT

It works, but I now have a limitation of 8 devices using IRK. Maybe I have to change the device manager anyway. We will see. And there is another disadvantage. I am not able to start a BLE_GAP_ADV_FP_FILTER_CONNREQ advertisement with an empty whitelist. This is somehow logical but it means that when the device is first used anybody can pair. Unless I do no advertising at all and only advertise then when the button is pushed. Or is there something I overlook?

RE: What I miss in the device manager

Marcel Mulder — Tue, 20 Jan 2015 13:16:20 GMT

Ha, ok I see. Thats a nice solution. When I press the button I do BLE_GAP_ADV_FP_ANY advertisement for a period and otherwise I do a BLE_GAP_ADV_FP_FILTER_CONNREQ using the bond information and the whitelist. In this case there is no change to the device manager. At least I can't think of one. I will try this. Many thanks!

RE: What I miss in the device manager

Hung Bui — Tue, 20 Jan 2015 12:10:22 GMT

Actually whitelist can do the task.

We feed data to the whitelist from the bond information we store in device manager. It's true that we don't know the BT address up front, but we do know after bonding.

Even if the central device use random BT address and change it every 15 minutes (iOS devices), the IRK number will remain the same and we can use IRK to recognized a bonded device when doing whitelist. You can have a look at Resolvable Private Address in the Bluetooth spec (section 10.8 Vol 3 Part C Core spec 4.1).

What I ment with "bonding period" is advertising without whitelist, it's pretty much not related to device manager.

We tried to make the device manager as generic as possible, so it may not have all the features that you wanted. But I think it is quite straight forward to modify the code and add your needed features in.

RE: What I miss in the device manager

Marcel Mulder — Tue, 20 Jan 2015 11:30:59 GMT

What I mean with no support in device manager is that I cannot use the device manager out of the box. I can however change it. That's not the problem and I already did that. But it would be nice if people can use the SDK as-is without patches and having more control about who can pair and who not.

RE: What I miss in the device manager

Marcel Mulder — Tue, 20 Jan 2015 11:21:15 GMT

Whitelist is not an option I think because I don't know the BT addresses up front and they can change. Most phone use random BT addresses. Our product can have multiple bonds which can be initiated at any time.

I want to prevent unauthorized pairing. It should be initialized or confirmed by a person using the button. This means that pairing is conditional and I don't see support for that in the device manager.

You say that I can use the button to start a bonding mode period. Can I start that separate of the device manager? Some advertise option? I don't understand how you can do that.

RE: What I miss in the device manager

Hung Bui — Tue, 20 Jan 2015 10:05:00 GMT

Hi Marcel,

What I understand here is that you want to allow your neighbor's phone to connect to your device but don't want his phone to be able to pair with the device ?

If it is the case, you can simply catch the BLE_GAP_EVT_SEC_PARAMS_REQUEST and send the sd_ble_gap_sec_params_reply with and error (from BLE_GAP_SEC_STATUS) to avoid pairing. You can have a look here. This event handled automatically in device manager with a success reply for any master, but you can add your code here to wait for the confirmation from end user before sending the reply.

If it's not the case, and you don't want your neighbor to connect (and bond) to your device, then you can use white list to avoid unwanted connection.

To build the whitelist, you can set an option for the device to enter bonding mode (that accept all devices to connect and bond). You can also use RSSI (that only accepts connection from device let's say in the range of 3m) to avoid your neighbour to connect to your device when in this bonding mode. The bonding mode period can be started by holding the button when starting, or by sending a command with the app on the phone.

After you have done with bonding, you can use the address information for the whitelist and avoid unwanted connection.

[EDITED with correct information on case #1. ]