Connections drop and don't come back

RE: Connections drop and don't come back

Einar Thorsrud — Mon, 24 Mar 2025 11:41:56 GMT

Hi David,

I do not have any updaed from my side, but I look forward to seeing the result of your last test and will continue looking at this after that.

RE: Connections drop and don't come back

David Ormand — Fri, 21 Mar 2025 22:41:20 GMT

Some more information:

I have been capturing the internally-generated error codes generated by the Central as it runs, and noticed a pattern just before the "drop and don't come back" event occurs. I've got a Discovery process that looks for the UUID of my custom service, then the characteristics, and then the CCCD attribute; if something prevents the service discovery step from completing, then the connection is dropped. This is the 2nd-to-last error reported. Due to a logic error in my code, the connection is being dropped _twice_. After the first one, the bt_conn pointer is being dereferenced and set to NULL. Then the second call to bt_conn_disconnect occurs.

I'm looking at the bt_conn_disconnect() function in zephyr/subsys/bluetooth/host/conn.c. It doesn't look like there are any tests performed on conn before using it. I shouldn't be surprised that trying to use a NULL pointer would cause a fault. Could be this is killing the entire Bluetooth thread, so it isn't just advertising that isn't working, it's all the BLE stuff. I guess I shouldn't be surprised that the interrupt-driven console part of my program would continue to run.

I can believe that a poor-quality RF scenario could cause an incident during Discovery; this is why I never see it except when the case is flipped over, and only rarely even then.

I've fixed my logic bug and am rerunning the test to see if the "drop and don't come back" problem recurs. If it does, I will attempt to enable full logging to console and try to figure out how to capture it in this embedded application.

RE: Connections drop and don't come back

David Ormand — Fri, 21 Mar 2025 22:24:13 GMT

A bit more info:

When this event occurs, the Central reports not seeing _any_ Peripheral devices advertising, even ones that were not previously connected.

This led us previously to suspect that some error was occurring during reconnect that left scanning off. So we implemented a timer that restarts scanning if a reconnect is _not_ in progress and no Peripheral advertising is detected. If scanning is already running, the worst that could happen (so we figured) is getting an EALREADY return (except we saw that bt_le_scan_start() was returning 0 frequently, much more than the "drop and don't come back" event).

This did not fix the problem.

RE: Connections drop and don't come back

Einar Thorsrud — Fri, 21 Mar 2025 08:47:32 GMT

Hi,

I am looking into this and will get back to you.