Bluetooth: Host: bt_att: already processing a REQ/RSP on chan xxx

[axelnxp]

Describe the bug
We are currently evaluating Zephyr BLE on an internal platform and we just rebased on 3.5.0 tag from 3.4.0.
Since then, we are facing a regression on BLE, related to the recent rework of the buffer reuse for the att rsp.

Here is a log when running the peripheral_ht sample:

Bluetooth initialized
no temperature device; using simulated data
Advertising successfully started
Connected
[00:21:05.993,860] <err> bt_att: already processing a REQ/RSP on chan 0x30046d80
[00:21:05.993,874] <err> bt_att: already processing a REQ/RSP on chan 0x30046d80
[00:21:05.993,880] <err> bt_att: unable to allocate buf for error response

We've been able to identify the commit causing the regression on our side: 828be80

As a workaround, disabling the buffer re-use in bt_att_chan_create_pdu solves the problem.

        switch (att_op_get_type(op)) {
	case ATT_RESPONSE:
		/* Use a timeout only when responding */
		timeout = BT_ATT_TIMEOUT;
		// re_use = true;
		break;
	case ATT_CONFIRMATION:
		timeout = BT_ATT_TIMEOUT;
		break;
	default:
		timeout = K_FOREVER;
	}

Is there anything we may have missed ? A new configuration or requirement to make it work properly ?

Thanks !

[github-actions]

Hi @axelnxp! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[kruithofa]

@axelnxp can you provide the steps required to reproduce this issue? In particular: are both sides Zephyr

[carlescufi]

@yeaissa could you verify that #65272 fixes this issue as well?

[yeaissa]

Yes it fixes the issue