Bluetooth Pairing - hci cc fails, but rfcomm connect works
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
The same usb bluetooth dongle , with the same bluetooth/bluez version (4.3),
compiled kernel (184.108.40.206) 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.
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?
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.