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.

Hi,

Kyrre Aalerud said:

when the error happens, ref is still 3.
Normally ref is 2,

That sounds strange. Where are the places you call bt_conn_ref() and bt_conn_unref() ? In what callbacks?

Could you post the code relevant functions / callbacks where you call bt_conn_ref/bt_conn_unref ?

The ref:

static void connected(struct bt_conn *conn, uint8_t err)
{
    struct bt_conn_info info;

    if (err) 
    {
        LOG_ERR("BLE Connection failed (err 0x%02x)", err);
        return;
    }

    default_conn_ble = bt_conn_ref(conn);

    bt_conn_get_info(conn, &info);
    LOG_INF("BLE Connected: Interval=%d, Datalen=%d", info.le.interval, info.le.data_len->tx_max_len);

The connected() callback goes on to check some parameters and request changes in data length if appropriate.

The unref:

static void disconnected(struct bt_conn *conn, uint8_t reason)
{
    LOG_WRN("BLE Disconnected (reason 0x%02x)", reason);
    if (auth_conn) 
    {
        bt_conn_unref(auth_conn);
        auth_conn = NULL;
    }
    
    if (default_conn_ble) 
    {
        bt_conn_unref(default_conn_ble);
        default_conn_ble = NULL;
        disable_reporting_over_ble(); // Once disconnected, disable reporting over BLE
    }
}

We only support one connection, and it appears the issue happens more if we trigger two quick connects from same unit in python with connectivity dongle before previous connect has finished or failed. This seems to queue up two connections in such a way as to leave us out of sync and closing/reopening python sript (and device) seems to cause the connection to close so we can continue.

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?

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.