Skip to contentSkip to conversation

Bluetooth: Add LE SecMgr and mgmtops support

RFC In review Brian Gix 1 participant 3 messages Nov 7, 2011 Bluetooth drivers

lore
Share & tools
lore

Brian Gix

author
#0 lore raw

cover Bluetooth: Add LE SecMgr and mgmtops support

I have talked to various members of this list about upstreaming the changes that we have made in the Code Aurora Forum, to support a more feature-complete MGMTOPS interface between BlueZ and the Kernel, and to support MITM protection for Low Energy SMP, using the same confirmation paths as Secure Simple Pairing (SMP).

I have spent much of the past week rebasing these changes onto the lastest revisions in bluetooth-next, and while this code has *not*
been extensively tested on this revision of the kernel (it has been vigerously tested on older Android base platforms) it can now at leat be cleaning applied to this kernel, and comments made.

I expect issues will be found, and I also expect to eventually submit this as at least two patches:

1. MGMTOPS additions/modifications
2. SMP rework

I have made an attempt to preserve all bug fixes from the past 5-6 months, but may inadvertantly have undid some fixes.

Signature · 4 lines
Brian Gix
[email protected]
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
author
#1 lore raw
Quoted 13 lines · Brian Gix

I have talked to various members of this list about upstreaming the changes that we have made in the Code Aurora Forum, to support a more feature-complete MGMTOPS interface between BlueZ and the Kernel, and to support MITM protection for Low Energy SMP, using the same confirmation paths as Secure Simple Pairing (SMP).

I have spent much of the past week rebasing these changes onto the lastest revisions in bluetooth-next, and while this code has *not* been extensively tested on this revision of the kernel (it has been vigerously tested on older Android base platforms) it can now at leat be cleaning applied to this kernel, and comments made.

Quoted 9 lines

I expect issues will be found, and I also expect to eventually submit this as at least two patches:

1. MGMTOPS additions/modifications
2. SMP rework

I have made an attempt to preserve all bug fixes from the past 5-6 months, but may inadvertantly have undid some fixes.

This patch was rebased off of:

commit 1e92e0b03905de28616d53c8b8c654defb16a096

Author: Szymon Janc <[email protected]>
Date:   Thu Nov 3 16:05:44 2011 +0100

Bluetooth: Add debug print to l2cap_chan_create

Signature · 4 lines
Brian Gix
[email protected]
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
author
#2 lore raw
In reply to Brian Gix
Quoted 13 lines · Brian Gix

I have talked to various members of this list about upstreaming the changes that we have made in the Code Aurora Forum, to support a more feature-complete MGMTOPS interface between BlueZ and the Kernel, and to support MITM protection for Low Energy SMP, using the same confirmation paths as Secure Simple Pairing (SMP).

I have spent much of the past week rebasing these changes onto the lastest revisions in bluetooth-next, and while this code has *not* been extensively tested on this revision of the kernel (it has been vigerously tested on older Android base platforms) it can now at leat be cleaning applied to this kernel, and comments made.

Quoted 9 lines

I expect issues will be found, and I also expect to eventually submit this as at least two patches:

1. MGMTOPS additions/modifications
2. SMP rework

I have made an attempt to preserve all bug fixes from the past 5-6 months, but may inadvertantly have undid some fixes.

I am also now going to commence rebasing the MGMTOPS changes that I made to Bluez. The changes are much less drastic, but of course important for the support of the kernel side. The existing MGMTOPS interface will work with the Kernel changes with fairly minor changes, that include usually a few extra parameters in the datagrams.

Most significantly, we thought that the LE Address type (Random vs Public) was important to store with the pairing information. I know that some here have been of the opinion that we can just do an LE scan each time we want to connect to an LE device, but as we make the move towards supporting LE Privacy, this piece of information (Random vs Public) really is just an extension of the BD Addr being used.

Signature · 4 lines
Brian Gix
[email protected]
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum