zephyr: BLE stack can get stuck in connected state despite connection failure
I’m periodically connecting to a Zephyr sensor (nrf52840) using a central device (esp32-c3). The central is rather unstable due to WiFi/BT coexistence, so it drops the connection unexpectedly a lot. I noticed that the Zephyr device does not recover nicely from this, if it had an active connection when the error occurs.
It gets detected on a low level, but the information does not get propagated it seems. It logs the following:
[00:41:33.821,014] <wrn> bt_hci_core: opcode 0x2013 status 0x02
I.e. it tries to update the connection (op=0x2013) but gets the error “NO CONNECTION” (0x02). But no one picks this up. In particular, I checked the file subsys/bluetooth/host/conn.c which calls send_conn_le_param_update(conn, param) inside its deferred work handler, but it never checks the return value so it obviously does not do anything with the information.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 20 (14 by maintainers)
Commits related to this issue
- Bluetooth: conn: don't ignore send_conn_le_param_update's retval Could result in a zombie connection, that is the local device thinking it's still connected whilst the peer has disconnected. (maybe)... — committed to jori-nordic/zephyr by jori-nordic 2 years ago
- tests: Bluetooth: add sleep in notify cb testcase Validates that nothing nefarious happens if the application decides to wait an arbitrary amount of time in notification callbacks. Also validates th... — committed to jori-nordic/zephyr by jori-nordic 9 months ago
- tests: Bluetooth: add sleep in notify cb testcase Validates that nothing nefarious happens if the application decides to wait an arbitrary amount of time in notification callbacks. Also validates th... — committed to jori-nordic/zephyr by jori-nordic 9 months ago
- tests: Bluetooth: add sleep in notify cb testcase Validates that nothing nefarious happens if the application decides to wait an arbitrary amount of time in notification callbacks. Also validates th... — committed to zephyrproject-rtos/zephyr by jori-nordic 9 months ago
- tests: Bluetooth: add sleep in notify cb testcase Validates that nothing nefarious happens if the application decides to wait an arbitrary amount of time in notification callbacks. Also validates th... — committed to Chenhongren/zephyr by jori-nordic 9 months ago
I’m saying this is (maybe) a solution, but likely not the correct (or long-term) solution.
Problem is that we’re in a work handler so we can’t really propagate the error. The only thing we can do as you say is check it and execute some procedure (like explicitly disconnect the connection).
But that ideally shouldn’t be necessary and the device should know it’s disconnected when the supervision timeout fires in the controller. It shouldn’t just ‘hang’ like this. What I mean is I’d like to find out what’s keeping this connection alive in the stack.