Hi Chen, On Wed, Jan 18, 2012 at 10:41 AM, Ganir, Chen <chen.ganir@xxxxxx> wrote: >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
