Bluetooth Devices will not pair on Pop_OS! 20.04 LTS using KDE Plasma 5.18.5

cordx · 08-01-2020, 04:43 AM

Quote:

Originally Posted by cordx

there is also an option to "remove" the device, but i have never used it so i stop short of suggesting you try that.

i am revising my suggestion a little since i had the time to run some tests and now think removing the headphones would also probably be helpful.

what i noticed with my bluetooth speaker was that since i had previously trusted it, just turning it on was enough to create a directory similar to the one referenced in your logs (as well as connect it):
/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0/bluetooth/hci0/hci0:12

when my speaker was powered off or removed through bluetoothctl or blueman, there was no directory inside of /hci0 named anything like /hci0:X.

hopefully untrusting, disconnecting and removing the headphones will remove that directory and give you a fresh start. you could even check on your system before you power on the headphones in
/sys/devices/pci0000:00/0000:00:01.3/0000:01:00.0/usb1/1-9/1-9:1.0/bluetooth/hci0

if you have journalctl -f running when you power the bluetooth on, you should be able to verify that path. mine looked like this in the log:

Quote:

Aug 01 02:06:03 <hostname> upowerd[3770]: unhandled action 'bind' on /sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.4/1-1.4:1.0
Aug 01 02:06:03 <hostname> kernel: Bluetooth: hci0: BCM: chip id 63

ALazyDope · 08-01-2020, 11:36 AM

To answer your first question about losing power while they were connected: I have tried this on ALL my bluetooth devices and none of them work, and I have NEVER had these headphones properly paired before.

Second, when running remove on the headphones, this appearss in journalctl

Code:

Aug 01 12:20:59 Byron-GPC kernel: debugfs: File 'le_min_key_size' in directory 'hci0' already present!
Aug 01 12:20:59 Byron-GPC kernel: debugfs: File 'le_max_key_size' in directory 'hci0' already present!

When I use Blueman to search, the search never finishes, and I can't disable scan in bluetoothctl as it just returns the error

Code:

Failed to stop discovery: org.bluez.Error.Failed

And journalctl has this to say while the scan is ongoing

Code:

Aug 01 12:13:48 Byron-GPC /usr/lib/gdm3/gdm-x-session[14163]: Traceback (most recent call last):
Aug 01 12:13:48 Byron-GPC /usr/lib/gdm3/gdm-x-session[14163]:   File "/usr/lib/python3/dist-packages/blueman/bluez/Base.py", line 81, in callback
Aug 01 12:13:48 Byron-GPC /usr/lib/gdm3/gdm-x-session[14163]:     value = proxy.call_finish(result).unpack()
Aug 01 12:13:48 Byron-GPC /usr/lib/gdm3/gdm-x-session[14163]: gi.repository.GLib.Error: g-io-error-quark: GDBus.Error:org.bluez.Error.InProgress: Operation already in progress (36)
Aug 01 12:13:48 Byron-GPC /usr/lib/gdm3/gdm-x-session[14163]: During handling of the above exception, another exception occurred:
Aug 01 12:13:48 Byron-GPC /usr/lib/gdm3/gdm-x-session[14163]: Traceback (most recent call last):
Aug 01 12:13:48 Byron-GPC /usr/lib/gdm3/gdm-x-session[14163]:   File "/usr/lib/python3/dist-packages/blueman/bluez/Base.py", line 90, in callback
Aug 01 12:13:48 Byron-GPC /usr/lib/gdm3/gdm-x-session[14163]:     raise parse_dbus_error(e)
Aug 01 12:13:48 Byron-GPC /usr/lib/gdm3/gdm-x-session[14163]: blueman.bluez.errors.DBusInProgressError:  Operation already in progress

Powering off the controller however was able to overrule this however

After rebooting and powering on the bluetooth controller, there was something different in show

Code:

Controller 48:F1:7F:8E:9E:A9 (public)
        Name: Byron-GPC
        Alias: Byron-GPC
        Class: 0x001c0104
        Powered: yes
        Discoverable: yes
        DiscoverableTimeout: 0x00000000
        Pairable: yes
        UUID: A/V Remote Control        (0000110e-0000-1000-8000-00805f9b34fb)
        UUID: Audio Source              (0000110a-0000-1000-8000-00805f9b34fb)
        UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)
        UUID: Headset AG                (00001112-0000-1000-8000-00805f9b34fb)
        UUID: Headset                   (00001108-0000-1000-8000-00805f9b34fb)
        UUID: IrMC Sync                 (00001104-0000-1000-8000-00805f9b34fb)
        UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
        UUID: Audio Sink                (0000110b-0000-1000-8000-00805f9b34fb)
        UUID: Vendor specific           (00005005-0000-1000-8000-0002ee000001)
        Modalias: usb:v1D6Bp0246d0535
        Discovering: no

The class on the controller changed from 0x00000000 to 0x001c0104

and when attempting to pair again...

Code:

