Attempting to pair with a bluetooth device

>a=01:23:45:67 ; hcitool cc $a # would not connect

but

>rfcomm bind $a
>rfcomm connect hci0 $a
>rfcomm release /dev/rfcomm0
>rfcomm connect hci0 $a

worked perfectly

The same usb bluetooth dongle , with the same bluetooth/bluez version (4.3),
compiled kernel (2.6.30.1) and phone worked perfectly with hci-tools on another pc. I tried copying all config files (including /var/lib/bluetooth) from the working pc to no avail.

This behaviour with the same hcidump output is described exactly on another unanswered post,
http://forums.fedoraforum.org/archiv.../t-193320.html.

Has anyone an idea what might cause such behaviour.

I'm not sure where the problem is then. If you can connect and pair with RFCOMM, then what do you need to use "hcitool cc" for? Which services are you using that you can't connect directly with?

All the services work using the link set up with rfcomm.

It seems untidy to need to to explicitly connect using rfcomm as root rather than use the normal automatic mechapinnism with bluetoothd.

It took a lot of experimenting and searching to get the connection to work. Issues like this make it hard to get a system going "out of the box", so if the bug can be documented, or better, fixed, it would
make it easier for the next user.

If no-one has already found or knows an answer to this, I'll eventually spend a bit more time, and try to pinpoint the problem.
If I can determine why hci does not work I'll put in a bug report.

BlueZ will establish the connection when you actually use a service, you shouldn't need to pre-connect with "cc". So for example when you try to push a file to the phone with obexftp, it would connect as soon as you run the command and then disconnect once it has been transferred. You don't need to setup a link before running a service.

It isn't a bug, that is how it is setup to work. Bluetooth devices don't remain constantly linked like WiFi or other protocols, as it would drain the battery too fast on mobile devices.

So if you are able to connect with RFCOMM, then obviously the pairing process has succeeded. All you should have to do is run whatever service you want to use and it will automatically connect. If not, what error do the individual services report?

Thanks for your help.

I cannot explain the reason that "hcitool cc" would not, and still won't, connect (or more,connects, and then disconnects deliberately shortly afterwards).

The reason bluetoothd/hcid would not automatically connect was because of the stored data in the Nokia 2760 handdset. I was using the same dongle and passcode as on the first pc, but the hostname (used as part of the ID) was, of course , different. Hence the reason for the different behaviour on the two PC's. When I deleted the ID of the first PC , it was possible to recognize the new host and then set up to pair automatically.

Thanks very much for you help. Once I understood how the connection process worked a bit better I was able to track down the problem. I am now able to use connection automatically again on the new pc.

I found the upgrade to bluetooth 4.3 somewhat disconcerting, since the names and configuration have been changed, and the manual pages are not yet up to date.

To be perfectly honest, I have never gotten "hcitool cc" to work with any of my hardware on any computer. I am not sure what it's function is, as it always either returns nothing or spits back a vague error message. It could just be a hold-over from older versions of the library or older Bluetooth revisions. I see old guides and documentation refer to it, but newer software uses the more advanced APIs to manage connections, or at least connect on a per-service basis.

The BlueZ 4.x branch is still a bit difficult to work with as it is undergoing a lot of changes in a short amount of time. Hopefully the documentation will soon catch up and developers will begin working on more software that supports it. But until then, it can be a pain.