This is mostly a bug fix release rather than including many new features. The fixes fall in several different areas, including OPP, ATT and advertising (instance number handling in particular). There’s also a fix for handling a sudden disconnect when a connection setup process hasn’t yet completed. The one notable feature this release has is the ability to select between letting the stack handle ATT security elevation or doing the respective error handling in higher layers.
It’s been well over two months since the last BlueZ release, so we’re quite overdue for another one. BlueZ 5.31 contains fixes to many different areas, including networking, GATT, HID, A2DP and AVRCP. Feature-wise we’ve got support for security flags for the GATT database, allowing fine-grained security level control for D-Bus clients using the GATT D-Bus API. We’ve also got a new experimental device discovery filter interface which allows filtering for a specific remote service, RSSI threshold or transport (LE vs. BR/EDR). Another new experimental interface is for LE advertising, which also brings the LE peripheral role closer to feature completion on a D-Bus level.
On the Android side, all PTS documents have been updated to cover the latest PTS 6.1 version.
The highlight of this release is the completion of the GATT D-Bus APIs. We’ve now got both the client and server functionality in place, however it’s still behind the -E (–experimental) command line switch. The API is documented in doc/gatt-api.txt and there are several test tools for it in the tree (even bluetoothctl has support for it). Another new (and still experimental) D-Bus API that debuts with this release is one for managing LE Advertising, i.e. acting in peripheral role. The API is documented in doc/advertising-api.txt.
Besides the new features, there are several fixes to AVCTP, AVDTP & AVRCP. There’s also a fix for C++ compiler compatibility with the library headers as well as a fix for device information not being stored in certain corner cases.
On the Android side a notable addition is support for the Android 5.1 GATT MTU exchange API.
This is a comparatively large release with over a month and 475 commits since 5.28. There have been lots of fixes to the Android side, mainly to HFP & HSP, but also to GATT. The Android qualification documentation and results have also been updated for PTS version 6.0. Our internal GATT library (used both by ‘normal’ BlueZ as well as the Android version) received lots of updates for this release. The GATT client and server D-Bus APIs (which use the library) also reached completion, although they’re still behind the –experimental command line switch. The APIs are documented in doc/gatt-api.txt. Other notable changes are a fix for AVCTP key repeat timeout as well as added support for the Multi Profile Specification (MPS).
The Bluetooth 4.2 specification has been adopted in December 2014 by the Bluetooth SIG and now 3 month later, Apple is introducing support for LE Secure Connections with their update to iOS 8.2 software.
Support for LE Secure Connections provides Diffie-Hellman and Elliptic Curve Cryptography (ECDH) feature for creating Long Term Keys. These keys are P-256 strong keys and provide strong security that is now similar to BR/EDR Secure Connections introduced with Bluetooth 4.1 specification.
Using a Linux kernel 3.19 also enables LE Secure Connections feature and now BlueZ and iOS devices can utilize the strong security from Bluetooth 4.2 specification. The LE Secure Connections is a host stack only feature and can be used with Bluetooth 4.0 controllers. So every Bluetooth Low Energy capable system has the possibility of gaining LE Secure Connections support.
The BlueZ for Android project also enables Bluetooth 4.1 and 4.2 features for Android KitKat and Lollipop versions. This includes support for BR/EDR and LE Secure Connections.
Here’s the first BlueZ release in 2015. Most of the changes since the last one are bug fixes, but there’s actually quite many of them this time, including:
- Fixes to GATT service discovery & probing
- Fix for bearer selection with dual-mode devices
- Fix potential crash when removing devices
- Fix issue with incomplete names in EIR data
- Fix parsing GATT name characteristics
- Fix AVCTP long press & key repetition handling
- Fixes for GATT notification handling
Besides bug fixes we’ve now also got more extensive unit tests for new GATT code as well as better HCI decoders in btmon for some less used 4.1 and 4.2 features. The hid2hci tool gained support for CSR 8510 A10 devices and the hex2hcd tool (for Broadcom firmware) received a complete rewrite with better command handling.
Here comes the traditional x-mas release! BlueZ 5.27 consists mostly of bug fixes to areas such as GATT and mgmt (the interface through which bluetoothd talks to the kernel). The emulation framework has also received many new features, paving the way for more extensive test automation. On the Android side we’ve continued perfecting 5.0 (Lollipop) support, a notable addition being support for needed SELinux policies.
The Bluetooth Core Specification 4.2 was released December 2nd and it brings with itself several new features for Bluetooth Low Energy. Perhaps the most interesting one (and also the biggest) of these has been merged to the Bluetooth subsystem and submitted for inclusion in the 3.19 kernel release. The feature is called Low Energy Secure Connections (LE SC).
Bluetooth LE pairing has had known security vulnerabilities ever since its introduction to the Bluetooth specification. LE SC upgrades the Security Manager Protocol (SMP, used for LE pairing) to take advantage of the same Elliptic curve Diffie–Hellman (ECDH) key agreement protocol that classic BR/EDR Bluetooth uses. This essentially brings LE pairing to the same level of security as BR/EDR pairing.
Another improvement that LE SC brings is what’s called cross-transport key derivation. What this means is that when two dual-mode (supporting LE + BR/EDR) devices pair with each other, they only need to pair over either LE or BR/EDR to get the encryption keys for both transports in one go. When pairing over LE, as a last step of the SMP pairing procedure the BR/EDR Link Key (LK) gets derived from the LE Long Term Key (LTK) by both devices. For BR/EDR on the other hand, a subset of SMP can now be run over a fixed L2CAP channel resulting in deriving an LTK from the LK at the end of the BR/EDR pairing procedure.
Hardware & Software Requirements
BlueZ 5.26 is the first user space version that supports LE SC and will automatically take advantage of it for kernels also indicating support for it (i.e. >= 3.19 in practice). Most LE SC features are available for any Bluetooth adapter capable of LE (i.e. supporting Bluetooth 4.0 or later), however cross-transport key derivation in the BR/EDR -> LE direction requires that the BR/EDR link is encrypted with AES (compared to E0 for Bluetooth 4.0 and before), i.e. supports BR/EDR Secure Connections. Since BR/EDR SC was introduced with Bluetooth 4.1 this means that full LE SC is only available when the local and remote Bluetooth HW support at least Bluetooth 4.1.