Feature request to deal with a buggy non-Nordic stack

[Elias]

I'm trying to debug my UWP Central app, which interacts with our device based on nRF52/s132. What I think I'm seeing with my packet sniffer (the nRF51 sniffer, incidentally) is that the BLE stack on my Windows machine (an Intel stack) is misbehaving at the Link Layer, specifically in its use of SN/NESN bits.

Eventually, the stack appears to send a SN/NESN combination that is different from both the next expected combination (which happens normally) and the one from its previously transmitted packet (happens in the common case of re-transmitting a single packet). In this case, the s132 appears to continue to increment the SN/NESN, but it keeps the packet payload the same for several packets, and eventually, connection events cease without a disconnection event.

This itself isn't necessarily a "bug" in s132, since I doubt the BT spec specifies how to deal with this. What I would like, though, is that the s132 handle it more intelligently, at least by throwing an error to the application, or flushing the transmit buffer, or maybe even disconnecting. Right now, I can't tell what's going on from the Peripheral alone.

Will post some sniffer files once I can produce a minimal example.

[Hung Bui]

Hi Elias,

I don't think throwing an event to the application would be a good idea because if we do that we may have to handle lots of unnecessary events if there is some interference (that can be recovered via re-transmission)

Note that SN and NESN can be used independently to ACK and to tell that there is new payload. Please have a look here at chapter II.

I don't see why we have to flush the transmit buffer or disconnecting if the central still operate normally after that. You may want to give us some more information or explanation on what went wrong, a screenshot of the sniffer trace would be useful.