bluetooth: host: sample applications can't set BT address w/o using an FS

[mike-scott]

Previous to commit d22b7c9, sample applications could use the bt_storage API to set the BT address. That API was removed eliminating functionality that can be useful.

Here are some use-cases:

• Non-Nordic devices may not support a static internal private BT address
• Using customized logic to establish BT addresses allows CI testing / management to establish pre-defined values for whitelists / blacklists, etc
• As the BT address is directly translated into a portion of the IPv6 6lowpan address, we can customize the subnet used. Establishing subnetted networks during test (IE: custom 5th/6th octet values + 32 bit serial number value):
  BT Address can be hardcoded to D4:E7 + <32 bit serial # value>.

Example: Calculated 32-bit serial # b1830106 would translate to BT address: D4:E7:B1:83:01:06 which would translate to 6lowpan IPv6 address: fe80::d4e7:b1ff:fe83:106.

The 6lowpan gateway could use the fe80::d4e7/80 mask for networking instead of the typical fe80::/64 mask if desired.

[jhedberg]

One solution would be to introduce something like the following that needs to be called before bt_enable():

int bt_set_id_addr(const bt_addr_le_t *addr);

We can discuss whether it should be behind a new Kconfig (defaulting to n) or always available.

[mike-scott]

This would allow callers to change the value of bt_dev.id_addr?

[mike-scott]

I can't see any reason why it would need to be behind a new Kconfig, but I might be overlooking something. The old method was available to everyone by default.

[carlescufi]

If it's runtime then I don't see the point for such a small call to be behind Kconfig, no.

I assume no one likes to extend functions by doing something like bt_enable_ex(id_addr, cb) right?

[jhedberg]

This would allow callers to change the value of bt_dev.id_addr?

Correct.

I can't see any reason why it would need to be behind a new Kconfig, but I might be overlooking something. The old method was available to everyone by default.

Fair enough.

I assume no one likes to extend functions by doing something like bt_enable_ex(id_addr, cb) right?

I was thinking about that, and even about breaking the bt_enable() API by just adding a parameter. However, I'm slightly inclined to not giving this new feature too much publicity since it's for a quite small set of use-cases, and we don't want people misunderstanding or misusing the API (e.g. not understanding what it is and thinking they have to call it no matter what)

[carlescufi]

I was thinking about that, and even about breaking the bt_enable() API by just adding a parameter. However, I'm slightly inclined to not giving this new feature too much publicity since it's for a quite small set of use-cases, and we don't want people misunderstanding or misusing the API (e.g. not understanding what it is and thinking they have to call it no matter what

I agree. I think a bt_set_id_addr() is better but let's restrict it to being callable just before bt_enable() is invoked in my opinion.

[mike-scott]

I agree. I think a bt_set_id_addr() is better but let's restrict it to being callable just before bt_enable() is invoked in my opinion.

This restriction doesn't hurt our use-cases at all and mimics the old functionality. Would the call return an error if used after bt_enable()?