Connection parameter update disconnection on Windows

[nrbrook]

• 1323.PEDpro500 June 14 v3.pcapng

We have a device that works correctly on iOS, Android, mac, but disconnects on some Windows machines. We use nRF5 SDK 17.1.0 and s132 7.2.0. The disconnect occurs after the supervision timeout following a connection parameter update, whether successful or not. It doesn’t happen if we send data to Windows after the connection parameter update. I have attached a packet capture using BTVS. I saw this issue:

https://github.com/zephyrproject-rtos/zephyr/issues/29636

Could it be related?

edit: link above seems to be regarding the central not the peripheral role so I guess unlikely related.

[Vidar Berg]

Hi,

I do not think this is a known issue at least. Could you try again with the NRF_SDH_CLOCK_LF_ACCURACY set to 1 and NRF_SDH_CLOCK_LF_SRC 0 and see if it gives the same result? This may help rule out drift on the slow clock (either on the PC or on the device) as a possible cause. I also think it would be helpful to have a packet capture of the packets sent on-air if you have BLE sniffer on hand.

Best regards,

Vidar

[nrbrook]

Hi Vidar,

Vidar Berg said:

Could you try again with the NRF_SDH_CLOCK_LF_ACCURACY set to 1 and NRF_SDH_CLOCK_LF_SRC 0 and see if it gives the same result?

They already are set to these values.

I am debugging this remotely so it might be difficult to get a packet log from a sniffer, but I will try.

However, I got debug logs from the device, and the disconnect reason on the nRF52832 is BLE_HCI_STATUS_CODE_LMP_RESPONSE_TIMEOUT. Does this indicate that windows has not responded to the request?

[Vidar Berg]

Hi,

BLE_HCI_STATUS_CODE_LMP_RESPONSE_TIMEOUT indicates that the Windows host failed to respond to a link layer control request issued by your peripheral. But I don't understand how it could be tied to the connection parameter update.

From the core spec. v5.3, vol. 6, part B:

Are you using the GATT Module to handle data length updates in your FW? In that case, please try to disable the NRF_BLE_GATT_MTU_EXCHANGE_INITIATION_ENABLED in sdk_config.h to see if it makes any difference if Windows is allowed to initiate the update procedure first.

[nrbrook]

BT500S-6 June 16 v1.pcapng

I think what might be happening is Windows sends an "LE Connection Update complete" packet from controller to host (in the attached which is a bit simpler):

727	42.195	controller	host	HCI_EVT	Rcvd LE Meta (LE Connection Update Complete)

and then for some reason is expecting some communication from the other side after that. It disconnects after the supervision timeout after that:

733	47.291	controller	host	HCI_EVT	Rcvd Disconnect Complete

Because it thinks the connection has timed out, it doesn't send a disconnection packet, and so on the nRF, the LL times out because Windows just stops communicating. Although I see the LMP_RESPONSE_TIMEOUT is when an LMP or LL transaction failed to respond within the timeout. But the nRF does get the connection parameters response:

00> [00:01:01.128,234] <info> Bluetooth: Attempting connection param change, min: 50ms, max: 75ms, latency: 0, timeout: 5000ms
00> [00:01:01.411,682] <debug> Bluetooth: Connection parameters changed successfully for connection 0000
00> [00:01:01.411,712] <info> Bluetooth: Connection params updated for connection 0000: min 75ms, max 75ms, latency 0, timeout 5000ms
00> [00:01:01.501,708] <info> Bluetooth: Disconnected. conn_handle: 0x0, reason: BLE_HCI_STATUS_CODE_LMP_RESPONSE_TIMEOUT

So perhaps it is nRF that times out first, and then Windows? I'll try to get a sniffer capture.

As I mentioned, if we send a packet after that connection parameter update response, Windows doesn't disconnect.

I do use nrf_ble_gatt, but NRF_BLE_GATT_MTU_EXCHANGE_INITIATION_ENABLED is not defined in my project and so is disabled already.

[Vidar Berg]

After a LMP_RESPONSE_TIMEOUT, the peripheral (nrf) will stop responding to the central so the central will end up with a supervision timeout.

nrbrook said:

So perhaps it is nRF that times out first, and then Windows? I'll try to get a sniffer capture.

As I mentioned, if we send a packet after that connection parameter update response, Windows doesn't disconnect.

Yes, it's this part I don't understand. I hope you are able to get a sniffer capture of it.

[nrbrook]

We are trying to get a capture, but we use LESC. When using the debug key, Windows doesn't accept the key and rejects the pairing request (we can use the sniffer successfully when connecting with iOS). If we disable LESC and use just works pairing, we can use the sniffer, but the problem doesn't seem to occur. Any suggestions? Do you know of a way to get Windows to accept the LESC debug key?

[Vidar Berg]

It's surprising that the paring method seems affect behavior as well. Are you doing bonding or do you pair on every connection?

[nrbrook]

Yes, I was also surprised. I've asked the remote guys to try again because this problem is somewhat intermittent, so it may be just that it didn't happen when they tried.

Yes we are bonding.