无法创建RFCOMM TTY:地址已经在使用

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.

然后在服务器或客户端执行Ctrl+C完成连接。

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.

我意识到，当设备保持10秒或更长时间连接时，断开连接就成功了。但是当这个时间较短(快速连接/断开连接)时，问题就出现了。

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:

当一切正常时(10秒或10秒以上)，只显示以下信息:

[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

4 个解决方案

#1

Have you tried using release?

你试过使用release函数吗?

sudo rfcomm release 0

sudo rfcomm发布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.

或者直接将设备添加到/etc/ blueteeth /rfcomm文件中，然后将其绑定，然后在完成之后尝试发布。

sudo rfcomm bind 0

sudo rfcomm绑定0

#2

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.

考虑到在断开连接前等待10秒是没有问题的，我认为我们有一个可靠的线索:RFCOMM规范(https://www.bluefang.org/docman/handlers/downloaddoc.ashx?很有可能，您已经从您的客户端(听起来不像您发送了数据)从控制通道上删除了数据。虽然我不会期望这会在断开连接时引发问题，但是当您试图在等待这个ACK时释放TTY时，BlueZ堆栈中的一个问题可能会引起问题。

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.

你试过在通道上发送数据吗?如果控制通道真的在断开连接，如果您能够交换数据，那将是令人惊讶的。
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.

您是否尝试过使用不同的设备作为您的RFCOMM客户端?客户端栈中的一个问题可能是没有调用控制信号。

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).

我还没有广泛地使用BlueZ堆栈，所以我不能提供准确的代码更改，但希望这足够让我制定一个解决方案(例如，如果您可以跟踪等待ACK的计时器，也许您可以终止它)。

#3

SOLUTION

解决方案

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

问题是在Ubuntu中安装的一个包妨碍了设备的正常发布。

Just do:

只做:

apt-get remove --purge modemmanager

#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)

要检查哪个设备没有释放端口:sudo lsof | grep /dev/rfcomm0(或分配的任何端口)

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

简单的回答就是，在申请期间关闭通讯端口，开心的日子!

#1