GATT Timeout on writing to buttonless dfu characteristic

RE: GATT Timeout on writing to buttonless dfu characteristic

fhfs — Thu, 26 Aug 2021 10:07:31 GMT

How does your devices implement these security modes?

We use nrf52 devices on either side of the connection. The connection works fine, the problem only occurs when we try to update the devices.

Sniffing using the SC LTK works for the most part. I've tested the devices where we got the GATT Timeouts, but I cant seem to recreate the problem. Leaving this issue resolved until it reoccurs.

RE: GATT Timeout on writing to buttonless dfu characteristic

Simonr — Mon, 23 Aug 2021 06:16:39 GMT

Sorry that I haven't gotten back to you until now. Have you still not been able to get a sniffer trace of the timeout occurring? If the TIMEOUT only occurs on one of the security modes, it seems like one of the devices have not implemented support for Security level 4: LESC MITM protected encrypted link using a 128-bit strength encryption key required.

How does your devices implement these security modes?

Best regards,

Simon

RE: GATT Timeout on writing to buttonless dfu characteristic

fhfs — Fri, 20 Aug 2021 12:24:06 GMT

With nrf Sniffer version 4.0 we can use the SC LTK to sniff the connections

RE: GATT Timeout on writing to buttonless dfu characteristic

fhfs — Thu, 22 Jul 2021 09:14:46 GMT

I have tried to recreate the GATT Timeout while the two devices are in debug mode with LESC level 2 and Debug Keys enabled. The GATT Timeout does not happen in the 20 times I've started the DFU.

It still does happen on our Release devices using LESC level 4. I don't see another way to pinpoint the problem with the GATT Timeout. Do you have any ideas?

RE: GATT Timeout on writing to buttonless dfu characteristic

Susheel Nuguru — Wed, 07 Jul 2021 13:52:27 GMT

Hi, Simon is on summer vacation and hence the delay in response. Good to know that you are now able to sniff the packets during LESC connected peers.

RE: GATT Timeout on writing to buttonless dfu characteristic

fhfs — Wed, 07 Jul 2021 12:43:29 GMT

I can indeed sniff LESC Just-Works connections with the nrf-sniffer and wireshark.
Daniel's method works perfectly

RE: GATT Timeout on writing to buttonless dfu characteristic

fhfs — Fri, 02 Jul 2021 14:48:24 GMT

Do you know how to enable this debugging mode?
We are currently using LESC with OOB.

My best guess is setting the mode to just-works, but where do I put/set the public/private debug keys?

RE: GATT Timeout on writing to buttonless dfu characteristic

Simonr — Wed, 23 Jun 2021 08:28:07 GMT

Thank you for answering my initial questions!

Sniffing a connection between paired devices is possible, and it's described how to that for connections that use LESC is described at the bottom of the Common Sniffing Actions guide here.

Best regards,

Simon

RE: GATT Timeout on writing to buttonless dfu characteristic

fhfs — Tue, 22 Jun 2021 14:37:46 GMT

Thank you for your answer Simon.

Which of the devices is it that times out?

Our gateway receives the timeout

What happens in the log of the other device when this timeout occurs?

Both sides disconnect, no special error.

If you could provide a sniffer trace of the devices in the DFU that would be great so we could see exactly what is going on over the air. You can use any nRF52 family DK as a sniffer with our nRFSniffer firmware that's to be used with Wireshark.

That will be hard. We use LESC encryption on our connections. Decrypting LESC is not supported with the current plugin, or is it?

Do you have any log between your devices that point to the notification subscribtion doesn't go through? To the best of my knowledge a delay like this shouldn't be required. HAve you tried implementing it to see if it decreases the chances of this timeout occurring

I will set up another test to capture both logs and try adding the delay after the write response which enabled the indications.

RE: GATT Timeout on writing to buttonless dfu characteristic

Simonr — Thu, 17 Jun 2021 11:24:10 GMT

Which of the devices is it that times out? What happens in the log of the other device when this timeout occurs? If you could provide a sniffer trace of the devices in the DFU that would be great so we could see exactly what is going on over the air. You can use any nRF52 family DK as a sniffer with our nRFSniffer firmware that's to be used with Wireshark.

Do you have any log between your devices that point to the notification subscribtion doesn't go through? To the best of my knowledge a delay like this shouldn't be required. HAve you tried implementing it to see if it decreases the chances of this timeout occurring?

Best regards,

Simon