Gently reminder, please check the patch. On 14.04.2025 14:50, Oleg Lyovin wrote: > Hello everyone, > > While experimenting with a device acting as and A2DP Source, I have > encountered the following very rare case during connection to an > external speaker: > > 1970-01-01 00:37:47 debug bluetoothd[240]: profiles/audio/sink.c:sink_set_state() State changed /org/bluez/hci0/dev_28_2B_B9_40_00_1B: SINK_STATE_CONNECTING -> SINK_STATE_DISCONNECTED > 1970-01-01 00:37:47 debug bluetoothd[240]: profiles/audio/avdtp.c:avdtp_unref() 0x17c1350: ref=1 > 1970-01-01 00:37:47 debug bluetoothd[240]: profiles/audio/a2dp.c:channel_remove() chan 0x17ac468 > 1970-01-01 00:37:47 debug bluetoothd[240]: profiles/audio/avdtp.c:avdtp_unref() 0x17c1350: ref=0 > 1970-01-01 00:37:47 debug bluetoothd[240]: profiles/audio/avdtp.c:avdtp_free() 0x17c1350 > 1970-01-01 00:37:50 debug bluetoothd[240]: src/shared/mgmt.c:can_read_data() [0x0000] event 0x000c > 1970-01-01 00:37:50 debug bluetoothd[240]: src/adapter.c:dev_disconnected() Device 28:2B:B9:40:00:1B disconnected, reason 2 > 1970-01-01 00:37:50 debug bluetoothd[240]: src/adapter.c:adapter_remove_connection() > 1970-01-01 00:37:50 debug bluetoothd[240]: src/device.c:device_remove_connection() connection removed while Connect() is waiting reply > 1970-01-01 00:37:50 debug bluetoothd[240]: plugins/policy.c:disconnect_cb() reason 2 > 1970-01-01 00:37:50 debug bluetoothd[240]: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 28:2B:B9:40:00:1B type 0 status 0xe > 1970-01-01 00:37:50 debug bluetoothd[240]: src/device.c:device_bonding_complete() bonding (nil) status 0x0e > 1970-01-01 00:37:50 debug bluetoothd[240]: src/device.c:device_bonding_failed() status 14 > > Subsequent attempts to connect using bluetoothctl lead to > "br-connection-busy": > [bluetooth]# connect 28:2B:B9:40:00:1B > Attempting to connect to 28:2B:B9:40:00:1B > Failed to connect: org.bluez.Error.InProgress br-connection-busy > > The reason is that "connect_profiles" does the following check: > if (dev->pending || dev->connect || dev->browse) > return btd_error_in_progress_str(msg, ERR_BREDR_CONN_BUSY); > > In the above scenario, "dev->pending" is not NULL. I have prepared > the RFC patch that frees it when a disconnect occurs in the > "device_remove_connection" code path. I'm not sure if this is the > correct way to solve the issue, but with this patch it can no longer > be reproduced. > > Oleg Lyovin (1): > device: Fix rare ERR_BREDR_CONN_BUSY during connect > > src/device.c | 4 ++++ > 1 file changed, 4 insertions(+) >
