Can't create RFCOMM TTY: Address already in use - linux

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

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

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

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

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!

Related

Minimal setup for bluetooth SDP in 2021

I have minimal linux system (no GUI, raspberry pi like board, based on buildroot) which should be able to do the following:
Allow all bluetooth clients to pair (no pin) after pressing a button for 60 seconds
Allow connection using SPP (serial port profile)
Endpoint of the SPP should be something like /dev/rfcomm
In an older version of buildroot (setup around 2016) I was able to do this using the following commands executed after the button press:
dbus-daemon &
bluetoothd --compat &
hciconfig hci0 up
hciconfig hci0 noauth
hciconfig hci0 sspmode 1
hciconfig hci0 class 0x080500
hciconfig hci0 name foobar
hciconfig hci0 piscan
sdptool add --channel=22 SP
rfcomm listen /dev/rfcomm0 22
I could then pair from my android phone without pin and connect to the SPP interface using this app. Since then hciconfig, sdptool and rfcomm where deprecated. If I try the above method I can't pair from my phone (got connection refused). Without pairing the SPP stuff can't work obviously.
What would be the preferred way in 2021 to setup a headless system which behaves as described above?

Bluetooth LE on Raspbian does not bond with nRF

I have an Rpi3 and I want to bond it with nRF which is connected to my laptop via UART. This nRF-laptop connection shows me whether Rpi3 is connected and/or paired with nRF. I am able to connect to the nRF device by running:
gatttool -t random -b XX:XX:XX:XX:XX:XX -I
I found that to be able to pair it, all I need to do is run the following command after I connected using gattool:
sec-level medium
However, nRF device only showed "Connected".
Then I tried using bluetoothctl command. I made sure the power is on, agent is on, it's discoverable and etc. After I ran the command pair XX:XX:XX:XX:XX:XX, it said it was successful. This was also confirmed after running info XX:XX:XX:XX:XX:XX. Yet nRF device did not react to the pairing. If I connect to nRF device through my phone using "nRF Connect" app, then nRF shows that my phone is paired.
I am running:
Linux 4.9.13-v7+ #974 SMP Wed Mar 1 20:09:48 GMT 2017 armv7l GNU/Linux
PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
Bluez-5.44
I followed tutorials from adafruit and stackoverflow. I read that for Bluez-5.44 I do not need to run bluetooth in the experimental mode.
What am I missing? I would appreciate any help.
To any lost souls who might have also been stuck in this situation, here is how I solved it (you need to run sudo for the following commands):
$ service bluetooth stop
$ /etc/init.d/bluetooth start
If the nRF device has been paired once and then restarted, that means the pairing key is still on Pi's side which needs to be removed and can be done by:
$ bluetoothctl
$ remove XX:XX:XX:XX:XX:XX
$ exit
After this you need to start bluetooth device:
$ hciconfig hci0 up

Is this bluetooth configuration sufficient?

