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

Bug#1027684: blueman: no legacy pairing with BT-Speaker

32 views
Skip to first unread message

Michael Schmitt

unread,
Jan 1, 2023, 3:40:03 PM1/1/23
to
Package: blueman
Version: 2.1.4-1+b1
Severity: normal
X-Debbugs-Cc: ms....@web.de

Dear Maintainer,

* What led up to the situation?

Try to pair BT-Speaker from Marshall => fails to pair
Try to pair other 'nameless' BT-Speaker => pairing success

Only difference in info: BT-Speaker from Marshall has lagacy pairing: yes

BTW: Same problem on debian testing...


* What exactly did you do (or not do) that was effective (or ineffective)?

I switched to cmd-line:

bluetoothctl
pairable on
scan on
pair xx:xx:xx (ID of BT Speaker Marshall)


* What was the outcome of this action?

I get a 'request pin code'
[agent] Enter PIN code:

Now enter 0000, the RETURN, and pairing works on command line. paired device is available in blueman and may be used.

* What outcome did you expect instead? (while using blueman)
There appears no dialog / request from blueman to enter pin for legacy pairing. Only 'pairing failed for: xx:xx:xx' is displayed
(Deb 11 with LXDE, same with XFCE)

So in this situation pairing of Marshall BT-Speaker only works on cmd-line.




-- System Information:
Debian Release: 11.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-0.deb11.6-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: 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 3.38.0-1
ii bluez 5.55-3.1
ii bluez-obexd 5.55-3.1
ii dbus 1.12.24-0+deb11u1
ii dbus-user-session [default-dbus-session-bus] 1.12.24-0+deb11u1
ii dconf-gsettings-backend [gsettings-backend] 0.38.0-2
ii gir1.2-ayatanaappindicator3-0.1 0.5.5-2+deb11u2
ii gir1.2-gdkpixbuf-2.0 2.42.2+dfsg-1+deb11u1
ii gir1.2-glib-2.0 1.66.1-1+b1
ii gir1.2-gtk-3.0 3.24.24-4+deb11u2
ii gir1.2-nm-1.0 1.30.6-1+deb11u1
ii gir1.2-pango-1.0 1.46.2-3
ii gnome-icon-theme 3.12.0-3
ii libbluetooth3 5.55-3.1
ii libc6 2.31-13+deb11u5
ii libglib2.0-0 2.66.8-1
ii libpulse-mainloop-glib0 14.2-2
ii librsvg2-common 2.50.3+dfsg-1
ii mate-icon-theme 1.24.0-1
ii notification-daemon 3.20.0-4
ii policykit-1 0.105-31+deb11u1
ii python3 3.9.2-3
ii python3-cairo 1.16.2-4+b2
ii python3-gi 3.38.0-2
ii python3-gi-cairo 3.38.0-2

Versions of packages blueman recommends:
ii pulseaudio-module-bluetooth 14.2-2

blueman suggests no packages.

-- no debconf information

Christopher Schramm

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

sorry for the late reply.

Unfortunately blueman 2.1 has a buggy PIN database built-in that
probably leads to a random 4-digit PIN getting provided in this case
instead of the 0000 that the device expects.

However, the database is not part of blueman 2.3 anymore, so I would
expect the PIN code request to show up in testing. In case it does not,
please see
https://github.com/blueman-project/blueman/wiki/Troubleshooting#debugging-blueman
on debug logging and check what you get with it when trying to pair the
device.

Cheers

Michael Schmitt

unread,
Mar 11, 2023, 11:20:04 AM3/11/23
to
Dear Christopher,

sorry for the late reply too :-)

I set up a VM with debian testing an it works like you described. The
pin code request shows up (blueman version 2.3.5-2+b1) and pairing works
like a charm.

So the problem should be fixed in next stable release....

Thanks for your reply.

Cheers
0 new messages