BLE pairing issues with Lenovo X240

[ohtap]

Hi,

We have a BLE peripheral device that is used as a mouse/keyboard (nRF52832 SDK 14.0)

The peripheral pairs with most central devices just fine (including Mac and PC), except it seems with some models of Lenovo laptops.

When attempting to pair with the X240 model (Windows 10) , we get "Driver error" on the Bluetooth menu. Pairing with an example Nordic keyboard seems to work fine. The problem is reproduced with different 53832 boards.

Sniffing yields the results in the attached file.

We tried updating the drivers and disabling/enabling the Bluetooth device (via Device Manager) but it only fixes the issue once every few dozen attempts. When it actually manages to pair, it works just fine, but getting there is a problem. The "fix" itself is also temporary and has to be done again if the device is unpaired.

We're not sure if it's an issue with our app or some issues with the drivers. Would appreciate help.

Thanks.

Pairing with x240.pcapng

[Susheel Nuguru]

Hi there,

It is really hard to say what went wrong with the information provided. Have you tried taking a sniffer log and see of few phones are doing something differently in air which is not compatible with the BLE spec. If you attach a sniffer log when trying to pair with Lenovo (or devices that does not pair), then we will try to narrow it down.

[gkovelman_tap]

htc_m9_pairing_1.pcapng

lenovo_x240_pairing_2.pcapng

The attached session in the opening question is of a failed connection with the Lenovo.

I'm attaching two more sessions. Sorry for not trimming them.

One, where the connection succeeds, is with an HTC M9 phone. Connection is from time index 1284.
Second, where the connection fails, is with the same lenovo laptop. Connection is from time index 8766.

I'm seeing these differences:

• Bonding: Lenovo is's Initiator Key(s) list is only CSRK and HTC's is LTK, IRK, CSRK, Linkkey and slave is responding with none
• MTU: Lenovo is not accepting MTU exchange request from the slave but initiating it's own (with MTU 525).
• Termination: the Lenovo sent LL_TERMINATE_ID after service discovery, before reading encrypted characteristics.

[gkovelman_tap]

Also, this issue is reproducible with example HID projects when increasing the ATT MTU to higher than 23.

Further checking that with reducing ATT MTU to 23, the above Lenovo is able to pair successfully with our device.
Was this experienced ever? Could the SoftDevice be exchanging MTU incorrectly?

We need the higher MTU for part of our application.

[Kenneth]

Hi, Looking at the logs I can't find anything showing that the softdevice doesn't behave as expected.From your description it seems to be an issue with the internal state machine of the driver/link layer in the Lenovo in this case. My recommendation is to  delay the MTU exchange request initiated by the peripheral (for instance add a 5second delay after connection is established before requesting an MTU exchange, in case it has not yet been updated.) Or instead of a fixed delay, you may trigger the MTU exchange after notifications (cccd) handles have been executed. In general I have seen a few issues using long MTU, they have been caused by central device does not always properly handle an MTU exchange shortly after connection established.

[gkovelman_tap]

Thanks.

Any recommend way to postpone the MTU exchange?
I don't want to break the SDK's internal state machine, which I'm guessing that exists and depends on MTU exchange triggering.

We're using S132, SDK 14.0.