Return-Path: From: "Ganir, Chen" To: Anderson Lizardo CC: Vinicius Costa Gomes , "linux-bluetooth@vger.kernel.org" Subject: RE: [PATCH BlueZ 01/11] mgmt-api: Update the commands for exchanging LTK's Date: Wed, 18 Jan 2012 14:41:34 +0000 Message-ID: References: <1326842930-31623-1-git-send-email-vinicius.gomes@openbossa.org> In-Reply-To: Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Sender: linux-bluetooth-owner@vger.kernel.org List-ID: Lizardo, > -----Original Message----- > From: Anderson Lizardo [mailto:anderson.lizardo@openbossa.org] > Sent: Wednesday, January 18, 2012 12:41 PM > To: Ganir, Chen > Cc: Vinicius Costa Gomes; linux-bluetooth@vger.kernel.org > Subject: Re: [PATCH BlueZ 01/11] mgmt-api: Update the commands for > exchanging LTK's > > Hi Chen, > > On Wed, Jan 18, 2012 at 3:17 AM, Ganir, Chen wrote: > > Storing the address type in the LTK is not perfect. For this to work > properly, you will store the address type only for devices which > exchanged keys. What if we have devices which do not do pairing or > exchange keys at all ? What if we use the CreateDevice instead of > CreatePairedDevice? In that case we will not have the address type for > future reconnections. We need to store the device address type in a > separate file (for example, addresstypes) and manage it separately from > the LTK management. > > 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). > Best Regards, > -- > Anderson Lizardo > Instituto Nokia de Tecnologia - INdT > Manaus - Brazil Thanks, Chen Ganir