Can't create RFCOMM TTY: Address already in use

Question

I listen for a Bluetooth connection in my server doing:

rfcomm listen rfcomm1 1

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

Connection from XX:XX:XX:XX:XX:XX to /dev/rfcomm1
Press CTRL-C for hangup

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:

rfcomm listen rfcomm1 1

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

Can't create RFCOMM TTY: Address already in use

So I go and I check which connections are open:

rfcomm -a

And I can see that the connection appears, as closed, but should not appear once disconnected...

rfcomm1: XX:XX:XX:XX:XX:XX -> XX:XX:XX:XX:XX:XX channel 1 closed [reuse-dlc release-on-hup ]

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

EDIT

I realized that when the device keeps connected about 10 seconds or more, then the disconnection is successful. But when this time is shorter (fast connection/disconnection), the problem occurs.

And if while the failure is taking place, I do:

dmesg

This is printed:

[11800.001527] Bluetooth: TIOCGSERIAL is not supported
[11800.033063] Bluetooth: TIOCGSERIAL is not supported
[11926.708438] Bluetooth: TIOCGSERIAL is not supported
[11934.918197] Bluetooth: TIOCGSERIAL is not supported
[11934.926194] Bluetooth: TIOCGSERIAL is not supported
[11934.926284] ------------[ cut here ]------------
[11934.926297] WARNING: CPU: 1 PID: 2316 at /build/linux-Pcn0xK/linux-4.4.0/drivers/tty/tty_port.c:143 tty_port_destructor+0x7a/0x80()
[11934.926300] Modules linked in: minidriver(OE) nls_utf8 isofs rfcomm bnep arc4 ath5k snd_hda_codec_realtek uvcvideo ath mac80211 snd_hda_codec_hdmi snd_hda_codec_generic snd_hda_intel videobuf2_vmalloc snd_hda_codec samsung_laptop videobuf2_memops snd_hda_core btusb videobuf2_v4l2 btrtl snd_hwdep videobuf2_core coretemp btbcm cfg80211 snd_pcm v4l2_common btintel snd_seq_midi joydev videodev bluetooth snd_seq_midi_event serio_raw media snd_rawmidi input_leds snd_seq snd_seq_device snd_timer snd soundcore shpchp lpc_ich mac_hid binfmt_misc parport_pc ppdev lp parport autofs4 hid_logitech ff_memless uas usb_storage hid_generic usbhid hid amdkfd amd_iommu_v2 radeon psmouse pata_acpi i2c_algo_bit ttm sky2 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops video fjes drm [last unloaded: minidriver]

[11934.926401] CPU: 1 PID: 2316 Comm: kworker/1:1 Tainted: G        W  OE   4.4.0-97-generic #120-Ubuntu
[11934.926404] Hardware name: SAMSUNG ELECTRONICS CO., LTD. R520/R522/R620               /R520/R522/R620               , BIOS 05LL.M025.20090916.Jay 09/16/20
[11934.926410] Workqueue: events release_one_tty
[11934.926413]  0000000000000286 c977cef9c84bca31 ffff88012ea3fd48 ffffffff813fabe3
[11934.926419]  0000000000000000 ffffffff81d386c0 ffff88012ea3fd80 ffffffff810812e2
[11934.926425]  ffff8800b5153800 ffff8800b67f6400 ffff8800b67f6400 ffffffffc06dc840
[11934.926430] Call Trace:
[11934.926438]  [<ffffffff813fabe3>] dump_stack+0x63/0x90
[11934.926445]  [<ffffffff810812e2>] warn_slowpath_common+0x82/0xc0
[11934.926450]  [<ffffffff8108142a>] warn_slowpath_null+0x1a/0x20
[11934.926455]  [<ffffffff8150357a>] tty_port_destructor+0x7a/0x80
[11934.926460]  [<ffffffff81503ce8>] tty_port_put+0x28/0x30
[11934.926471]  [<ffffffffc06d5fa8>] rfcomm_tty_cleanup+0x68/0x70 [rfcomm]
[11934.926475]  [<ffffffff814f91fb>] release_one_tty+0x3b/0xc0
[11934.926481]  [<ffffffff8109a635>] process_one_work+0x165/0x480
[11934.926486]  [<ffffffff8109a99b>] worker_thread+0x4b/0x4c0
[11934.926491]  [<ffffffff8109a950>] ? process_one_work+0x480/0x480
[11934.926496]  [<ffffffff810a0c75>] kthread+0xe5/0x100
[11934.926500]  [<ffffffff810a0b90>] ? kthread_create_on_node+0x1e0/0x1e0
[11934.926507]  [<ffffffff81843b8f>] ret_from_fork+0x3f/0x70
[11934.926511]  [<ffffffff810a0b90>] ? kthread_create_on_node+0x1e0/0x1e0
[11934.926515] ---[ end trace a33c33d1fdbe410d ]---
[11936.001325] Bluetooth: TIOCGSERIAL is not supported
[11936.033194] Bluetooth: TIOCGSERIAL is not supported

