Current status on BLE development

Current status on BLE development

[Claudio Takahasi]

Hi,

It is common to see questions in the ML or in the IRC asking the
status of BLE development and where the get the source code.
Below a short summary of our latest development on Bluetooth Low Energy:

* Discovery procedure over management interface (kernel): patches sent
to the mailing list, waiting maintainer approval

* SM(Security Manager): kernel & userspace
- Just Works key generation method is working and accepted upstream;
- Key Exchange and Storage: a first version of the implementation is
implemented and working, but before being accepted upstream it needs
some changes;
- Passkey Entry: Still not implemented;
- Out of Band: Still not implemented;
- Address Resolution: Planned but still not implemented;
- Command Signing: Still not implemented;

* LE connection improvements: under development

Proximity Monitor
=============
* Userspace
- New D-Bus API(improvement) was proposed and implemented, patches not
upstream[3]

* Kernel
- New RSSI Threshold Monitoring implemented. Required by Proximity
Path Loss. Under internal revision and will be sent to mailing list
after it.

git trees
===============
* For stable LE support on kernel, use Gustavo Padovan's
bluetooth-next tree:
git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-next-2.6.git
(it doesn't contain the patches for interleaved discovery using
management. Missing SM key distribution(SM phase 3).

* Unstable kernel with Interleaved Discovery, RSSI Threshold monitor,
remaining SM patches, changes in connection parameters based on
Proximity and Thermometer requirements:
http://git.infradead.org/users/vcgomes/linux-2.6.git (branch
proximity-integration)

* BlueZ Userspace
[3] git://git.infradead.org/users/cktakahasi/bluez.git proximity-devel

Regards,
Claudio

RE: Current status on BLE development

[Arun Kumar SINGH]

SGkgQ2xhdWRpbywNCg0KPkl0IGlzIGNvbW1vbiB0byBzZWUgcXVlc3Rpb25zIGluIHRoZSBNTCBv
ciBpbiB0aGUgSVJDIGFza2luZyB0aGUNCj5zdGF0dXMgb2YgQkxFIGRldmVsb3BtZW50IGFuZCB3
aGVyZSB0aGUgZ2V0IHRoZSBzb3VyY2UgY29kZS4NCj5CZWxvdyBhIHNob3J0IHN1bW1hcnkgb2Yg
b3VyIGxhdGVzdCBkZXZlbG9wbWVudCBvbiBCbHVldG9vdGggTG93IEVuZXJneToNCj4NCj4qIERp
c2NvdmVyeSBwcm9jZWR1cmUgb3ZlciBtYW5hZ2VtZW50IGludGVyZmFjZSAoa2VybmVsKTogcGF0
Y2hlcyBzZW50DQo+dG8gdGhlIG1haWxpbmcgbGlzdCwgd2FpdGluZyBtYWludGFpbmVyIGFwcHJv
dmFsDQo+DQo+KiBTTShTZWN1cml0eSBNYW5hZ2VyKToga2VybmVsICYgdXNlcnNwYWNlDQo+LSBK
dXN0IFdvcmtzIGtleSBnZW5lcmF0aW9uIG1ldGhvZCBpcyB3b3JraW5nIGFuZCBhY2NlcHRlZCB1
cHN0cmVhbTsNCj4tIEtleSBFeGNoYW5nZSBhbmQgU3RvcmFnZTogYSBmaXJzdCB2ZXJzaW9uIG9m
IHRoZSBpbXBsZW1lbnRhdGlvbiBpcw0KPmltcGxlbWVudGVkIGFuZCB3b3JraW5nLCBidXQgYmVm
b3JlIGJlaW5nIGFjY2VwdGVkIHVwc3RyZWFtIGl0IG5lZWRzDQo+c29tZSBjaGFuZ2VzOw0KPi0g
UGFzc2tleSBFbnRyeTogU3RpbGwgbm90IGltcGxlbWVudGVkOw0KPi0gT3V0IG9mIEJhbmQ6IFN0
aWxsIG5vdCBpbXBsZW1lbnRlZDsNCj4tIEFkZHJlc3MgUmVzb2x1dGlvbjogUGxhbm5lZCBidXQg
c3RpbGwgbm90IGltcGxlbWVudGVkOw0KPi0gQ29tbWFuZCBTaWduaW5nOiBTdGlsbCBub3QgaW1w
bGVtZW50ZWQ7DQo+DQo+KiBMRSBjb25uZWN0aW9uIGltcHJvdmVtZW50czogdW5kZXIgZGV2ZWxv
cG1lbnQNCjxzbmlwIC4uPg0KDQpUaGFua3MgZm9yIHRoZSBkZXRhaWxlZCBzdW1tYXJ5LiBIb3dl
dmVyIEkgd291bGQgYWxzbyBsaWtlIHRvIHVuZGVyc3RhbmQgdGhlIHN0YXR1cyBvZiBtZ210IGlu
dGVyZmFjZSBpbiB0ZXJtcyBvZiBpdHMgY29tcGxldGVuZXNzIGZvciBCUi9FRFIgYW5kIExFIHN1
cHBvcnQuIEkgY2FuIHNlZSBMRSBEaXNjb3ZlcnkgcmVsYXRlZCBwYXRjaGVzIGJlaW5nIHB1c2hl
ZCB1cHN0cmVhbSBmb3IgbWdtdCBpL2YgaG93ZXZlciB3aGF0IGludHJpZ3VlcyBtZSBpcyB3aGV0
aGVyIGl0cyB0b3RhbGx5IHVuYXZvaWRhYmxlIHRvIHVwZ3JhZGUgdG8gbWdtdCBpbnRlcmZhY2Ug
Zm9yIExFL3Byb2ZpbGVzPyANClNpbmNlIGZvciBTTVAga2V5IGV4Y2hhbmdlLCBoY2lvcHMgaXMg
aW5hZGVxdWF0ZSwgSSBhbSB0cnlpbmcgdG8gdW5kZXJzdGFuZCBhcyB0byBob3cgZmFyIGhjaW9w
cyBjYW4gYmUgcmVsaWVkIGluIHRlcm1zIG9mIExFIHByb2ZpbGVzIHdoaWNoIHdvdWxkIG5lZWQg
U01QIGtleSBkaXN0cmlidXRpb24gYW5kIHN0b3JhZ2U/DQogDQoNCg0KVGhhbmtzLA0KQXJ1bg0K