I have a Yocto/Open Embedded Linux build for a Gumstix Overo Y COM which I am trying to integrate bluetooth into (using Bluez4).
When I boot my image, the onboard bluetooth module (wilink 8) is unresponsive. Is the configuration I outline below sufficient? If not, what is missing?
The kernel, linux-firmware and bluez4 recipe append are from the meta-gumstix repo [fido] branch (https://github.com/gumstix/meta-gumstix) - one change I have made is the system uses sysvinit instead of systemd.
3.18 kernel with all patches and the defconfig:
meta-gumstix/recipes-kernel/linux/linux-gumstix_3.18.bb
meta-gumstix/recipes-kernel/linux/linux-gumstix-3.18/
Firmware append recipe:
meta-gumstix/recipes-kernel/linux-firmware_git.append
meta-gumstix/recipes-kernel/linux-firmware/linux-firmware/
Bluez4 recipe append:
meta-gumstix/recipes-connectivity/bluez/bluez4_4.101.bbappend
meta-gumstix/recipes-connectivity/bluez/files/
When I boot, this is all hcitool can tell me:
hcitool dev:
parallels#ubuntu:~$ hcitool dev
Devices:
root#overo:~# hcitool scan
Device is not available: No such device
root#overo:~# /usr/sbin/hciattach -n ttyO1 texas
Initialization timed out.
If I start Bluez:
root#overo:~# dmesg | grep -i bluetooth
root#overo:~# bluetoothd -d
root#overo:~# rfcomm bind all
root#overo:~# dmesg | grep -i bluetooth
[ 62.131408] Bluetooth: Core ver 2.19
[ 62.131622] Bluetooth: HCI device and connection manager initialized
[ 62.132080] Bluetooth: HCI socket layer initialized
[ 62.132141] Bluetooth: L2CAP socket layer initialized
[ 62.132263] Bluetooth: SCO socket layer initialized
[ 62.190826] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 62.190856] Bluetooth: BNEP filters: protocol multicast
[ 62.190917] Bluetooth: BNEP socket layer initialized
[ 71.641448] Bluetooth: RFCOMM TTY layer initialized
[ 71.641540] Bluetooth: RFCOMM socket layer initialized
[ 71.641601] Bluetooth: RFCOMM ver 1.11
Then dbus tells me:
root#overo:~# dbus-send --system --dest=org.freedesktop.DBus --type=method_call --print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames
method return sender=org.freedesktop.DBus -> dest=:1.2 reply_serial=2
array [
string "org.freedesktop.DBus"
string ":1.0"
string "org.bluez"
string ":1.1"
string ":1.2"
]
root#overo:~#
(root#overo:~# cat introspect_bt.py
#!/usr/bin/env python
import dbus
from xml.etree import ElementTree
def rec_intro(bus, service, object_path):
print(object_path)
obj = bus.get_object(service, object_path)
iface = dbus.Interface(obj, 'org.freedesktop.DBus.Introspectable')
xml_string = iface.Introspect()
for child in ElementTree.fromstring(xml_string):
if child.tag == 'node':
if object_path == '/':
object_path = ''
new_path = '/'.join((object_path, child.attrib['name']))
rec_intro(bus, service, new_path)
bus = dbus.SystemBus()
rec_intro(bus, 'org.bluez', '/org/bluez')
root#overo:~#
)
root#overo:~# python introspect_bt.py
/org/bluez
/org/bluez/1309
/org/bluez/1309/any
I would expect bluez to list an adapter such as /org/bluez/1309/hci0. As neither hcitool or bluez seem to be able to locate my bluetooth module, am I missing something in the setup / configuration?
I'm more than happy to edit this to include any extra information that you might find useful.
Thanks!
Edited with further info:
#parthiban-n -
Bringing the adapter up doesn't work
root#overo:~# hciconfig hci0 up
Can't get device info: No such device
& I don't know where the adapter sits (I think this is the root problem - bluez doesn't seem to know anything about the hardware and doesn't have an adapter for it). Is this something that I can configure myself, or should bluez automatically recognise the module?
I used bluez5 initially with the same results, before downgrading to bluez4 (I'm loath to change back as switching bluez version is a complete delete-cache & rebuild, around 6 hours!). I imagine that as hciconfig & hcitool can't communicate with the BT module the problem was unlikely to be with bluez, AFAIK hci**** don't use bluez for their operation.
#aksonlyaks -
The module is not USB connected, it's an onboard combined WIFI/BT module - the Wilink8 WL1831MOD which seems to use a combined driver for WIFI & BT. The WIFI works fine, so I think it's OK from the driver side of things. Here's some output from /proc/modules & dmesg which looks good to me, but I've posted it up in case there is anything obviously missing:
root#overo:~# cat /proc/modules
rfcomm 34100 0 - Live 0xbf2d3000
bnep 10602 2 - Live 0xbf2cc000
bluetooth 300191 8 rfcomm,bnep, Live 0xbf270000
ipv6 367991 16 [permanent], Live 0xbf1ff000
ctr 3441 2 - Live 0xbf1fb000
ccm 7252 2 - Live 0xbf1f6000
ft6206 3532 0 - Live 0xbf1f2000 (O)
arc4 1688 2 - Live 0xbf1ee000
wl18xx 81650 0 - Live 0xbf1d1000
wlcore 177003 1 wl18xx, Live 0xbf198000
mac80211 478003 2 wl18xx,wlcore, Live 0xbf0fb000
cfg80211 408851 3 wl18xx,wlcore,mac80211, Live 0xbf06a000
rfkill 19564 4 bluetooth,cfg80211, Live 0xbf060000
wlcore_sdio 3947 0 - Live 0xbf058000
twl4030_madc 9173 0 - Live 0xbf052000
industrialio 27152 1 twl4030_madc, Live 0xbf045000
fpgaDrv352 13275 2 - Live 0xbf03e000 (O)
usb_f_ecm 8379 1 - Live 0xbf037000
pwm 6671 0 - Live 0xbf031000 (O)
fpgaCfgDrv 5623 0 - Live 0xbf02c000 (O)
g_ether 3375 0 - Live 0xbf027000
usb_f_rndis 21372 2 g_ether, Live 0xbf01c000
u_ether 14284 3 usb_f_ecm,g_ether,usb_f_rndis, Live 0xbf014000
libcomposite 46775 3 usb_f_ecm,g_ether,usb_f_rndis, Live 0xbf000000
I think wl18xx & wlcore are the main driver components for the WL1831MOD.
root#overo:~# dmesg | grep -i wl
[ 2.430389] twl 0-0048: PIH (irq 23) chaining IRQs 339..347
[ 2.430999] twl 0-0048: power (irq 344) chaining IRQs 347..354
[ 2.437225] twl_rtc 48070000.i2c:twl#48:rtc: Power up reset detected.
[ 2.437805] twl_rtc 48070000.i2c:twl#48:rtc: Enabling TWL-RTC
[ 2.442840] twl_rtc 48070000.i2c:twl#48:rtc: rtc core: registered 48070000.i2c:twl#48 as rtc0
[ 2.511505] twl4030_gpio twl4030-gpio: gpio (irq 339) chaining IRQs 355..372
[ 2.513275] gpiochip_add: registered GPIOs 492 to 511 on device: twl4030
[ 2.524597] twl4030_usb 48070000.i2c:twl#48:twl4030-usb: Initialized TWL4030 USB module
[ 2.531158] input: twl4030_pwrbutton as /devices/68000000.ocp/48070000.i2c/i2c-0/0-0048/48070000.i2c:twl#48:pwrbutton/input/input0
[ 2.534881] twl4030_keypad 48070000.i2c:twl#48:keypad: OF: linux,keymap property not defined in /ocp/i2c#48070000/twl#48/keypad
[ 2.547119] twl4030_keypad 48070000.i2c:twl#48:keypad: Failed to build keymap
[ 2.554748] twl4030_keypad: probe of 48070000.i2c:twl#48:keypad failed with error -2
[ 2.760864] twl_rtc 48070000.i2c:twl#48:rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800)
[ 8.107849] twl4030_madc 48070000.i2c:twl#48:madc: clk disabled, enabling
[ 11.101715] wlcore: wl18xx HW: 183x or 180x, PG 2.2 (ROM 0x11)
[ 11.224395] wlcore: loaded
[ 19.257476] wlcore: PHY firmware version: Rev 8.2.0.0.195
[ 19.375305] wlcore: firmware booted (Rev 8.8.0.0.13)
[ 23.282714] wlan0: authenticate with 30:b5:c2:66:4c:04
[ 23.306152] wlan0: send auth to 30:b5:c2:66:4c:04 (try 1/3)
[ 23.327819] wlan0: authenticated
[ 23.338958] wlan0: associate with 30:b5:c2:66:4c:04 (try 1/3)
[ 23.345367] wlan0: RX AssocResp from 30:b5:c2:66:4c:04 (capab=0x431 status=0 aid=5)
[ 23.390258] wlan0: associated[ 23.624877] wlcore: Association completed.
It looks like the driver comes up and then there are some wlan related messages, nothing specific to bluetooth operation or intialisation that I can see.

hciconfig -a Connection timed out (110) , bluez, btusb

I am experiencing this issue on my raspberry pi.
After a while of my python program running, it seems like one (or more) of the bluetooth adapters will "lock up" and hciconfig -a will output:
: Connection timed out (110)
root ~ # hciconfig -a
hci3: Type: BR/EDR Bus: USB
BD Address: 5C:F3:70:61:CA:D6 ACL MTU: 9000:8 SCO MTU: 64:1
UP RUNNING
RX bytes:5315773 acl:178107 sco:0 events:287995 errors:0
TX bytes:487424645 acl:527773 sco:0 commands:13454 errors:0
Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH SNIFF
Link mode: SLAVE ACCEPT
Can't read local name on hci3: Connection timed out (110)
The problem seems to manifest more frequently when multiple adapters are used.
The project I am working on involves using multiple (and sometimes single) USB bluetooth adapters to obex-push files to phones.
The python program that does the following things:
1.automatically detects adapters - #hciconfig -a
2.configures them - #hciconfig CMD
3.Inquires devices - #hcitool -i inq
4.Obex push files on (possibly simultaneously with other threads and other ) - bluez dbus
Some info from my system:
root ~ # modinfo btusb
filename: /lib/modules/3.12.29-1-ARCH/kernel/drivers/bluetooth/btusb.ko.gz
license: GPL
version: 0.6
description: Generic Bluetooth USB driver ver 0.6
author: Marcel Holtmann <marcel#holtmann.org>
srcversion: 61D6539530170376DCAF49C
alias: usb:v*p*d*dcE0dsc01dp01ic*isc*ip*in*
...
depends: bluetooth
intree: Y
vermagic: 3.12.29-1-ARCH preempt mod_unload modversions ARMv6
...
root ~ # pacman -Q
...
bluez 5.24-1
bluez-utils 5.24-1
...
dbus 1.8.0-1
dbus-glib 0.102-1
...
libusb 1.0.18-1
...
linux-api-headers 3.13.2-1
linux-firmware 20140217.343e460-1
linux-raspberrypi 3.12.29-1
Any ideas/or suggestions?
Is there a newer version of btusb? I looked, but I came up mostly empty handed
Note: I am somewhat of a Linux newb (though I am learning) =-)
...
PS:
These forums seem to suggest that something similar may have been fixed:
https://bbs.archlinux.org/viewtopic.php?id=183411
https://bbs.archlinux.org/viewtopic.php?id=183038
but the referenced problem appears to be specifically with the Atheros adapter chipset and I am using Broadcom chipset. Also, it appears the latest version of linux I can get for the rpi is 13.13 headers and linux-raspberrypi 13.12

bluetooth pairing and connection from command line

I want to connect and pair to available nearby bluetooth devices from command line in linux.
I have searched through internet, and found that we can pair through simple-agent, but it is not available in my device.
following commands are available in device:
hcitool, hciconfig, hcidump, sdptool, l2ping, rfcomm.
for connecting to remote device i am running the following command.
hcitool cc BD_ADDRESS
but above command is connecting the device for a while, and again the device is getting disconnected. in hcidump output , i am seeing the disconnection event. Is there anyway in linux command line through which i can test my bluetooth? What can be the reason for device is getting disconnected after a while?
I saw the same issue once and was able to solve it with the rfcomm command. Try the following:
# rfcomm connect /dev/rfcomm0 00:11:22:33:44:55 1 &
Additionally, it is good practice to enable secure simple pairing and enable page and inquiry scan with the following commands:
# hciconfig hci0 sspmode 1
# hciconfig hci0 piscan
Let me know if you still have problems.

Resources