I'm trying to connect a the above headset to a Slackware 12.2 box for use with mainly with Ekiga and Skype. Here is the info:

Slackware 12.2

I have also tried uninstalling the above series of Bluez software and compiling and installing the 4.32 (latest). Still no joy.

As far as I understand, the setup can be split in to distinct parts – the paring process, and the audio setup (with alsa or pulseaudio). I am stuck at the first part. I have bluetooth system started. I place the device in pairing mode. I run:

As can be seen from above – hcitool does detect the headset – but when I ask to connect to it – it doesn't ask for a pin – it doesn't say anything. I've also tried “hcitool auth” just in case – although if my understanding is correct – this command is used to ask for a pin from the device – like a mobile phone – where the pin is entered manually.

I've also tried using the pin helper option in /etc/bluetooth/hcid.conf – no joy. I've looked through /var/log/messages and /var/log/syslog – but there doesn't seem to be anything relevant there. I also can't find how to turn some sort of debugging on for hcitool to get it to output more detail.

I've also tried the 4.x series of bluez – with the same results.

Just to eliminate the possibility – I've managed to pair the headset successfully (and use) with a Nokia mobile phone. But I've switched the phone's bluetooth off during the tests/attempts to connect to laptop. I have also used the manufacturer's instructions to reset the handset's memory (plug in the charger, and unplug after 5-10 seconds). I've also managed to pair the headset, using the same bluetooth usb dongle using a Ubuntu 8.10 live cd. Unfortunately, it uses the gnome applet – so no matter how much I grep'ed around for the MAC address of the headset to try and figure how does the gnome applet do things – or what commands it uses under the hood – I just couldn't get anywhere.

I use Slackware on my main machine – and really like it (apologies to those who disagree :-) ) - so I need to figure out how to get things done with the command line. I am happy to stay with the 3.x series of bluez, or move again to 4.x – if anyone can enlighten me what is going on with hcitool. Incidently – on Ubuntu, the 'hcitool con' reports no connections either – even when I am paired – so I can't figure out how it works. Maybe it uses some other command line tools to pair 'under the hood'.

I've googled around for ages – and there are quite a few guides. But they just don't work for me. Everybody says that you are supposed to be prompted for a pin when attempting to connect with hcitool. I am not.

Anybody who understands what is going on – please chip in with some help. Am I missing anything here? Do I need to install some extra software/modules/libraries? Can I at least find some error messages somewhere?

Thanks

Answering my question here :-) In short, I have managed to get the headset working with the command line only. I'm going to describe below what it involves – maybe it saves somebody else 4 days of pleasure and despair (not necessarily in that order). The information below represents what I've managed to accumulate in the last few days. The 4.x series of bluez software seems to almost lack any formal documentation (at the moment) – so my understanding of various aspects could very well be inaccurate in places. Please don't hesitate to correct me. These instructions are specific to Slackware 12.2 – but you should be able to apply them with suitable modifications to your distribution.

First some background info. The 4.x series of bluez seems to be a significant redesign over 3.x series. The config files are pretty much different, apparently no more 'hcid' and 'hdid' daemons – and the pairing/pin helper agent is, well, almost gone. The only way to pair a device at the moment seems to be the Gnome Bluetooth applet/wizard, or the python scripts included in the bluez sources, under the 'test' folder. There is also the option to use dbus commands – but I just couldn't get that to work. So, technically, there is no command line for pairing at the moment per se. However, sieving through the bluez developers mailing list – there seems to be some intention to develop one at some point in time.

What I used:
a. Slackware 12.2
b. Original 2.6.27.7-smp kernel
c. Bluez 4.32 (latest at the moment)
d. Cambridge Silicon Radio Ltd Bluetooth Dongle
e. Jabra BT2010 bluetooth headset

As usual - please make sure you understand enough of what is going on and what you are doing - and that you take sufficient precautions against any type of data loss. Not only I can't be held responsible for any consequences as a result of you following these suggestions - but I would hate to think you ended up with even less of a functional machine by the end :-)

Now, step by step instructions:

1. Remove whatever version you have of everything bluez (unless you already have the one you want to try). I had bluez-libs, bluez-firmware, bluez-hcidump and bluez-tools. I used pkgtool (or removepkg command) – but you can use whatever means your distribution provides for removing software.

2. Remove /etc/bluetooth and /var/lib/bluetooth directories entirely. This is where bluez settings and pairing information is stored – we don't want them mixed up with newer versions.

3. On Slackware, I've also removed the /etc/rc.d/rc.bluetooth script as it is incompatible with the newer 4.x series. On your distribution you will have to find out where the init scripts are for bluetooth and how to remove/disable them.