Re: Current status on BLE development

[Claudio Takahasi]

Hi Arun,

On Tue, Aug 2, 2011 at 8:49 AM, Arun Kumar SINGH
<arunkr.singh@stericsson.com> wrote:
> Hi Claudio,
>
>>It is common to see questions in the ML or in the IRC asking the
>>status of BLE development and where the get the source code.
>>Below a short summary of our latest development on Bluetooth Low Energy:
>>
>>* Discovery procedure over management interface (kernel): patches sent
>>to the mailing list, waiting maintainer approval
>>
>>* SM(Security Manager): kernel & userspace
>>- Just Works key generation method is working and accepted upstream;
>>- Key Exchange and Storage: a first version of the implementation is
>>implemented and working, but before being accepted upstream it needs
>>some changes;
>>- Passkey Entry: Still not implemented;
>>- Out of Band: Still not implemented;
>>- Address Resolution: Planned but still not implemented;
>>- Command Signing: Still not implemented;
>>
>>* LE connection improvements: under development
> <snip ..>
>
> Thanks for the detailed summary. However I would also like to understand the status of mgmt interface in terms of its completeness for BR/EDR and LE support. I can see LE Discovery related patches being pushed upstream for mgmt i/f however what intrigues me is whether its totally unavoidable to upgrade to mgmt interface for LE/profiles?
> Since for SMP key exchange, hciops is inadequate, I am trying to understand as to how far hciops can be relied in terms of LE profiles which would need SMP key distribution and storage?
>

If the LE profile requires SM/encryption it is necessary to use mgmt.
The RSSI threshold monitor is another feature missing for Proximity
Path Loss, it can be implemented in hciops but I am pretty sure that
the maintainers will complain about it.

Currently, it is not possible to open a socket for the SM L2CAP fixed
channel, change the code(moving all logic to the userspace) at this
point is not feasible. Interleaved discovery works on both interfaces,
bonding only using mgmt.

BR,
Claudio.

>
>
> Thanks,
> Arun

Re: Current status on BLE development

[Claudio Takahasi]

Hi,

Here is a new status update of the BLE development. Changes since the
first status report:
1. SM patches refactoring based on the comments of the maintainers in the ML
2. Use the LTK after receiving a LE Security Request: basically for
re-connections
3. initial LE scanning before connections(re-connections) if the entry
is not found in the cache (unstable)

Proximity Link Loss and Find are now working. Tested using real
hardware(key fobs).
Proximity Path Loss needs improvement, is there someone in the BlueZ
ML interested in helping us?
At the moment we are using hard-coded values for RSSI thresholds:
-60(low RSSI threshold) and -75(high RSSI threshold)
We need to improve the logic to define the SignalLevel(good, regular,
weak) properly based on the measured RSSI, Remote TX Power and other
parameter that could influence the results.


* Unstable kernel with Interleaved Discovery, RSSI Threshold monitor,
LE scanning and remaining SM patches
[1] http://git.infradead.org/users/vcgomes/linux-2.6.git (branch
proximity-integration)

* BlueZ Userspace
[2] git://git.infradead.org/users/cktakahasi/bluez.git proximity-devel

Regards,
Claudio