3
votes

The connection to a Bluetooth device via RFCOMM fails on Linux/Bluez with Connection refused at the call of connect(s, (struct sockaddr *)&addr, sizeof(addr));. The device was successfully paired. An RFCOMM connection to that device from Android or Windows can be successfully established, so the problem seems to be locaed with Bluez diver and/or blueotoothd.

With Linux/Bluez the bluetoothctl and Wireshark traces show that it fist connects and then after about 2 seconds a disconnection is done. The reason for the disconnection is not clear.

The same problem happens with different Linux releases, on PC with USB Bluetooth (Linux ubuntu 4.15.0-33-generic #36~16.04.1-Ubuntu SMP Wed Aug 15 17:21:05 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux) or Raspberry Pi 3 (Jessie, Stretch).

I have checked numerous other thread having the same/similar problem. Most have no or no clear answer.

The Wireshark trace screenshot shows the disconnect after 2.2 seconds.

The corresponding bluetoothd syslog output:

Aug 31 16:43:54 ubuntu bluetoothd[926]: src/adapter.c:connected_callback() hci0 device F6:65:0A:E5:DE:E1 connected eir_len 22
Aug 31 16:43:54 ubuntu bluetoothd[926]: src/device.c:device_create() dst F6:65:0A:E5:DE:E1
Aug 31 16:43:54 ubuntu bluetoothd[926]: src/device.c:device_new() address F6:65:0A:E5:DE:E1
Aug 31 16:43:55 ubuntu bluetoothd[926]: src/device.c:device_new() Creating device /org/bluez/hci0/dev_F6_65_0A_E5_DE_E1
Aug 31 16:43:57 ubuntu bluetoothd[926]: src/adapter.c:dev_disconnected() Device F6:65:0A:E5:DE:E1 disconnected, reason 3
Aug 31 16:43:57 ubuntu bluetoothd[926]: src/adapter.c:adapter_remove_connection()
Aug 31 16:43:57 ubuntu bluetoothd[926]: src/adapter.c:adapter_remove_connection() Removing temporary device /org/bluez/hci0/dev_F6_65_0A_E5_DE_E1
Aug 31 16:43:57 ubuntu bluetoothd[926]: src/device.c:device_remove() Removing device /org/bluez/hci0/dev_F6_65_0A_E5_DE_E1
Aug 31 16:43:57 ubuntu bluetoothd[926]: src/device.c:btd_device_unref() Freeing device /org/bluez/hci0/dev_F6_65_0A_E5_DE_E1
Aug 31 16:43:57 ubuntu bluetoothd[926]: src/device.c:device_free() 0x563aa2a270a0
Aug 31 16:43:57 ubuntu bluetoothd[926]: plugins/policy.c:disconnect_cb() reason 3
Aug 31 16:43:57 ubuntu bluetoothd[926]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr F6:65:0A:E5:DE:E1 type 0 status 0xe
Aug 31 16:43:57 ubuntu bluetoothd[926]: src/adapter.c:resume_discovery()

reason 3 points to MGMT_DEV_DISCONN_REMOTE in include/net/bluetooth/mgmt.h of the kernel sources. This would mean that it is the device who initiates the disconnect. But the highlighted line in the Wireshark trace shows that it is the host that initiates the disconnection.

Many thanks for any help in advance.

1
This often happens when bluez doesn't have all the mandatory profiles which the device needs. I am not sure about libbluetooth based operations, but still you can try using "ConnectProfile" method to connect to specific profile, see here: git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/… By default "Connect" will try to resolve and connect all the profiles the device supports. Failing to connect with all the profiles exits the connection and leaves the device in paired state.Parthiban
Thanks for your hint. Setting a profile would probably automatically pick the correct RFCOMM channel. But it seems not obvious to me how a profile can be set.shpc

1 Answers

1
votes

The incorrect RFCOMM channel was used. It instantly works when the correct RFCOMM channel is used.

sdptool records F6:65:0A:E5:DE:E1 shows on which channel the RFCOMM is:

Service Name: Serial Port
Service RecHandle: 0x10000
Service Class ID List:
  "Serial Port" (0x1101)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 5