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]

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.

[Vidar Berg]

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()

nrbrook said:

so it may be just that it didn't happen when they tried

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