Hi Ellie, On Wed, Sep 11, 2024 at 6:28 PM Ellie <el@xxxxxxxxxxx> wrote: > > Hi everyone, > > My apologies if this is the wrong place to send this question to. But my > question is, what do I do if a bluetooth keyboard no longer shows the > pairing passkey code on pair? The model is a "Royal Kludge RK61-US" > keyboard. It used to show the pairing code and then pair fine. I ested > this with two different bluetooth controllers on two different Linux > machines of mine. It used to show a passkey and now it doesn't? > But since I moved to a different distribution with different bluetooth > tools and kernel versions, now kernel 6.10.8 with > bluetoothctl/bluetoothd 5.77, it no longer shows the pairing code and > bluetoothctl just thinks it pairs without showing a passkey. And during > that, the keyboard itself keeps flashing in pairing mode and won't > finish pairing like the Linux side seems to think it did, and I'm > guessing it's waiting for the code which never seems to show up in > bluetoothctl: > > [bluetooth]# scan on > [bluetooth]# SetDiscoveryFilter success > [bluetooth]# Discovery started > [bluetooth]# [CHG] Controller 70:D8:C2:14:8B:23 Discovering: yes > [bluetooth]# [NEW] Device C5:F9:E9:90:F6:8A RK61-5.0 > [bluetooth]# pair C5:F9:E9:90:F6:8A > [bluetooC5:F9:E9:90:F6:8A9:E9:90:F6:8A > Attempting to connect to C5:F9:E9:90:F6:8A > [bluetooth]# [CHG] Device C5:F9:E9:90:F6:8A WakeAllowed: yes > [blueC5:F9:E9:90:F6:8A9:E9:90:F6:8A > Attempting to pair with C5:F9:E9:90:F6:8A > [CHG] Device C5:F9:E9:90:F6:8A Connected: yes > [RK61-5.0]# Connection successful > [RK61-5.0]# [CHG] Device C5:F9:E9:90:F6:8A Bonded: yes > [RK61-5.0]# [NEW] Primary Service (Handle 0x0000) > /org/bluez/hci0/dev_C5_F9_E9_90_F6_8A/service000a > 0000180a-0000-1000-8000-00805f9b34fb > Device Information > [RK61-5.0]# [NEW] Characteristic (Handle 0x0000) > /org/bluez/hci0/dev_C5_F9_E9_90_F6_8A/service000a/char000b > 00002a29-0000-1000-8000-00805f9b34fb > Manufacturer Name String > [RK61-5.0]# [NEW] Characteristic (Handle 0x0000) > /org/bluez/hci0/dev_C5_F9_E9_90_F6_8A/service000a/char000d > 00002a28-0000-1000-8000-00805f9b34fb > Software Revision String > [RK61-5.0]# [NEW] Characteristic (Handle 0x0000) > /org/bluez/hci0/dev_C5_F9_E9_90_F6_8A/service000a/char000f > 00002a50-0000-1000-8000-00805f9b34fb > PnP ID > [RK61-5.0]# [NEW] Primary Service (Handle 0x0000) > /org/bluez/hci0/dev_C5_F9_E9_90_F6_8A/service0011 > 0000180f-0000-1000-8000-00805f9b34fb > Battery Service > [RK61-5.0]# [NEW] Characteristic (Handle 0x0000) > /org/bluez/hci0/dev_C5_F9_E9_90_F6_8A/service0011/char0012 > 00002a19-0000-1000-8000-00805f9b34fb > Battery Level > [RK61-5.0]# [NEW] Descriptor (Handle 0x0000) > /org/bluez/hci0/dev_C5_F9_E9_90_F6_8A/service0011/char0012/desc0014 > 00002902-0000-1000-8000-00805f9b34fb > Client Characteristic Configuration > [RK61-5.0]# [CHG] Device C5:F9:E9:90:F6:8A UUIDs: > 00001800-0000-1000-8000-00805f9b34fb > [RK61-5.0]# [CHG] Device C5:F9:E9:90:F6:8A UUIDs: > 0000180a-0000-1000-8000-00805f9b34fb > [RK61-5.0]# [CHG] Device C5:F9:E9:90:F6:8A UUIDs: > 0000180f-0000-1000-8000-00805f9b34fb > [RK61-5.0]# [CHG] Device C5:F9:E9:90:F6:8A UUIDs: > 00001812-0000-1000-8000-00805f9b34fb > [RK61-5.0]# [CHG] Device C5:F9:E9:90:F6:8A ServicesResolved: yes > [RK61-5.0]# [CHG] Device C5:F9:E9:90:F6:8A Paired: yes > [RK61-5.0]# [CHG] Device C5:F9:E9:90:F6:8A Modalias: usb:v000Ep3412d6701 It shows as paired above, I wonder if it is using JustWork pairing method but it sounds really weird if before it used a passkey. > Is this some sort of regression maybe, or am I supposed to try some > special option? Am I supposed to do something with some active probe > command in bluetoothctl to get the passkey code to show? My apologies > for these beginner questions, but from all I could find online it seems > like the code is meant to show up during above process but it doesn't. We probably need the btmon traces to check if the passkey method is really being used, maybe something else is at play like some other pairing agent with different IO capabilities. > I already tried the different controller modes "dual", "bredr", "le", > and it seems like it's an "le" type device since with "bredr" it doesn't > show up. Other than that, the modes didn't seem to make a difference. > > Sadly, I didn't write down the exact software versions of kernel etc. > that I previously used when everything worked. :-| > > Regards, > > Ellie > -- Luiz Augusto von Dentz