Re: [PATCH] Bluetooth: Link Keys should be stored if MITM is not required

[Johan Hedberg <johan.hedberg@gmail.com>]

Hi Vishal,

On Tue, Apr 03, 2012, Vishal AGARWAL wrote:
> I am testing with PTS. I have attached the HCI dump also for this
> case.

First of all please stop top posting. It's not tolerated on this list.
Replying to an inline quoted mail makes it even doubly worse since it
completely messes up the history of the thread.

About the hcidump you attached we're getting the following from the
remote device:

 HCI Event: IO Capability Response (0x32) plen 9
    bdaddr 00:80:98:E7:32:4C capability 0x01 oob 0x00 auth 0x00
    Capability: DisplayYesNo (OOB data not present)
    Authentication: No Bonding (No MITM Protection)

I.e. the PTS is telling us to *not* store the key. Which test case is
this? To my understanding the PTS doesn't have BR/EDR GAP tests but you
need to use the BITE for them. Has something changed in that regard?

Looking at the full trace we're getting a link key request before
dropping the ACL. What we should probably do is to not immediately drop
the key from our list but instead keep it there as long as the
connection is up. I think that would still be in line with what the
specification expects us to do with no-bonding keys.

Now that I look at hciops it's more or less what's happening: it never
writes the key to the file system but does keep it in its list at
runtime.

So to conclude, the right fix is not what you've proposed but to modify
the code to hang on to the key until the ACL link goes down. I.e. please
add a "persistent" flag to struct link_key and add code to remove any
such keys from hdev->link_keys when the ACL goes away.

Johan