Long time to disconnect

[nordev]

Hi, 

Our NRF52840 (running 14.2) often takes a very long time to disconnect, from when a disconnection is initiated by the phone. It can take 30s, sometimes even more, for the disconnect to happen. Sometimes the disconnect happens immediately like it should, but I would say that it is more common for the disconnect to take a long time than for the disconnect to be normal. 

I installed the NRF Sniffer and have done a capture, but I am not really sure what to make of the result. 

The below was a bad disconnect. Here, the highlighted line was about when the disconnect was initiated on the phone (image 1). Then I got "Empty PDU" for a long time. The empty PDU continues for a long time, with only one "encrypted packet decrypted incorrectly" in between, then in the second image, the highlighted line shows when the disconnect actually happens. There is ~13 sec in between the initiation and the actual disconnect.

By contrast, this was one of the times that I got a normal disconnection. 

The above was done with our custom app. The issue also happens when using the NRF Connect App for iOS. For reference, below is the capture when the disconnect was initiated by the NRF app:

I pressed the disconnect button around the time of this highlighted line: 

There is no command of any kind here though; the closest command is this one (but I don't know if they're even related, this is just the first command I found when scrolling up):

The disconnect comes what looks like 23 seconds later: 

My questions:

(MAIN QUESTION) How can I find out why it is taking a long time to disconnect? Note that it happens with different phones, but we have only been able to test with iPhones so far.

AUXILLIARY QUESTIONS: 

1. What are control opcodes and why do they only show up in the test using the NRF app, but not our custom app? Should we do something to enable these opcodes? 

2. What is empty PDU? 

3. What is "bad MIC"?

4. Where do I learn about how to interpret the captured packets? I read this but it doesn't really explain what I should be looking for.

Thanks!

[nordev]

Hi Joakim Jakobsen are you planning to help with my question? It has been more than 2 weeks. Can anyone else help?ovrebekk? Karl Ylvisaker? I am still stuck and would be grateful for some guidance. 

Some things I have tried since my original post:

• i have tried loading a Nordic example to see if the issue persists. The one I used is ble_app_bms. The disconnects happen immediately, so the problem must be somewhere in my code. Or maybe something in the compilation settings?
• I checked the call stack for when the disconnect is triggered and compared between my app and the Nordic example. It is the same exact thing in both cases (screenshot from bms app): except for some reason, in my app, the handlers (which I believe are part of the softdevice) just don’t get triggered until 10-30 seconds after the disconnect is initiated on the phone. The whole stack executes immediately once the first handler is triggered though. 
• I have tried commenting out all the custom parts of my app (including bluetooth_init() and blietooth_on_ble_evt()) to see if I could pinpoint what is wrong, but I am still experiencing the problem. I tried connecting and disconnecting 5 times in a row, using the Nordic NRF Connect app for iPhone, and I timed how long it took from pressing the “disconnect” button in the phone to the actual disconnect event: 22s, 31s, 10s, 25s, 28s respectively. It is different every time. 

Also, this is an aside, but I am having to use my phone to send this note because your website is not working on my computer for some reason. It has been like this the whole week. It says “waiting for available socket” and stays like this forever. Other websites work fine though. 

when I regain access to your website via my computer, I can send a code snippet for what is left over after commenting out / removing the custom parts of my app. 

i am looking for guidance on what other parts of the code or configurations I can check that could possibly be causing this issue. 

thank you!