Re: [PATCH BlueZ 01/11] mgmt-api: Update the commands for exchanging LTK's

Hi Chen,

On Wed, Jan 18, 2012 at 10:41 AM, Ganir, Chen [off-list ref] wrote:

quoted

Note that BlueZ is still relying on the kernel LE advertising cache
(which is refreshed with either the automatic scanning prior to
connection, or with the future background scanning support) for
detecting address type for non-bonded devices. We have no plans to
change that in near feature, because IIRC it would require changing
bluetooth socket API (which would break all current BR/EDR
applications).

This is an issue separate from LTK storage, if you are interested on
pursuing this, feel free to make a proposal.

I have a working implementation now that is able to create a connection for bonded devices (currently just bonded devices, but in the future, any created device node) without relying on the scan cache. I simply store the device address, and use it when connecting to that device. I see no reason or possibility for a device to change its address type during its life time (correct me if I'm wrong, and please describe a use case for that).

How do you know which address type to use for LE Create Connection
(Own_Address_Type in page 1073) on the kernel side? AFAIK, there is no
way to differentiate a public address from random just by looking at
the address (the public address has no "reserved" bits). You need the
address type as found on the advertising reports.

What do you mean by "store"? for how long it is stored, specially for
non-bonded devices? Is it on kernel or userspace?

Regards,
-- 
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil