Peripheral missing disconnect on timeout

Hi,

Did you register a disconnected callback? E.g. as shown here?

When debugging I notice that disconnect does not work as it returns that it is not connected, but conn->ref is not 0. Calling unref till it reaches 0 causes it to start advertising again.

But upon trying to connect to this we get
***New connection: 0 (printed by on_gap_evt_connected in our script)
connect_to_device error: 'NoneType' object is not subscriptable.

After this, it stops advertising again while state remains in BT_CONN_CONNECT_ADV.

Has there been any progress on this? We manage to reproduce the hang regularly but are unable to figure out why it happens. Any failed transmit on NUS is handled.

Hi,

I have tried to reproduce the issue, but so far it's working fine here.

Are you able to provide a simple pc-ble-driver python script, together with a simple nRF Connect SDK sample that reproduces this?

So far it has been difficult to strip it down to a working example.
The basic premise is apparently starting new connections while already starting a connection from the python side in such a way as to get the dongle in a "busy" state. When reset later it sometimes gets the peripheral in an odd state where it doesn't disconnect properly?

Maybe we can share project access, but it would be some work to make it run without the external hardware that is integrated into the code. In theory a blank NUS example with some high traffic should be all it takes while trying to "pester" it with connections, but the sample does not build for me and I did not have time to dig into it.

Kyrre Aalerud said:

When reset later it sometimes gets the peripheral in an odd state where it doesn't disconnect properly?

Maybe a Bluetooth sniffer trace of the issue could help give some clues about what is needed to trigger this issue. See: https://www.nordicsemi.com/Products/Development-tools/nRF-Sniffer-for-Bluetooth-LE

It's a long shot, but maybe the fix in this PR could help: https://github.com/zephyrproject-rtos/zephyr/pull/44194

I have not yet managed to grab a sniff, but I did discover some issue related to this.
The code uses NUS and so there is a callback registered with NUS for send, and as we allocate buffers and deliver to NUS we are not able to free them as link goes down.

bt_gatt_notify_cb() is called by NUS in bt_nus_send() and it gives it (in param structure) a single callback for when it is complete. As long as link is alive when it starts this function, it does not fail, and queues up the data. However, there is no callback for failure if link goes down and there is now nobody to deliver the tx events to. Next connection is established, but nothing can be sent, and when this new connection times out (4 seconds default is a long time) nothing happens.

I have not yet managed to grab a sniff, but I did discover some issue related to this.
The code uses NUS and so there is a callback registered with NUS for send, and as we allocate buffers and deliver to NUS we are not able to free them as link goes down.

bt_gatt_notify_cb() is called by NUS in bt_nus_send() and it gives it (in param structure) a single callback for when it is complete. As long as link is alive when it starts this function, it does not fail, and queues up the data. However, there is no callback for failure if link goes down and there is now nobody to deliver the tx events to. Next connection is established, but nothing can be sent, and when this new connection times out (4 seconds default is a long time) nothing happens.