I listen for a Bluetooth connection in my server doing:

Then I connect with my Bluetooth client and this message appears:

This means that everything is alright...

Then I finish my connection by doing Ctrl+C in the server or in the client.

After this, I do again:

But this time, when I connect the client I receive this message:

So I go and I check which connections are open:
And I can see that the connection appears, as closed, but should not appear once disconnected...

The strangest thing is that sometimes, disconnection is successful and I can reconnect without any problem at all.

I have noticed similar behavior as well. Something is not right. I was using "rfcomm connect ..." to establish a connection to a bluetooth device, and I would say roughly a third of the time it either did not work or said the device was still in use after closing the connection.

To work around this I edited the file /etc/bluetooth/rfcomm and added an entry for my device using something like this

Of course you should alter the rfcomm number if you don't want to call it rfcomm0, and specify the proper channel if necessary (otherwise try 1). Now to initialize the connection

Note, the "0" is for rfcomm0, not the channel. Then when you are finished,

I don't know what is different about doing it this way as opposed to using "rfcomm connect ..." but this way seems to work a bit more reliably for some reason.

I have asked this question in other forums and they have proposed similar solutions... I pass you the link:

https://stackoverflow.com/questions/...already-in-use

Thanks

Yeah. Using bind / release in this case would be a workaround and not a solution. A proper solution would be to have "rfcomm connect" work as it should. I would suggest filing a bug report against the BlueZ package through your distribution.

If anyone does know of a proper solution or patch, I would certainly like to know as well. I often have to tear down rfcomm connections or even restart the bluetooth daemon in order to get things working.

You mention using bluetooth in a server to listen for connections. If you do not necessarily know what bluetooth devices are in the vicinity, then adding them to rfcomm.conf in advance would definitely be problematic. If this is the case you could try writing a script to automate this - run "hcitool scan" to get the MAC address(es), i.e. parse this output and add these devices to rfcomm.conf. Certainly inconvenient, but might work.

Also judging from your response in your other link, you may not know the proper channel. I don't know the reliability of connecting to multiple channels at once - you would need "sdptool browse" to find the proper channel for what you are trying to connect for. I cannot really guide you in how to do this, because I don't know what kind of channels you need. (For example, sdbtool tells me that my phone can broadcast NMEA data on Channel 5, so when I want to see GPS info I add channel 5 in rfcomm.conf.)

Another thought - does your server's bluetooth chip use closed firmware? That might have something to do with those TIOCGSERIAL issues, though that's probably a kernel ( > 3.6 ) problem. Then again, you say that when a device connects fine, you still see that message.

This can work but I prefer to remove the connection properly.

I create my own services with sdptool. I have an script that removes the default services, then creates others with serial profile. Also I change the Uuid of every sdptool service I create, so they can be distinguished separately from the Android device (client). When this is done, I do as many "rfcomm listen" as services I have.

I do this because from Android, the way of connecting to a bluetooth service is by Uuid, not by channel number. The number of the channel doesn't really matter.

I have tried with other bluetooth devices and the problem is still there...

SOLUTION

https://stackoverflow.com/questions/...-use/46915801#