Can't create RFCOMM TTY: Address already in use
I listen for a Bluetooth connection in my server doing:
Code:
rfcomm listen rfcomm1 1 Code:
Connection from XX:XX:XX:XX:XX:XX to /dev/rfcomm1 Then I finish my connection by doing Ctrl+C in the server or in the client. After this, I do again: Code:
rfcomm listen rfcomm1 1 Code:
Can't create RFCOMM TTY: Address already in use Code:
rfcomm -a Code:
rfcomm1: XX:XX:XX:XX:XX:XX -> XX:XX:XX:XX:XX:XX channel 1 closed [reuse-dlc release-on-hup ] |
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 Code:
rfcomm0 { Code:
sudo rfcomm bind 0 Code:
sudo rfcomm release 0 |
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. |
Quote:
Quote:
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. Quote:
|
|
All times are GMT -5. The time now is 01:30 PM. |