When everything works fine (10 or more sec), only these messages are shown:

[11936.001325] Bluetooth: TIOCGSERIAL is not supported
[11936.033194] Bluetooth: TIOCGSERIAL is not supported
[11936.001325] Bluetooth: TIOCGSERIAL is not supported
[11936.033194] Bluetooth: TIOCGSERIAL is not supported

Uniocular

Answer 1

SOLUTION

The problem was a package that comes installed in Ubuntu that was interfering with the normal release of the device.

Just do:

apt-get remove --purge modemmanager

Uniocular

Answer 2

Have you tried using release?

sudo rfcomm release 0

Or alternatively directly adding your device into /etc/bluetooth/rfcomm and then binding it instead and then try the release after you are finished.

sudo rfcomm bind 0

Lusitania

The problem is still there after doing 'release'. I have to do 'listen' instead of 'bind' because I don't know how many devices are going to connect to it. So I have the max possible number of channels listening and when a mobile tries to connect, a new /dev/rfcomm* is created. I don't know the MACs of the clients before the connection so I can't subscribe them previously to /etc/bluetooth/rfcomm (I can't find this file in /etc/bluetooth). And the problem comes when disconnecting, I'll edit my post to give more details. – Uniocular

@Sergio. That's good news, can you post your answer for others who may have the same problem? – Lusitania

Answer 3

Given that there is no issue if you wait 10 seconds before disconnecting, I think we have a solid lead: The RFCOMM spec (https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=263754) defines 10 seconds as the minimum timeout for data ACKs ("Acknowledgement Timer (T1)") and control channel responses ("Response Timer for Multiplexer Control Channel (T2)"). Most likely, you have un-ACKed data on the control channel from your client (doesn't sound like you've sent data). Although I wouldn't expect this to cause problems upon disconnect, it is likely that an issue within the BlueZ stack is causing problem when you try to release the TTY while it's waiting for this ACK.

1. Have you tried sending data on the channel? If the control channel is truly going un-ACK'd, it would be surprising if you able to exchange data.

2. Have you tried using a different device as your RFCOMM client? Perhaps an issue in the stack on there client side is not ACKing control signals.

I haven't worked extensively with the BlueZ stack, so I can't provide exact code changes, but hopefully this is enough information to formulate a work-around (e.g. if you can track down the timer that is waiting for this ACK, perhaps you could kill it).

Infundibuliform

The issue persists in my case even after staying connected for at least 10 seconds. – Harbison

Answer 4

This error occurs because a process is holding the port open and only releases if the port is closed.

To check which device isn't releasing the port: sudo lsof | grep /dev/rfcomm0 (or whatever port is assigned)

So simple answer is, close the comm port within the application and happy days!

Stripy

sudo lsof | grep /dev/rfcomm0 returns nothing, but the port is still busy. – Harbison