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]

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.

[Susheel Nuguru]

we can do a small workaround without breaking the state machine of the SDK

in nrf_ble_gatt.c->on_connected_evt replace

        err_code = sd_ble_gattc_exchange_mtu_request(conn_handle, p_link->att_mtu_desired);

with 

        // err_code = sd_ble_gattc_exchange_mtu_request(conn_handle, p_link->att_mtu_desired);
        err_code = NRF_ERROR_BUSY;

This will tell the module to retry it after sometime (after getting new ble event). This should work fine in your case.