zephyr: Bluetooth: bt_att: ATT Timeout
Describe the bug
Local device performing ATT write cmds, generates <wrn> bt_att: Ignoring unexpected request when peer device send an ATT request. The peer then gets <err> bt_att: ATT timeout
To Reproduce Use the branch: https://github.com/cvinayak/zephyr/commit/b4939f526a9c1c86a88fd55810ed85e1ecaaf46d
Steps to reproduce the behavior: Build and flash peripheral:
- mkdir -p build/peripheral; cd build/peripheral
- cmake -GNinja -DBOARD=nrf52dk_nrf52832 …/…/samples/bluetooth/peripheral
- ninja
- ninja flash
Build and flash central_hr: 5. mkdir -p build/central_hr; cd build/central_hr 6. cmake -GNinja -DBOARD=nrf52dk_nrf52832 …/…/samples/bluetooth/central_hr 7. ninja 8. ninja flash
- Open two terminals,
minicom -D /dev/ttyACMx - Observe both peripheral and central_hr fail with respective warning and error messages in the console.
Expected behavior ATT request from peer device shall not be dropped. ATT bearer shall not timeout.
Impact showstopper
Screenshots or console output
Environment (please complete the following information):
- OS: Linux
- Toolchain: Zephyr SDK 0.11.2
- Commit SHA or Version used: https://github.com/cvinayak/zephyr/commit/b4939f526a9c1c86a88fd55810ed85e1ecaaf46d
Additional context Add any other context about the problem here.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 35 (18 by maintainers)
Commits related to this issue
- Bluetooth: ATT: Fix overwritting sent callback ATT channel sent callback shall not be overwritting until the operation completes as it can result in breaking flow control when CONFIG_BT_ATT_ENFORCE_F... — committed to Vudentz/zephyr by Vudentz 4 years ago
- Bluetooth: ATT: Fix overwritting sent callback ATT channel sent callback shall not be overwritting until the operation completes as it can result in breaking flow control when CONFIG_BT_ATT_ENFORCE_F... — committed to Vudentz/zephyr by Vudentz 4 years ago
- Bluetooth: ATT: Fix overwritting sent callback ATT channel sent callback shall not be overwritting until the operation completes as it can result in breaking flow control when CONFIG_BT_ATT_ENFORCE_F... — committed to joerchan/zephyr by Vudentz 4 years ago
- Bluetooth: ATT: Fix overwritting sent callback ATT channel sent callback shall not be overwritting until the operation completes as it can result in breaking flow control when CONFIG_BT_ATT_ENFORCE_F... — committed to joerchan/zephyr by Vudentz 4 years ago
- Bluetooth: ATT: Fix overwritting sent callback ATT channel sent callback shall not be overwritting until the operation completes as it can result in breaking flow control when CONFIG_BT_ATT_ENFORCE_F... — committed to zephyrproject-rtos/zephyr by Vudentz 4 years ago
- Bluetooth: ATT: Fix overwritting sent callback ATT channel sent callback shall not be overwritting until the operation completes as it can result in breaking flow control when CONFIG_BT_ATT_ENFORCE_F... — committed to Vudentz/zephyr by Vudentz 4 years ago
- Bluetooth: ATT: Fix overwritting sent callback ATT channel sent callback shall not be overwritting until the operation completes as it can result in breaking flow control when CONFIG_BT_ATT_ENFORCE_F... — committed to petejohanson/zephyr by Vudentz 4 years ago
- Bluetooth: ATT: Fix overwritting sent callback ATT channel sent callback shall not be overwritting until the operation completes as it can result in breaking flow control when CONFIG_BT_ATT_ENFORCE_F... — committed to zephyrproject-rtos/zephyr by Vudentz 4 years ago
@mhx yep, that is exactly what I see as well with the latest commit.
No, that doesn’t seem related. We have a couple of deadlocks that need fixing (they have PRs) which might fix the issue you are seeing.
Ive update the set, it is now possible to flood the stack with write without response like before and as a bonus I adds support for doing it using the shell.
@mfiumara If I’m reading that stack-trace right it appears the ASSERT came from
zephyr_i2c_readand then got a usage-fault in theassert_post_actionhandler. The fact that you get a similar ATT timeout on 2.2.0 must mean that it is a different problem, because this one is a regression since 2.2.0.Can you create a separate bug-report for it?
This was introduced with EATT support since bt_l2cap_chan_send cannot rely on setting callbacks per buffer like we used to do with bt_l2cap_send_cb, anyway I working on a fix for this.