peripheral_hids_keyboard only works with some hosts

[mlac]

Hi there,

I'm running the peripheral_hids_keyboard sample of the nRF Connect SDK 2.5.1 on my nRF52840-DK. After pushing button 4, advertising starts as expected, but I can only connect with some of my phones/tablets.

I can connect with:
- OnePlus 9 Pro phone running Android 13
- Huawei P20 Pro running Android 10

I can't connect with:
- MacBook Air running macOS Ventura 13.6.3 - After pressing the Connect button, a progress indicator shortly appears and then disappears.
- Huawei MediaPad M5 lite 10 tablet running Android 8.0.0 - Upon trying to pair, I get the "Pairing failed. Incorrect pairing key or the device you want to pair with is configured incorrectly" message.
- NPad-Pro tablet running Android 12 - "Pairing..." momentarily appears, then disappears.

The sample doesn't show up in the Bluetooth devices list:
- ThinkPad T520 running Windows 20 Pro 22H2

Can you reproduce such discrepancies across various hosts, and can you make them connect?

[Hung Bui]

Hi Mlac, 

Do you have any modification to the sample ? Do you use any filter accept list  ? 

Do you see any log on the NRF52 when you try to pair from those it can not connect ? 

I would suggest to try capture a sniffer trace so that we can inspect further. 

[mlac]

Hi Hung,

- As it turns out, the NPad-Pro tablet is a piece of crap that doesn't pair with any keyboard. :)
- The ThinkPad T520 doesn't list other BLE keyboards either. I think it has a Bluetooth classic module that doesn't support BLE.
- The Huawei MediaPad M5 lite 10 tablet actually works with the peripheral_hids_keyboard sample. I'm unsure why it didn't work the last time.

This leaves us with the MacBook Air running macOS Ventura 13.6.3. When trying to connect, I can see the following in the console:

Connected 10:B5:88:72:9A:E6 (public)
W: Ignoring data for unknown channel ID 0x003a
Disconnected from 10:B5:88:72:9A:E6 (public) (reason 19)

Does the above ring a bell? (I've installed the sniffer, but filtering the device seems a bit tricky. I can try to capture a trace if still needed.)

Thanks for everything!

[Hung Bui]

Hi Mlac, 

Regarding the trace between mouse and MAC, it doesn't seem they do pairing. Could you please test again and make sure the sniffer follows the mouse ? 
The log say "Unable to get keys for", it either returned by bt_keys_get_addr()  or bt_keys_get_type(). In both case it's related to that an old key can not be retracted or it can not create a new slot for the key. 
Have you made sure you erased the whole flash before testing ? I am under the impression that it reached the maximum number of device can be paired. 

Another option is to enable CONFIG_BT_KEYS_OVERWRITE_OLDEST so that it will overwrite the old key. 

If that doesn't help, could you add a breakpoint in the code where "Unable to get keys" is printed out in smp.c (there are 10 locations). We need to know which exact function causing the issue. 

[mlac]

Hi Hung,

I remembered that in a similarly strange but different situation when I upgraded my application to MCUboot, and it kept crashing shortly after boot, I used the `nrfjprog --recover` command successfully, and I tried it again for this issue, and it solved the problem for the keyboard sample.

How did `nrfjprog --recover` fix the issue? I'm starting to get dependent on this command without understanding what's happening in the background.

As for the mouse, now it pairs, but when I press the buttons, the mouse pointer doesn't move on the Mac, so I'm attaching the updated log and capture:

mouse-mac-2.pcapng

Fullscreen mouse-mac-2.txt Download

D: conn 0x20001d08 handle 0
D: chan 0x200020b4 cid 0x0006
I: BAS Notifications enabled
Connected 10:B5:88:72:9A:E6 (public)
Regular advertising started
W: Ignoring data for unknown channel ID 0x003a
button_changed(): right
button_changed(): left
button_changed(): up
button_changed(): down
button_changed(): right
button_changed(): right
button_changed(): right
button_changed(): left
button_changed(): left
button_changed(): left
button_changed(): left
button_changed(): up
button_changed(): up
button_changed(): up
button_changed(): up
button_changed(): up
button_changed(): down
button_changed(): down
button_changed(): down
button_changed(): down

[Hung Bui]

Hi mlac, 

When you do "nrfjprog --recover" the whole flash memory of the chip will be erased. If you simply erase and flash the new code without a full erase, the settings partition will retain, meaning all the bond in your test will still be in the flash. It could be the reason why you can't pair the MAC device because it exceed the maximum of pair information in the setting partition. 

From what I can see in the sniffer trace, the mouse did send the notification to the MAC. So there must be an issue interpreting the data on MAC that doesn't result in the mouse movement. 

One thing I noticed is that there were no pairing/bonding with the mouse. Could you check why ? It could be reason the MAC doesn't show mouse movement. 
 I assume the mouse works fine on other machine, correct ? 

Could you try using the nRF Desktop application ? It can also emulate a desktop mouse on a DK. 
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/applications/nrf_desktop/README.html#

[mlac]

Thanks for explaining what `nrfjprog --recover` does, Hung. It makes sense.

The nrf_desktop sample did work. I can connect it to my Mac, and the mouse pointer moves when pressing the buttons.

The peripheral_hids_mouse sample still doesn't work, even if I run `nrfjprog --recover` before flashing it, and my Mac doesn't remember any pairing information from before because when it does, it always offers to forget it for the device.

Would you be able to test peripheral_hids_mouse on a Mac? I use a MacBook Air M1, 2020 running macOS Ventura 13.6.3, but any new Mac with an M chip should work.

[Hung Bui]

Hi Mlac, 
I'm not so familiar with MAC device, but I did a test on a Macbook Air here and saw the same issue. 
Doesn't seem pairing is occurring. I will need to check internally here to see why. 
My suggestion in the mean time is to take a look at the nRF Desktop and check why it works with nRF Desktop but not the BLE mouse sample.

[mlac]

Thanks for confirming this bug, Hung. I will work on other parts of my project until this gets fixed.

I keep this conversation unresolved until the issue gets fixed.

[Hung Bui]

Hi mlac, 
Could you try testing the peripheral_hids_mouse again , this time with 

CONFIG_BT_HIDS_DEFAULT_PERM_RW_ENCRYPT=y 

It seems to work for me. 

[mlac]

Hi Hung,

The CONFIG_BT_HIDS_DEFAULT_PERM_RW_ENCRYPT option is enabled by default in the prj.conf of the peripheral_hids_mouse peripheral_hids_mouse sample, so I don't understand what has changed.

You wrote earlier that you could also reproduce this issue. I assume you haven't changed the CONFIG_BT_HIDS_DEFAULT_PERM_RW_ENCRYPT=y option either when testing the peripheral_hids_mouse sample.

[Hung Bui]

Hi mlac, 

Could you clarify how you find CONFIG_BT_HIDS_DEFAULT_PERM_RW_ENCRYPT enabled by default ? 
Please check the code: https://github.com/nrfconnect/sdk-nrf/blob/v2.5.1/samples/bluetooth/peripheral_hids_mouse/prj.conf

As you can find in the trace you provided, the link with the Macbook was not encrypted. 

 

[mlac]

Sorry, I was wrong about CONFIG_BT_HIDS_DEFAULT_PERM_RW_ENCRYPT; It's not enabled by default, indeed. The sample works on my Mac when this option is enabled.

Will you add CONFIG_BT_HIDS_DEFAULT_PERM_RW_ENCRYPT=y to the prj.conf of this sample so that others won't encounter this issue?