For what it's worth, the issue is still present in kernel 6.12.4. All my
machines that updated their kernels can now no longer pair this
keyboard. The keyboard shows up as "Paired Yes" but "Trusted No", and no
pass key is prompted and it can't be used.
I haven't gotten around to some bluetooth debug log yet since I'm often
in sensitive environments where I'm not comfortable logging surrounding
devices.
Regards,
Ellie
On 9/12/24 3:23 AM, Luiz Augusto von Dentz wrote:
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
