Release of obexd-0.2

Another version of the new obexd which fixes some issues and improves the FTP support. Please do intensive testing and report any issues.


Release of bluez-libs-3.35 and bluez-utils-3.35

The previous release contains a regression when using the service search or browse functions. Giving a friendly name like “opp” didn’t work anymore. Also the authorization framework was broken with disabled experimental support. Both issues should be fixed with this release.


This could be the final release of the BlueZ 3.x series. So please test it intensivly and report any problems via the mailing list or the IRC channel.

Release of obexd-0.1

The obexd is an attempt to unify all current OBEX based servers for Linux and create a small, but powerful daemon. Please help testing the first version.


Release of bluez-gnome-0.27

When switching to a plugin based infrastructure for the Bluetooth core daemon, parts of the service API became obsolete. This release now updates our GNOME applications to handle this change nicely.


The percentage of translation for this package is still pretty bad. Only a few languages have translated every string. If you have some free time and speak a foreign language, then please translate it.

Lennart’s wish list

During the BlueZ developer meeting in Helsinki a month ago we talked with Lennart Poettering about the native integration of A2DP and Headset support with PulseAudio. He requested some enhancements to our Bluetooth support in the Linux kernel for a better synchronization of the audio stream.

  • Support for TIOCOUTQ and TIOCINQ ioctls
  • Support for retrieving the remote clock value

The current GIT tree is based on the 2.6.26-rc8 kernel release and contains support for the first two items on his list.

Adding the possibility to retrieve the remote clock value has not been implemented yet. The technical part is not really complicated, but I am not sure on how to present this information to the user-space.

This patch set also contains an update to the Simple Pairing support and a fix for the driver model integration of the low-level connections.

Release of bluez-libs-3.34 and bluez-utils-3.34

The SDP client functionality of the Bluetooth library contains a potential security issue since the length checks of the incoming data are not always present. The following packages are fixing this by introducing safe versions for some function calls.


The credits for finding and fixing this issue go to Glenn Durfee from the Google Android team.

Simple Pairing patches available

The bluez-libs-3.33 and bluez-utils-3.33 release introduced the user-space support for Simple Pairing via the new D-Bus API. The missing piece to make this fully work where appropriate kernel patches. These are now available via a GIT tree.

This patch series is based on the 2.6.26-rc7 kernel release and also contains fixes for the HID disconnect detection and updates to the RFCOMM TTY handling.

It is important that these changes are intensively tested before we start submitting them for the 2.6.27 merge window. Everybody with Bluetooth 2.1 hardware, please start testing and give feedback via the BlueZ developer mailing list.

Preparing for 4.0

The 3.33 release was suppose to be the last one before hitting 4.0, but unfortunately it is not. We will have 3.34 and maybe 3.35 to stabilize the 3.x series before it can enter maintenance mode. This still means that 4.0 is only a glimpse away.

With 4.0 a lot of things will change. The first big one is that bluez-libs and bluez-utils will be merged back into one package called bluez like it was for the 1.x series. These two packages have been released in sync since the whole 3.x series and so it only makes sense to combine them. It is then up to the package maintainers to split the library part into a libbluetooth package and so on.

The old D-Bus API will be removed. We gonna have a whole new D-Bus API set that is smaller and more powerful. It is a big step and will improve the usage of Bluetooth for end user applications a lot. In the current 3.33 release, both APIs exists in parallel to give current developers an outlook what is coming. So start using the new API.

Our embedded GLib support will be removed. The 4.x series will have a hard dependency on the GLib base library. The reason for doing it is that mainting the embedded GLib part became to much of a burden and took a lot of resources.

All future development will be done in a GIT tree on and the CVS repositories at will be marked as read-only. We will keep them for reference and potential security updates for the 3.x series.

Stay tuned. More updates on this topic will follow…