-
Notifications
You must be signed in to change notification settings - Fork 330
Description
I have a machine where I am attempting to run both a Peripheral Application(Running a GATT Server) and a Central application (running a GATT Client) using Bluez.
Connections fail, if they are not established in a certain order. To be clear. If the outgoing connection is established first, there is no issue being connected twice.
If a remote central is connected to the peripheral application on the machine, the central application is unable to connect to a remote peripheral. When the remote central is disconnected, the local central can once again connect to remote peripherals. If the events occur in the opposite order, ie - the central application connects to a remote peripheral, the peripheral application is able to receive incoming connections without issue.
In an attempt to take our applications out of the equation, I was able to reproduce the behavior in two others cases.
- Using the test/example-gatt-server provided by bluez and the ubuntu ui to connect to a remote gatt server.
- Using the bluetootchctl tool.
Reproducing the issue with bluetootchctl
If you run through the steps in Setup Advertising, the behavior described above appears. If you run “Connect remote device to local machine” first, followed by “Connect local machine to remote device”, the second connection fails. If you run the steps in the reverse direction, everything works.
Setup Advertising
- bluetoothctl
- menu advertise
- name on
- back
- advertise on
- discoverable on
Connect remote device to local machine.
Steps for this depend on the remote device being used.
Connect local machine to remote device
- scan on
- scan off
- devices ( to find and identify the device to connect to )
- connect "MAC ADDRESS"
I don't have the logs available at the moment. I can attach them later.
In both cases the log shows "Connection attempt to: ...". This is printed out in the device_connect_le method of the device.c file.
In the case where the connection fails, that is the last message. When thing work, the next log statement is a notification that the device connected. It originates in the connected_callback method of the adapter.c file.
Hardware/Software Versions.
BLUEZ: 5.50.
Kernel: 5.10.104-tegra.
I have seen the same behavior on two additional machines. An x86 Ubuntu 22.04 VM(running a 5.6x build of bluez) and a Raspbian Pi4 build (running a 5.50 build of bluez). (Will have to add version information later).
hciconfig -a
- hci0: Type: Primary Bus: USB
- BD Address: D4:6D:6D:ED:54:99 ACL MTU: 1021:4 SCO MTU: 96:6
- UP RUNNING PSCAN ISCAN
- RX bytes:15062 acl:0 sco:0 events:2432 errors:0
- TX bytes:597226 acl:0 sco:0 commands:2430 errors:0
- Features: 0xff 0xfe 0x0f 0xfe 0xdb 0xff 0x7b 0x87
- Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
- Link policy: RSWITCH HOLD SNIFF
- Link mode: SLAVE ACCEPT
- Name: 'hostname'
- Class: 0x200000
- Service Classes: Audio
- Device Class: Miscellaneous,
- HCI Version: 4.2 (0x8) Revision: 0x100
- LMP Version: 4.2 (0x8) Subversion: 0x100
- Manufacturer: Intel Corp. (2)
Any and all help is appreciated! Thanks.