Release of bluez-4.4

And another brown paper bag release. Sorry about that, but I forgot to check the compilation of the CUPS backend. This release adds a temporary fix. It also adds the missing service API description.


Release of bluez-gnome-1.3

This release fixes a few bugs within the wizard and adapts to the changed discovery handling introduced with bluez-4.3.


Release of bluez-4.3

This release adds a plugin for handling external services and and it has now full support for discovery sessions to simplify the UI. It also adds the first steps into telephony driver abstraction.


Something to BITE

Yesterday the 29th of August 2008 was an historical day. BlueZ passed all Bluetooth 2.1 qualification tests for GAP. The bluez-4.2 release and an upcoming 2.6.27-mh1 kernel will pass all qualification tests form the Bluetooth 2.1 specification.

This is a testing that has been done with basically all PICS enabled. It would have been the full set of PICS, but two things have not been implemented by BlueZ right now:

  • L2CAP flow control and retransmission (deprecated by a Core Addendum)
  • RFCOMM support for sending RLS (receiving works)

Let me emphasize on this once more. Besides these two exception, BlueZ has passed all test cases required for a full Bluetooth 2.1 qualification. And this means full Simple Pairing support.

The qualification testing consisted of GAP, L2CAP, SDP, RFCOMM and SPP using the BITE test system. Everybody who has used the BITE before knows how much pain this system is and how broken it is. And every time they manage to break things while fixing others.

Just let me give you an example. So there is one test for checking a device in non-connectable mode (translates to page scan and inquiry scan off and hciconfig hci0 noscan for BlueZ) and with the latest test vectors it was impossible to pass this test. Even putting the device into a shielded box didn’t help. The test system still found it. Hey it even found our device after we took it out of the shielded box. This is one of the perfect example where the test system manfucturere didn’t validate their own system. Hey guys from AT4 wireless, you might wanna just run your test system against BlueZ.

The most famous failing test case is for testing park state support. For a host stack, it is impossible to fail this test since you can’t do anything wrong. You just simply can’t. Let me tell you that in the last 5 years we never passed that test case. So this time with a shielded box and the right star constellation, we finally did. Quite amazing and nobody of us really knows what we did different.

Did you ever tried to pass all (and I really mean all) SDP tests in one go. It is a nightmare and creating the right PIXIT settings for this takes quite some time. The main reason is that the SDP record editor that comes with the BITE is just plain braindead. I have the magic PIXIT values for doing a fully automated test run with BlueZ. However when re-importing them, the tester fails to import the ASCII string values. It just sets them to blank and you have to go into the CSV, read them and then put them in manually (again). Software validation at its glory. I did mention that this test system cost around 130.000 EUR and around 16.000 EUR in yearly fees!

So the bluez-4.2 release has been pushed out together with a bluez-gnome-1.2 to give you the nice Simple Pairing dialogs. The missing kernel patches will follow as soon as I have time to document them properly, but from 2.6.27-rc4 and later the major ones have been merged upstream already. If you are looking for Bluetooth 2.1 capable hardware, then the best bets are currently the EeePC 901 and the MacBooks. Go out and build Bluetooth 2.1 capable devices now.

And before I forget this, the qualification listing for this tests run has not been discussed yet. I will give an update when I know more details.

Release of bluez-gnome-1.2

This release now includes the Simple Pairing dialogs for numeric passkey entering and the numeric confirmation.


Together with bluez-4.2 this allows full usage of Simple Pairing if you find another device that’s support it. Currently it is only BlueZ to BlueZ.

Release of bluez-4.2

This release fixes a couple of bugs that were crashing bluetoothd and it also continues to clean up the code base. A lot of functions were removed and others made static.

However the biggest update is for the IO capabilities selection routine for Simple Pairing. It now fully complies to the Bluetooth 2.1 specification and allows to use the full potential of Simple Pairing.


Release of bluez-gnome-1.1

This release brings back most applications that have been omitted from the previous release.


The bluetooth-sendto application has been ported over to the new API and the bluetooth-wizard application is now installed by default.

The support for GNOME VFS based file browsing is currently not integrated. That might follow in one of the next releases.

Release of bluez-gnome-1.0

This is the first release supporting the BlueZ 4.x D-Bus API. The support for the old API has been removed. This brings a lot of internal changes with it and thus the major version number has been increased.


Despite the fact that this version is called 1.0 it has some drawbacks. The only two applications currently ported to the new API are bluetooth-applet and bluetooth-properties. So if you are looking for file transfer support, this is the wrong release for you.

This release can be used with hcid -x from bluez-utils-3.36 or with bluetoothd from the latest bluez-4.x release. When using hcid make sure to enable the experimental support via the -x switch, because otherwise only the 3.x API will be present.

The next step is to get all the dialogs for Simple Pairing support in place. This should include support for the bluetooth-wizard and after that we will port the missing applications to the new API.