Application-layer avoidance of DRGN-9612?

RE: Application-layer avoidance of DRGN-9612?

Elias — Wed, 22 Sep 2021 20:42:02 GMT

Unfortunately, we've only been able to retain information from SD asserts very recently in development, so for most instances, we don't have information on which assert fired. For the ones that we've captured, they are always "id = 0x01, pc = 0x15022", and we believe this is due to DRGN-9535 and DRGN-9723.

RE: Application-layer avoidance of DRGN-9612?

Kenneth — Wed, 22 Sep 2021 13:25:55 GMT

[quote user="Elias Simon"]Okay, because our application always uses "max_tx_octets = 251", it sounds like the issue can't explain any of the unexpected resets (due to SD assert) that we've been seeing. Does that conclusion sound valid?[/quote]

I agree. You might have shared this in other devzone cases, but which asserts are you seeing and are they always the same?

RE: Application-layer avoidance of DRGN-9612?

Elias — Tue, 21 Sep 2021 18:49:30 GMT

Okay, because our application always uses "max_tx_octets = 251", it sounds like the issue can't explain any of the unexpected resets (due to SD assert) that we've been seeing. Does that conclusion sound valid?

We have another explanation for the resets, but it doesn't fit as "neatly" for all recorded instances, so we were exploring other possibilities.

RE: Application-layer avoidance of DRGN-9612?

Kenneth — Tue, 21 Sep 2021 13:20:56 GMT

Hi,

Have you experienced this issue or are you asking theoretical about this issue?

The assert due DRGN-9612 will only happen if the TX DLE length is downgraded, while SoftDevice is trying to send a long packet (and gets a NACK at the same time). The issue was found internally and fixed. I consider this a very specific corner case issue that we have not seen any direct report of, since it's not very probably that a peer may ever downgrade its DLE length. At least we have not been able to tie it as the direct root-cause for any asset reported, however the assert that could happen is a generic "rem overstay" assert, so it might have occured without our knowledge though. All that said, the sd_ble_gap_data_length_update(connHandle, NULL, NULL) should be able to prevent this, since it always use the same length.

Best regards,
Kenneth