bartoszek/zephyr
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Bluetooth: att: don't re-use the ATT buffer for confirmations

Browse Source 
If the peer is a zephyr host, there is no problem, as the Zephyr
host limits sending parallel REQs and INDs.

But the spec allows sending those in parallel, and it may end up that
the re-used REQ buffer hasn't been destroyed when an indication comes.

Only re-use the buffer when enqueuing ATT responses.

This means that we may run out of buffers if the peer sends too many
indications and our application also sends a lot of commands/notifications.

The rationale for this is that having to handle a lot of requests is a
more plausible scenario (e.g. being discovered by multiple peers) than
handling lots of parallel indications.

Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
This commit is contained in:
Jonathan Rico 2023-09-26 16:37:26 +02:00 committed by Johan Hedberg
parent 3bfeadfa4a
commit 7093538c42
1 changed files with 5 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
subsys/bluetooth/host/att.c
View File

@ -670,11 +670,13 @@ static struct net_buf *bt_att_chan_create_pdu(struct bt_att_chan *chan, uint8_t
switch (att_op_get_type(op)) {
case ATT_RESPONSE:
case ATT_CONFIRMATION:
/* Use a timeout only when responding/confirming */
/* 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;
}
@ -701,7 +703,7 @@ static struct net_buf *bt_att_chan_create_pdu(struct bt_att_chan *chan, uint8_t
* This is better than an assert as an assert would
* allow a peer to DoS us.
*/
LOG_ERR("already processing a transaction on chan %p", chan);
LOG_ERR("already processing a REQ/RSP on chan %p", chan);
return NULL;
}