[bluetooth]# pair 38:18:4C:03:54:A3
Attempting to pair with 38:18:4C:03:54:A3
[CHG] Device 38:18:4C:03:54:A3 Connected: yes
[WH-XB900N]# info 38:18:4C:03:54:A3
Device 38:18:4C:03:54:A3 (public)
        Name: WH-XB900N
        Alias: WH-XB900N
        Class: 0x00240404
        Icon: audio-card
        Paired: no
        Trusted: no
        Blocked: no
        Connected: yes
        LegacyPairing: no
        UUID: Handsfree                 (0000111e-0000-1000-8000-00805f9b34fb)
        UUID: Headset                   (00001108-0000-1000-8000-00805f9b34fb)
        UUID: Audio Sink                (0000110b-0000-1000-8000-00805f9b34fb)
        UUID: Advanced Audio Distribu.. (0000110d-0000-1000-8000-00805f9b34fb)
        UUID: A/V Remote Control        (0000110e-0000-1000-8000-00805f9b34fb)
        UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
        UUID: Headset HS                (00001131-0000-1000-8000-00805f9b34fb)
        UUID: A/V Remote Control Cont.. (0000110f-0000-1000-8000-00805f9b34fb)
        UUID: Vendor specific           (00000000-deca-fade-deca-deafdecacaff)
        Modalias: usb:v054Cp0CDCd0452
        RSSI: -41
        TxPower: 4

connected yes, paired no, no audio, no connection on the device's end, only the computer's

VERY long after attempting to pair, I get this error

Code:

Failed to pair: org.freedesktop.DBus.Error.NoReply

And absolutely nothing in journalctl

ALazyDope · 08-01-2020, 11:45 AM

Also I didn't see your update before posting, to add to what you suggested, hci0 does not have any hci0:X folders in it after removing the devices, and also, when powering on the bluetooth device, I could not find anything in journalctl that looked like what you showed, and as stated before, it still was not working regardless

cordx · 08-01-2020, 12:30 PM

Quote:

Originally Posted by ALazyDope

I have tried this on ALL my bluetooth devices and none of them work, and I have NEVER had these headphones properly paired before.

that makes this sound more like bluez issue than something to do with the headset. can you run?

Code:

pactl list modules | grep blue

these are the three i have running:

Quote:

Name: module-bluetooth-policy
Name: module-bluetooth-discover
Name: module-bluez5-discover

ALazyDope · 08-01-2020, 01:54 PM

All three of those modules are running

ALazyDope · 08-01-2020, 02:00 PM

So when use a bluetooth controller instead of the headset, it pairs and connects on the computer's end, but the device itself does not connect

Code:

[Xbox Wireless Controller]# info
Device 5C:BA:37:E1:29:E7 (public)
        Name: Xbox Wireless Controller
        Alias: Xbox Wireless Controller
        Class: 0x00000508
        Icon: input-gaming
        Paired: yes
        Trusted: no
        Blocked: no
        Connected: yes
        LegacyPairing: no

Controller is an Xbox One BT Wireless Controller, has worked and paired previously, but also does not connect properly now, as the light on the controller goes solid coloured if it pairs, but instead it also powers off due to inactivity, so clearly it's not actually connected.

Also this error appears in journalctl

Code:

Aug 01 15:00:51 Byron-GPC bluetoothd[1472]: 5C:BA:37:E1:29:E7: error updating services: Connection timed out (110)

A note to make is that the headset was never paired but the controller was

ALazyDope · 08-01-2020, 02:21 PM

Another thing I found out while digging through this is that hci0 has folders within it that loop backwards on itself, and I wasn't sure is that is supposed to be like that

Code:

alazydope@Byron-GPC:/sys/devices/pci0000:00/0000:00:01.3/0000:01:00.0/usb1/1-9/1-9:1.0$ ls
authorized         bInterfaceProtocol  driver  modalias              uevent
bAlternateSetting  bInterfaceSubClass  ep_02   power
bInterfaceClass    bluetooth           ep_81   subsystem
bInterfaceNumber   bNumEndpoints       ep_82   supports_autosuspend
alazydope@Byron-GPC:/sys/devices/pci0000:00/0000:00:01.3/0000:01:00.0/usb1/1-9/1-9:1.0$ cd bluetooth/hci0/
alazydope@Byron-GPC:/sys/devices/pci0000:00/0000:00:01.3/0000:01:00.0/usb1/1-9/1-9:1.0/bluetooth/hci0$ ls
device  power  rfkill0  subsystem  uevent
alazydope@Byron-GPC:/sys/devices/pci0000:00/0000:00:01.3/0000:01:00.0/usb1/1-9/1-9:1.0/bluetooth/hci0$ cd device
alazydope@Byron-GPC:/sys/devices/pci0000:00/0000:00:01.3/0000:01:00.0/usb1/1-9/1-9:1.0/bluetooth/hci0/device$ ls
authorized         bInterfaceProtocol  driver  modalias              uevent
bAlternateSetting  bInterfaceSubClass  ep_02   power
bInterfaceClass    bluetooth           ep_81   subsystem
bInterfaceNumber   bNumEndpoints       ep_82   supports_autosuspend