4. Download bluez and bluez-firmware from http://www.bluez.org/download/
(bluez-gnome didn't work for me and bluez-hcidump seems to be mostly used for debugging). I placed them under /usr/src – so my commands will use that path – you will have to adjust things depending on where you download them. I've also used what seems to be the Slackware traditional file locations for the configure command – again – this is up to you.

5. Unpack the sources, configure, compile and install them.

… and for the firmware:

6. I've copied the init script provided under 'scripts' folder, and it seems to work fine for Slackware – but see your distribution procedures:

7. Now for the connection and pairing process. You might want to restart the machine and make sure the bluetoothd daemon works fine.

should hopefully show the daemon running. I won't go into details on how to check the your bluetooth dongle or integrated bluetooth chipset is working fine – and which chipsets are supported and which are not.

Run hciconfig' command to check everything is ok with your bluetooth adapter, that it is recognised – and what is it's device name (I have zero'ed the mac address of my adapter – but yours should show a real address):

Place your headset in pairing mode (check manufacturers instructions). Run hcitool to discover it (again, you should see a real MAC address where the zeros are):

If hcitool refuses to scan – make sure your bluetooth adapter is up (assuming your device has been assigned hci0 – as most seem to) and then try the scan again:

8. I am a bit unclear if the command 'hcitool cc' is needed anymore – but it didn't seem to break anything either. We are going to use the python script in the sources directory to connect to the headset. This seems to be a one-off process – as once the pin has been passed to the headset – the authentication seemed to survive across reboots. Use mac address discovered with 'hcitool scan' earlier on, instead of zeros:

The last command should prompt for a pin (again, the pin for your headset is either in the documentation of the headset, or it might be generated automatically everytime if you have a fancy headset with a display). Enter the pin (0000 in my case). All going well – your computer is paired with your headset.

9. I have placed the following in my /etc/asound.conf. This will affect global settings for all users. You can place them instead in ~/.asoundrc file, and it will affect only the user in question. There seem to be a variety of settings that can go in this file, for voice only headsets (simple, mobile phone type), or A2DP stereo headsets. Also, if you use pulse-audio or some other audio setup – you might have to do some more digging. See links at the bottom. This works fine for my Slackware 12.2 box – which apparently just uses Alsa. I didn't use the mac address of the headset – as it seems to pick it up by default if you only have one. If you have problems – use the mac address as in the examples on the bluez wiki.

10. Restart the computer (or just alsa) and you should be able to test things. I have tested mine like this (note that 'headset' is what I used in the asound.conf file above. If you used something else, adjust accordingly):

For playback:

To see if the headset mic works:

If the mic works – you should hear your own voice in the headset speaker.

Oh – actually, in a way – this is just the start – as support for using headsets seems to vary depending on whatever app you are using. Some info I found useful can be found here:

http://wiki.bluez.org/wiki/HOWTO/AudioDevices

For example – I am still not clear if I can get Ekiga working with the headset at the moment.

But at least I have managed to get the headset paired and working with Slackware 12.2 using command line only. Yey!!!!

I've been trying to get my Motorola H560 working on my Slack machines for a day now. I could pair, but never any audio. Upgrading to Bluez-4 did the trick. You lose kbluetooth functionality (and I'm sure other apps that don't support the new API), but at least you can pair on the command line and get about your business.

Tested with Skype, seems to work.

I left the Slack-12.2 bluez-firmware package in place, because it doesn't appear to have changed (hcidump either). Just replaced bluez-libs and bluez-utils with bluez-4.32.

Thanks again. I needed this to _just work_ for a business trip I'm starting tomorrow.

Just an update. Now trying to actually get the headset to do something useful. Well, so far couldn't get it to work with anything (except, as mentioned above, to play music through it and test the mic - but being one of those mobile phone headsets - playing music through it is not exactly an advantage). Ekiga doesn't support alsa virtual devices, so no joy there. Linphone looked quite hopeful, and using the instructions from here: http://www.mail-archive.com/linphone.../msg01685.html I managed to get the headset to show in the linphone audio settings - but selecting it I get the same results as the poster. No sound, just the beeps, long delay to initialise the headset, and linphone pretty much freezes. With Skype sort of similar situation - I get to select it from the settings easily - but it just doesn't want to work. It worked briefly in the beginning (I could hear the startup sound) - but not anymore. Which is strange, as I haven't changed anything in between. When I restart skype it now crashes and restarts the X server (it stopped doing this as soon as I reverted to normal audio devices in the settings). I have even tried using the modified asound.conf file suggested in the bluez wiki, using the slave/plug type device to allow for resampling on-the-fly - but no joy in either applications.

If anybody has any suggestions - please jump in. I can't seem to find any more relevant stuff in google - actually I'm not even sure that it is possible to make these applications work yet with the newer style bluetooth audio support introduced by bluez 4.x (at least there are people who claim success with Skype - but I don't understand what is happening there).

Replying to my own questions again :-)

The Skype crashes were partially related to some filesystem corruption. After running a check - it stopped crashing - but still no audio on the headset - just beeps. After some more googling, I've removed completely the 'profile="voice"' line from the 'asound.conf' file (or .asoundrc - if that's what you are using) - and it started working. Somehow, either 'voice' or 'auto' didn't seem to work. But no profile setting at all works. One more thing with Skype - if I set the ring device and the other two on the headset - it seems to get the headset stuck - probably can't really send overlapping streams e.g. - the end of the ring might overlap with Skype trying to open the headset for voice. But as soon as I've set the ring device on the normal speaker, and leave the other two on the headset - it worked. Which is really not a problem - as I actually wanted to use the speaker for ringing.

Onto sip/voip clients - couldn't get Linphone to work - but did manage to get Twinkle to work with the headset. I am actually quite impressed with Twinkle - I've been avoiding it for the past few months - while I've been messing with all sorts of versions of linphone and Ekiga - trying to get them to work with this library and the other - and with asterisk, and over OpenVPN etc. Twinkle seems to have an impressive amount of granularity in it's settings - and it actually allows typing the Alsa device if it is not in the list. It worked straight away.

So after all - it wasn't all for nothing. I've got Skype and a sip client to work with the headset. Hope all this might help somebody. :-)

I did use my headset with Skype over my business trip (with bluez-4.32). It was a bit hit-and-miss as to whether it would pair sometimes (and whether it was truly paired and operational). I'm not sure how the key is cached, but sometimes I had to request a disconnect using "simple-agent" because it claimed it was already paired but the headset itself didn't agree. A method that was pretty reliable was that I compiled the "d-feet" dbus debugger and manually went in with the tool and executed the "Connect()" method on the headset. Afterward, it was very likely starting Skype was successful. Once in a while, it wasn't successful until I invoked "simple-agent" again.

I am using profile "voice" in my alsa config, but may not have tested any other profile.

Hopefully bluez-4 will be adopted quickly and be in Slack soon.