BLE pairing issues with Lenovo X240

RE: BLE pairing issues with Lenovo X240

Susheel Nuguru — Wed, 21 Mar 2018 06:44:26 GMT

You way of adding a timer and letting master do an MTU exchange seems safe. There is nothing i can think of that could cause problems this way.

RE: BLE pairing issues with Lenovo X240

ohtap — Tue, 13 Mar 2018 12:04:34 GMT

Maybe I phrased it improperly - we're not using osDelay, instead we're using osTimer (asynchronous) with a callback to a new function we created inside nrf_ble_gatt.c. There we use sd_ble_gattc_exchange_mtu_request.

Unfortunately the original suggestion didn't work, possibly because the next MTU exchange request came too soon after the first one (Slave->Master). After adding the delay, the sniffer shows the Master initiating the exchange about 1 second after the initial connection, which succeeds.

Our main concern with the timer we added is some race caused by external events related to the parameters passed to sd_ble_gattc_exchange_mtu_request. Can those parameters change in short time periods?

RE: BLE pairing issues with Lenovo X240

Susheel Nuguru — Tue, 13 Mar 2018 11:31:42 GMT

on_connected_evt happens in SWI2 interrupt context and adding a synchronous busy delay in any ISR is not recommended (if not forbidden). There will be a lot of side affects to it,

1) no other events will be able to processed during this time. trying to test the softdevice events buffering capacity on a busy link

2) FreeRTOS tick handler is running on lower priority than SWI2 interrupt. So for 5 seconds, you are not allowing it to update ticks. If you set configUSE_DISABLE_TICK_AUTO_CORRECTION_DEBUG = 1 in your project, this will make the RTOS timer completely wrong. But if you do not disable autocorrection of internal timers, then the FreeRTOS will try to recover as soon as tick event gets a chance to run.

Did you try the suggestion I gave? Did it not work?

RE: BLE pairing issues with Lenovo X240

ohtap — Tue, 13 Mar 2018 10:49:44 GMT

The delay was added in on_connected_evt using a FREERTOS timer.

After the callback, sd_ble_gattc_exchange_mtu_request uses the connection handle and the desired MTU, so we save those before we start the timer (conn_handle, p_link).

Any danger of possible races? any external entities changing those parameters?

Thanks

RE: BLE pairing issues with Lenovo X240

Susheel Nuguru — Mon, 12 Mar 2018 19:26:53 GMT

where exactly have you added 5 secs delay? i hope that you did it in thread context and not inside any ISR

RE: BLE pairing issues with Lenovo X240

ohtap — Mon, 12 Mar 2018 11:24:26 GMT

We've added a 5 sec delay to the MTU exchange process, it seems it gives the central device enough time to initiate the exchange correctly.

We had to edit nrf_ble_gatt.c (on_connected_evt specifically), so we're hoping not to introduce new issues. Do you have any recommendations to make sure the rest of the environment wasn't negatively affected?

Thanks

RE: BLE pairing issues with Lenovo X240

Susheel Nuguru — Thu, 08 Mar 2018 12:05:54 GMT

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.

RE: BLE pairing issues with Lenovo X240

gkovelman_tap — Wed, 07 Mar 2018 12:42:13 GMT

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.

RE: BLE pairing issues with Lenovo X240

Kenneth — Wed, 07 Mar 2018 10:11:27 GMT

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.

RE: BLE pairing issues with Lenovo X240

gkovelman_tap — Mon, 05 Mar 2018 15:50:06 GMT

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.

RE: BLE pairing issues with Lenovo X240

gkovelman_tap — Mon, 05 Mar 2018 12:45:28 GMT

devzone.nordicsemi.com/.../htc_5F00_m9_5F00_pairing_5F00_1.pcapng

devzone.nordicsemi.com/.../lenovo_5F00_x240_5F00_pairing_5F00_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.

RE: BLE pairing issues with Lenovo X240

Susheel Nuguru — Mon, 05 Mar 2018 08:12:48 GMT

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.