Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Bug#1032256: blueman: auto-connect incomplete, needs additional "bluetoothctl connect <Id>" to work

130 views
Skip to first unread message

Alf

unread,
Mar 2, 2023, 7:20:36 AM3/2/23
to
Package: blueman
Version: 2.3.5-2+b1
Severity: important

After a fresh boot of the PC, sound is routed through hardware audio chip as
Profile: "Analog Stereo Duplex" selected in pavucontol (graphical Tool)
and works fine via pipewire and pipewire-pulse.

When I want to use my Headset (ear-buds with micro build in), i.e. to make a phone call
using linphone I have to connect them via bluetooh to my adapter build in Intel AX200 WiFi card.

Headset/ear-buds are "Hama Freedom Light" with bluetooth 5.1 supporting these profiles:
A2DP v1.3
AVRCP v1.5
HFP v1.5
SPP v1.0

Connection fails when performing the usual way using blueman after pairing and trusting.
Blueman reports (auto-)"connected", but the device is not available for selection,
neither in linphone, nor in pavucontrol.

I tried various settings in /etc/bluetooth/main.conf without any success.
But I found a dirty workaround by watching bluetooth messages and "try and error".

Executing the interactive "bluetoothctl" command shows following.

ingo@xpc:~$ bluetoothctl
Agent registered
[bluetooth]# info 3C:F8:A8:B9:CE:A1
Device 3C:F8:A8:B9:CE:A1 (public)
Name: Hama Freedom Light
Alias: Hama Freedom Light
Class: 0x00240404
Icon: audio-headset
Paired: yes
Bonded: yes
Trusted: yes
Blocked: no
Connected: no
LegacyPairing: no
UUID: Audio Sink (0000110b-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
UUID: Advanced Audio Distribu.. (0000110d-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
UUID: Handsfree (0000111e-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
Modalias: bluetooth:v05D6p000Ad0240
[CHG] Device 3C:F8:A8:B9:CE:A1 Connected: yes
[Hama Freedom Light]#

>>> Some seconds after device is switched on (taken out of its box), blueman reports it as connected,
>>> but device still blinks to indicate it is not yet ready. No sound profile available at this time.

[CHG] Devicde 3C:F8:A8:B9:CE:A1 Connected: yes
[Hama Freedom Light]# info 3C:F8:A8:B9:CE:A1
Device 3C:F8:A8:B9:CE:A1 (public)
Name: Hama Freedom Light
Alias: Hama Freedom Light
Class: 0x00240404
Icon: audio-headset
Paired: yes
Bonded: yes
Trusted: yes
Blocked: no
Connected: yes
LegacyPairing: no
UUID: Audio Sink (0000110b-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
UUID: Advanced Audio Distribu.. (0000110d-0000-1000-8000-00805f9b34fb)
UUID: A/V Remote Control (0000110e-0000-1000-8000-00805f9b34fb)
UUID: Handsfree (0000111e-0000-1000-8000-00805f9b34fb)
UUID: PnP Information (00001200-0000-1000-8000-00805f9b34fb)
Modalias: bluetooth:v05D6p000Ad0240
[Hama Freedom Light]#

>>> Issue command "connect <MAC>" now a second time (first time was auto-connected):

[Hama Freedom Light]# connect 3C:F8:A8:B9:CE:A1
Attempting to connect to 3C:F8:A8:B9:CE:A1
[NEW] Endpoint /org/bluez/hci0/dev_3C_F8_A8_B9_CE_A1/sep2
[NEW] Endpoint /org/bluez/hci0/dev_3C_F8_A8_B9_CE_A1/sep1
[NEW] Transport /org/bluez/hci0/dev_3C_F8_A8_B9_CE_A1/sep1/fd0
Connection successful
[CHG] Device 3C:F8:A8:B9:CE:A1 ServicesResolved: yes
[CHG] Transport /org/bluez/hci0/dev_3C_F8_A8_B9_CE_A1/sep1/fd0 Volume: 0x0060 (96)
[Hama Freedom Light]#

>>> Device stops blinking and device is rercognized by pipeire-pulse all works as expected.
>>> All is fine now can use it i.e. with profile HFP and codec mSBC for phone calls ...
>>> Next: device switched off (put it back in its box):

[DEL] Transport /org/bluez/hci0/dev_3C_F8_A8_B9_CE_A1/sep1/fd0
[DEL] Endpoint /org/bluez/hci0/dev_3C_F8_A8_B9_CE_A1/sep2
[DEL] Endpoint /org/bluez/hci0/dev_3C_F8_A8_B9_CE_A1/sep1
[CHG] Device 3C:F8:A8:B9:CE:A1 ServicesResolved: no
[CHG] Device 3C:F8:A8:B9:CE:A1 Connected: no
[bluetooth]#

[bluetooth]# exit
ingo@xpc:~$


Additional info:
When blueman reports "connected" at the first discovery of my ear-buds nothing is logged in system journal.
When I then issue the "bluetoohtctl connect 3C:F8:A8:B9:CE:A1" comand another time to comlpete setup,
journal logs:

Mär 01 16:39:09 xpc wireplumber[1327]: RFCOMM receive command but modem not available: AT+CHLD=?
Mär 01 16:39:09 xpc wireplumber[1327]: RFCOMM receive command but modem not available: AT+CCWA=1
Mär 01 16:39:09 xpc wireplumber[1327]: RFCOMM receive command but modem not available: AT+NREC=0
Mär 01 16:39:09 xpc wireplumber[1327]: RFCOMM receive command but modem not available: AT+CGMI?
Mär 01 16:39:09 xpc kernel: input: Hama Freedom Light (AVRCP) as /devices/virtual/input/input27
Mär 01 16:39:09 xpc Thunar[4070]: thunar-volman: Nicht unterstützter Eingabegerätetyp »(null)«.
Mär 01 16:39:09 xpc systemd-logind[871]: Watching system buttons on /dev/input/event20 (Hama Freedom Light (AVRCP))
Mär 01 16:39:10 xpc Thunar[4075]: thunar-volman: Nicht unterstützter Eingabegerätetyp »/dev/input/event20«.

I do not have the knowledge for further debugging this complicated bluetooth attitude.
My guess currently is, the first auto-connect is with AVRCP profile only and the ear-buds are
waiting for further information and/or callback. The second (manual) connect then registers the
selected profile and completes connection.

Regards, Alf

-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing'), (50, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-5-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages blueman depends on:
ii adwaita-icon-theme 43-1
ii bluez 5.66-1
ii bluez-obexd 5.66-1
ii dbus 1.14.6-1
ii dbus-user-session [default-dbus-session-bus] 1.14.6-1
ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4
ii gir1.2-gdkpixbuf-2.0 2.42.10+dfsg-1+b1
ii gir1.2-glib-2.0 1.74.0-3
ii gir1.2-gtk-3.0 3.24.36-4
ii gir1.2-nm-1.0 1.42.0-1
ii gir1.2-pango-1.0 1.50.12+ds-1
ii gnome-icon-theme 3.12.0-5
ii libbluetooth3 5.66-1
ii libc6 2.36-8
ii libpulse-mainloop-glib0 16.1+dfsg1-2+b1
ii librsvg2-common 2.54.5+dfsg-1
ii polkitd 122-3
ii python3 3.11.2-1
ii python3-cairo 1.20.1-5+b1
ii python3-gi 3.42.2-3+b1
ii python3-gi-cairo 3.42.2-3+b1
ii xfce4-notifyd [notification-daemon] 0.7.3-1

Versions of packages blueman recommends:
pn pulseaudio-module-bluetooth <none>

blueman suggests no packages.

-- no debconf information

Ingo

unread,
Mar 2, 2023, 1:00:05 PM3/2/23
to
I found further information on my device (ear-buds) in
/var/lib/bluetooth/80:38:FB:D6:A7:62/3C:F8:A8:B9:CE:A1/info:

Name=Hama Freedom Light
Class=0x240404
SupportedTechnologies=BR/EDR;
Trusted=true
Blocked=false
Services=0000110b-0000-1000-8000-00805f9b34fb;0000110c-0000-1000-8000-00805f9b34fb;0000110d-0000-1000-8000-00805f9b34fb;0000110e-0000-1000-8000-00805f9b34fb;0000111e-0000-1000-8000-00805f9b34fb;00001200-0000-1000-8000-00805f9b34fb;

[DeviceID]
Source=1
Vendor=1494
Product=10
Version=576

[LinkKey]
Key=< 32 hex characters long, maybe secret? >
Type=4
PINLength=0

Christopher Schramm

unread,
Mar 4, 2023, 5:30:04 PM3/4/23
to
Hi Alf,

those protocols are completely run by the audio server, which in your
case seems to be PipeWire. blueman does not have any stake in it.

Regards

Alf

unread,
Mar 5, 2023, 12:00:04 PM3/5/23
to
Am 04.03.23 um 23:08 schrieb Christopher Schramm:
> Hi Alf,
>
> those protocols are completely run by the audio server, which in your case seems to be PipeWire. blueman does not have any stake in it.

Hi Christopher,

does that also apply to the creation of these missing nodes as reported back to bluetoothctl after the second connect command?

[Hama Freedom Light]# connect 3C:F8:A8:B9:CE:A1
Attempting to connect to 3C:F8:A8:B9:CE:A1
[NEW] Endpoint /org/bluez/hci0/dev_3C_F8_A8_B9_CE_A1/sep2
[NEW] Endpoint /org/bluez/hci0/dev_3C_F8_A8_B9_CE_A1/sep1
[NEW] Transport /org/bluez/hci0/dev_3C_F8_A8_B9_CE_A1/sep1/fd0
Connection successful
[CHG] Device 3C:F8:A8:B9:CE:A1 ServicesResolved: yes
[CHG] Transport /org/bluez/hci0/dev_3C_F8_A8_B9_CE_A1/sep1/fd0 Volume: 0x0060 (96)

If yes, could you please assign/move this bug to pipewire

Regards, Alf

Christopher Schramm

unread,
Mar 5, 2023, 2:30:05 PM3/5/23
to
>> those protocols are completely run by the audio server, which in your
>> case seems to be PipeWire. blueman does not have any stake in it.
>
> Hi Christopher,
>
> does that also apply to the creation of these missing nodes as reported
> back to bluetoothctl after the second connect command?
>
> [Hama Freedom Light]# connect 3C:F8:A8:B9:CE:A1
> Attempting to connect to 3C:F8:A8:B9:CE:A1
> [NEW] Endpoint /org/bluez/hci0/dev_3C_F8_A8_B9_CE_A1/sep2
> [NEW] Endpoint /org/bluez/hci0/dev_3C_F8_A8_B9_CE_A1/sep1
> [NEW] Transport /org/bluez/hci0/dev_3C_F8_A8_B9_CE_A1/sep1/fd0
> Connection successful
> [CHG] Device 3C:F8:A8:B9:CE:A1 ServicesResolved: yes
> [CHG] Transport /org/bluez/hci0/dev_3C_F8_A8_B9_CE_A1/sep1/fd0 Volume:
> 0x0060 (96)

Yes, those BlueZ endpoints are ultimately provided by the audio server.
0 new messages