unknown state never passing to poweredOn

[X4V1]

Hello,

I recently updated my debian 12 and after the update I'm not able to use my usb bluetooth adapter anymore.
Nothing has changed from code or anything else than the update of some packages.

After some tests I found that the noble.state is returning "unknown" and never changes to "poweredOn".
I checked the bluetooth adapter and it seems ok:

root@ws-api:~# hciconfig -a
hci0:   Type: Primary  Bus: USB
        BD Address: 00:15:83:EC:CC:A1  ACL MTU: 310:10  SCO MTU: 64:8
        UP RUNNING
        RX bytes:1416 acl:0 sco:0 events:97 errors:0
        TX bytes:4913 acl:0 sco:0 commands:97 errors:0
        Features: 0xff 0xff 0x8f 0xfe 0xdb 0xff 0x5b 0x87
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy: RSWITCH HOLD SNIFF PARK
        Link mode: PERIPHERAL ACCEPT
        Name: 'ws-api'
        Class: 0x000000
        Service Classes: Unspecified
        Device Class: Miscellaneous,
        HCI Version: 4.0 (0x6)  Revision: 0x22bb
        LMP Version: 4.0 (0x6)  Subversion: 0x22bb
        Manufacturer: Cambridge Silicon Radio (10)

The status of bluetooth in systemctl is also ok (not giving any warning/error):

root@ws-api:~# systemctl status bluetooth
● bluetooth.service - Bluetooth service
     Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/bluetooth.service.d
             └─experimental.conf
     Active: active (running) since Thu 2024-11-14 16:43:02 CET; 22s ago
       Docs: man:bluetoothd(8)
   Main PID: 1872 (bluetoothd)
     Status: "Running"
      Tasks: 1 (limit: 2308)
     Memory: 892.0K
        CPU: 21ms
     CGroup: /system.slice/bluetooth.service
             └─1872 /usr/libexec/bluetooth/bluetoothd --experimental

Nov 14 16:43:02 ws-api systemd[1]: Starting bluetooth.service - Bluetooth service...
Nov 14 16:43:02 ws-api bluetoothd[1872]: Bluetooth daemon 5.66
Nov 14 16:43:02 ws-api systemd[1]: Started bluetooth.service - Bluetooth service.
Nov 14 16:43:02 ws-api bluetoothd[1872]: Starting SDP server
Nov 14 16:43:02 ws-api bluetoothd[1872]: Bluetooth management interface 1.22 initialized
Nov 14 16:43:02 ws-api bluetoothd[1872]: Battery Provider Manager created
Nov 14 16:43:02 ws-api bluetoothd[1872]: Adv Monitor Manager created with supported features:0x00000000, enabled features:0x00000000, max number of supported monitors:32, max number of supported patterns:16

I don't see anything weird in the journal neither:

root@ws-api:~# journalctl -xe | grep bluetooth
Nov 14 16:44:42 ws-api systemd[1]: Starting bluetooth.service - Bluetooth service...
░░ Subject: A start job for unit bluetooth.service has begun execution
░░ A start job for unit bluetooth.service has begun execution.
Nov 14 16:44:42 ws-api bluetoothd[389]: Bluetooth daemon 5.66
Nov 14 16:44:42 ws-api bluetoothd[389]: Starting SDP server
Nov 14 16:44:42 ws-api systemd[1]: Started bluetooth.service - Bluetooth service.
░░ Subject: A start job for unit bluetooth.service has finished successfully
░░ A start job for unit bluetooth.service has finished successfully.
Nov 14 16:44:42 ws-api systemd[1]: Reached target bluetooth.target - Bluetooth Support.
░░ Subject: A start job for unit bluetooth.target has finished successfully
░░ A start job for unit bluetooth.target has finished successfully.
Nov 14 16:44:42 ws-api bluetoothd[389]: Bluetooth management interface 1.22 initialized
Nov 14 16:44:42 ws-api bluetoothd[389]: Battery Provider Manager created
Nov 14 16:44:42 ws-api dbus-daemon[390]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.4' (uid=0 pid=389 comm="/usr/libexec/bluetooth/bluetoothd --experimental")
Nov 14 16:44:42 ws-api bluetoothd[389]: Adv Monitor Manager created with supported features:0x00000000, enabled features:0x00000000, max number of supported monitors:32, max number of supported patterns:16

And from bluetoothctl I can connect to device using command line so I don't think the problem is coming from the adapter or the operating system configuration.

I'm running out of idea and I'm don't know what I can do next to investigate further. Any idea ?

I also found this opened issue #341 but I'm not sure if it is related to my problem.

Any help would be reallly appreciated.

UPDATE 1:
If I add the DEBUG env variable I can see an error from HCI:

hci onSocketError: EINVAL, Invalid argument +1ms

I'm now investigating what this error could be.

UPDATE 2:
After some search with the error from UPDATE 1 I found another issue reported in node-bluetooth-hci-socket: abandonware/node-bluetooth-hci-socket#60
It's apparently fixed in another repository but according to another user it's not stable (nathankellenicki/node-poweredup#189)

UPDATE 3:
On my Debian 12 the kernel "6.1.0-26-amd64" seems to be the latest working one. Starting from "6.1.0-27-amd64" it returns an unknown state and never pass to poweredOn.
Downgrading the kernel from "6.1.0-27-amd64" to "6.1.0-26-amd64" solved the problem for me. It's not a solution but at least I can have my bluetooth adapter working until we find a real solution.

UPDATE 4 (with solution):
As mentionned in 'update 2' the problem was coming from node-bluetooth-hci-socket.
A fix has been merged now (abandonware/node-bluetooth-hci-socket#61).
As "node-bluetooth-hci-socket" is an optional dependency of noble, we can simply update that package without having to change anything in noble.
I just tested and it works fine with the latest kernel (6.1.0-28-amd64).
The only thing is that node-bluetooth-hci-socket is not having the fix in the latest version publish in the npm registry so I had to install the fix manually pointing to the github repository instead (npm i https://github.com/abandonware/node-bluetooth-hci-socket )

[jamesdrake101]

This problem made my Raspbian Homebridge setup completely useless. I downgraded the kernel, thanks @X4V1 for giving me this lead.

[mman]

Seeing this as well on my Raspberry Pi, downgrading to 6.6.51+rpt-rpi-v8 makes it work again.

[X4V1]

It's now fixed (explained in the update 4). Closing this issue.