Connection parameter update disconnection on Windows

RE: Connection parameter update disconnection on Windows

Vidar Berg — Wed, 22 Jun 2022 11:07:58 GMT

In that case, it should be possible to load LTK from flash and insert into Wireshark. see "Sniffing a connection between bonded devices".

PM API to load bonding information for peer devices: pm_peer_data_bonding_load()

[quote userid="69018" url="~/f/nordic-q-a/89012/connection-parameter-update-disconnection-on-windows/373636"]so it may be just that it didn't happen when they tried[/quote]

I think so, unless the issue only occurs on the initial connection when bonding takes place.

RE: Connection parameter update disconnection on Windows

nrbrook — Wed, 22 Jun 2022 10:58:13 GMT

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.

RE: Connection parameter update disconnection on Windows

Vidar Berg — Wed, 22 Jun 2022 10:56:52 GMT

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

RE: Connection parameter update disconnection on Windows

nrbrook — Wed, 22 Jun 2022 09:50:58 GMT

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?

RE: Connection parameter update disconnection on Windows

Vidar Berg — Fri, 17 Jun 2022 09:02:35 GMT

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

[quote user="nrbrook"]

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.

[/quote]

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

RE: Connection parameter update disconnection on Windows

nrbrook — Fri, 17 Jun 2022 08:15:25 GMT

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

RE: Connection parameter update disconnection on Windows

Vidar Berg — Fri, 17 Jun 2022 07:17:09 GMT

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.

RE: Connection parameter update disconnection on Windows

nrbrook — Thu, 16 Jun 2022 16:15:07 GMT

Hi Vidar,

[quote userid="4240" url="~/f/nordic-q-a/89012/connection-parameter-update-disconnection-on-windows/372849#372849"]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?[/quote]

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?

RE: Connection parameter update disconnection on Windows

Vidar Berg — Thu, 16 Jun 2022 14:05:51 GMT

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