I'm still rather new to linux and I don't know exactly how all the devices and systems are organized yet

I also found a file named +bluetooth:hci0 in /run/udev/data/ and it contained some data, including an alias that didn't lead anywhere

Code:

I:7045470
E:SYSTEMD_ALIAS=/sys/subsystem/bluetooth/devices/hci0
E:SYSTEMD_WANTS=bluetooth.target
E:SYSTEMD_USER_WANTS=bluetooth.target
G:systemd

cordx · 08-02-2020, 09:00 AM

Quote:

Originally Posted by ALazyDope

To answer your first question about losing power while they were connected: I have tried this on ALL my bluetooth devices and none of them work, and I have NEVER had these headphones properly paired before.

i took that to mean nothing had ever worked with bluetooth on this particular system, but this

Quote:

Originally Posted by ALazyDope

A note to make is that the headset was never paired but the controller was

seems to indicate otherwise.

to clarify: has the headset every worked on this or any other system with bluetooth?

you say that the controller was previously paired. again, to clarify: are you saying it was previously paired on this particular system, but now will not do so? does that controller work on any other system?

do you have any device that will pair and work with bluetooth on this system at present? more generally (outside of the xbox controller and headset), has any bluetooth device worked on this system?

if any device worked previously but will not do so now now, have there been any recent system changes like updates or upgrades? if so, do you have a backup you can use to roll back to when things were working?

ALazyDope · 08-02-2020, 06:36 PM

Yes, bluetooth has previously worked on this system but then stopped working, the headset has never been paired, but pairs with other devices. The controller had been paired and worked before the issue, but now also does not work, but also still works with other devices, I have also tried a pair of earbuds that had also been paired before this issue but with no success either.

Sorry if my wording was confusing, yes other devices have worked before but none do any more, and new devices won't pair either.

cordx · 08-02-2020, 07:03 PM

no worries and definitely no need to apologize. it can be hard to figure out what to include and what to leave out. your inclusion of logs and terminal output has been helpful.

the part about things previously working that no longer do seems to be the bigger part of what is going on since nothing will work now. the easiest route would be if you had a backup that you could use to revert to a time when at least some things were pairing. any chance one of those exists?

ALazyDope · 08-03-2020, 01:26 AM

No I don't have a backup because I wasn't changing anything related to bluetooth when this happened, or at least I didn't believe so

cordx · 08-03-2020, 06:51 AM

that is understandable. i started making system backups before every update when a change in my desktop environment wiped out my printer and i had to spend a couple of hours trying to figure out the right configuration. they are pretty quick and easy with timeshift and i can delete them just as quickly and easily if i don't have any issues after a week or so.

that's not meant as an admonishment. just sharing why i changed my habits after a somewhat similar situation.

since nothing is pairing and you say you aren't seeing anything that looks helpful or useful when journalctl -f is running, my suggestion is to use dmesg to look at when your bluetooth adapter initializes to see if there are any noticeable error or warning messages.

Code:

dmesg -H | egrep -i 'hci0|bluetooth'

jamesostin · 08-03-2020, 07:38 AM

It is strange, I have never faced with this problem

ALazyDope · 08-03-2020, 09:20 AM

dmesg output

Code:

~$ dmesg -H | egrep -i 'hci0|bluetooth'
[  +0.002902] Bluetooth: Core ver 2.22
[  +0.000000] Bluetooth: HCI device and connection manager initialized
[  +0.000003] Bluetooth: HCI socket layer initialized
[  +0.000001] Bluetooth: L2CAP socket layer initialized
[  +0.000003] Bluetooth: SCO socket layer initialized
[  +0.001695] Bluetooth: hci0: read Intel version: 370810225019140f34
[  +0.000001] Bluetooth: hci0: Intel device is already patched. patch num: 34
[  +0.000272] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[  +0.000001] Bluetooth: BNEP filters: protocol multicast
[  +0.000003] Bluetooth: BNEP socket layer initialized
[Aug 3 10:19] Bluetooth: RFCOMM TTY layer initialized
[  +0.000005] Bluetooth: RFCOMM socket layer initialized
[  +0.000004] Bluetooth: RFCOMM ver 1.11

Will definitely also look into timeshift to avoid future issues

cordx · 08-03-2020, 09:54 AM

yours looks fairly identical to my own except the part where my system complains about the firmware not loading, but still manages to somehow work anyways.

have you considered the possibility of a re-install? or at the very least creating a live usb and booting into it to see if it might work better with your devices?

it's rarely my first suggestion to start all over. i think there's plenty to learn from trying to correct something that might be slightly off, but in a case like this where nothing pairs anymore and journalctl -f doesn't seem to show anything too major when you try and pair i thought i would at least suggest the live usb option to see if that might be something you hadn't thought of and would be willing to try.