This commit prevents ATT request APIs from blocking waiting on the
req_slab pool on the system work queue. The API will instead return
-ENOMEM.
This aligns with commit 05b16b971b, which
establishes that the GATT request APIs are non-blocking on the system
work queue. That commit makes GATT request APIs fail with -ENOMEM when
they fail to allocate a buffer for the ATT PDU on the system work queue.
There is no reason to make this distinction between the two resources,
and this makes the API more consistent.
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
`>= 0` was used when EATT support was implemented (#23199) because
`bt_l2cap_chan_send` could return number of bytes sent. After PR #67528,
`bt_l2cap_chan_send` doesn't return amount of bytes sent or any positive
value, but either 0 or negative value. Thus `>= 0` is not needed. It
also confusing when reading code, especially when the same check is not
implemented in other cases where underlying function `chan_send` is
used.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
`att_sent` is removed as it does not provide any value. All checks are
already performed in `att_on_sent_cb`, and keeping it only increases
readability complexity.
`att_sent` is removed as doesn't give any value. All checks are done
already in `att_on_sent_cb`. It just increases readness complexity.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
The extra `bt_att_chan_req_send` does nothing but increases readability
complexity. All checks are already performed by the caller.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
Fix the following warning
att.c:734:3: warning: label followed by a declaration is a C23 extension
[-Wc23-extensions]
734 | k_tid_t current_thread = k_current_get();
| ^
By wrapping that code as a compound statement
Signed-off-by: Alberto Escolar Piedras <alberto.escolar.piedras@nordicsemi.no>
This commit alignes the timeout value for allocating buffers within att
on the BT RX thread, making it consistent within att.c, see
bt_att_req_alloc.
We are inferring in many bt_gatt_* functions that if called from a BT RX
thread (which is inherently the case if called from a callback when
running a Bluetooth application), we don't block and instead return
-ENOMEM when the ATT request queue is full, avoiding a deadlock.
This promise is fulfilled within bt_att_req_alloc, where the timeout for
allocation of the request slab is set to K_NO_WAIT if we are on the BT
RX thread. Unfortunately, we break this promise in
bt_att_chan_create_pdu, where the timeout for allocation of the att pool
is still K_FOREVER and deadlocks can (and do) occur when too many
requests are sent yet the pool is depleted.
Note: Both req_slab and att_pool sizes are defined by
CONFIG_BT_ATT_TX_COUNT. If applications start getting -ENOMEM with this
change, they were at risk of such a deadlock, and may increase
CONFIG_BT_ATT_TX_COUNT to allocate the att pool for their requests.
Note: This possible deadlock has been flying under the radar, as
att_pools are freed when the HCI driver has sent it to the controller
(instead of when receiving the response, as it happens with req_slabs)
and due to the att_pool and the req_slab being both sized by
CONFIG_BT_ATT_TX_COUNT, and req_slab being allocated before and
returning -ENOMEM already if there is no space, it takes a more specific
situation to deplete the att_pool but not the req_slab pool at this
point.
Note: Ideally, we don't want functions to behave differently depending
on which thread they are running, and while this commit makes it more
consistent, it should be considered a workaround solution.
Signed-off-by: Kyra Lengfeld <kyra.lengfeld@nordicsemi.no>
The buffer allocation in conn.c will trigger warnings if we try to use
anything else than K_NO_WAIT for the timeout when called from within the
system workqueue.
The calls in l2cap.c and att.c which may pass non-zero timeouts already
have proper handling for failed allocations, so make sure we use K_NO_WAIT
to avoid unnecessary warnings from conn.c.
Signed-off-by: Johan Hedberg <johan.hedberg@silabs.com>
When we receive a response from a server we do not have an
outstanding request with, we disconnect the connection
rather than just ignoring it.
The reason for this is that the remote server is
not ensuring correct ATT flow control, which means
that we cannot trust future responses from the
server.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Core spec V5.4 Vol. 3 Part G 2.5.2.1 Robust Caching specifies
the conditions where Database Out Of Sync (0x12) error needs to
be returned as follows:
If a client that has indicated support for robust caching (by
setting the Robust Caching bit in the Client Supported Features
characteristic) is change-unaware then the server shall send an
ATT_ERROR_RSP PDU with the Error Code parameter set to Database
Out Of Sync (0x12) when either of the following happen:
• That client requests an operation at any Attribute Handle or
list of Attribute Handles by sending an ATT request.
• That client sends an ATT_READ_BY_TYPE_REQ PDU with Attribute
Type other than «Include» or «Characteristic» and an Attribute
Handle range other than 0x0001 to 0xFFFF.
Add the conditions to ATT_READ_BY_TYPE_REQ handler.
Signed-off-by: Chang Kim <changshik@meta.com>
This API gives better control on L2CAP COC credits and suits better
for Upper Tester implementation.
Co-authored-by: Szymon Janc <szymon.janc@codecoup.pl>
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
The timeout state is local and can block new ATT operations, but does
not affect the remote side. Disconnecting the GATT connection upon ATT
timeout simplifies error handling for developers. This reduces rare
failure conditions to a common one, without needing special cases for
ATT timeouts.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
Add missing braces to comply with MISRA C:2012 Rule 15.6 and
also following Zephyr's style guideline.
Signed-off-by: Pisit Sawangvonganan <pisit@ndrsolution.com>
When change unaware client send ATT request it shall get Database
Out of Sync error. Reading GATT database hash is an exception here.
This was affecting GATT/SR/GAS/BV-05-C qualification test case.
Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl>
Convert users of net_buf_put() and net_buf_get() functions to use
non-wrapped putters and getters k_fifo_put() and k_fifo_get().
Special handling of net_bufs in k_fifos is no longer needed after commit
3d306c181f, since these actions are now
atomic regardless of any net_buf fragments.
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
When developing Bluetooth applications, you typically run into
some errors. If you are an experienced Bluetooth developer,
you would typically have an HCI error lookup table in your memory.
Others might not.
This commit utilizes defines CONFIG_BT_DEBUG_HCI_ERR_TO_STR
and utilizes bt_hci_err_to_str() to print out HCI error strings
when enabled to improve the user experience.
Several alternatives where considered. This approach was chosen
as it had the best balance between readability, code size, and
implementation complexity.
The alternatives are listed below as a reference.
1. Macro defined format specifier:
```c
#define HCI_ERR_FMT "%s"
#define BT_HCI_ERR_TO_STR(err) (err)
#define HCI_ERR_FMT "%d"
#define BT_HCI_ERR_TO_STR(err) bt_hci_err_to_str((err))
LOG_INF("The event contained " HCI_ERR_FMT " as status",
BT_HCI_ERR_TO_STR(err));
```
Advantage: Space efficient: Code size does not increase
Disadvantage: Code becomes hard to read
2. Format specifier to always include both integer and string:
```c
static inline const char bt_hci_err_to_str(err)
{
return "";
}
LOG_INF("The event contained %s(0x%02x) as status",
bt_hci_err_to_str(err), err);
```
Advantage: Simple to use, implement, and read,
Disadvantage: Increases code size when CONFIG_BT_DEBUG_HCI_ERR_TO_STR
is disabled. The compiler seems unable to optimize away the unused
format specifier. Note: The size increase is only present when
logging is enabled.
3. Always print as string, allocate a stack variable when printing:
```c
const char *bt_hci_err_to_str(char *dst, size_t dst_size, uint8_t err)
{
snprintf(dst, dst_size, 0x%02x, err);
return dst;
}
LOG_INF("The event contained %s as status", BT_HCI_ERR_TO_STR(err));
```
Advantage: Very easy to read.
Disadvantage: Printing error codes becomes slow as it involves calling
snprint.
4. Implement a custom printf specifier, for example E.
This requires a global CONFIG_ERR_AS_STR as I assume we cannot have
one specifier for each type of error code.
Also, I assume we cannot start adding specifiers for each subsystem.
```c
#define BT_HCI_ERR_TO_STR(err) (err)
#define BT_HCI_ERR_TO_STR(err) bt_hci_err_to_str((err))
LOG_INF("The event contained %E as status", BT_HCI_ERR_TO_STR(err));
```
Advantage: Both efficient code and readable code.
Disadvantage: This requires a global CONFIG_ERR_AS_STR as I assume
we cannot have one specifier for each type of error code.
Also, I assume we cannot start adding specifiers for each subsystem.
That is, this approach is hard to implement correctly in a scalable
way.
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
It was pointed out in a future PR that they should have
a corresponding experimental Kconfig entry.
See PR #73795.
This updates the APIs added in PR #73826 and PR #74295.
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
Utilize a code spell-checking tool to scan for and correct spelling errors
in all files within the subsys/bluetooth/host directory.
Signed-off-by: Pisit Sawangvonganan <pisit@ndrsolution.com>
This can be useful if application developers
want to print them in the applications.
Later we can also use them in
the host to improve debuggability.
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
This API replaces `bt_l2cap_send()` and `bt_l2cap_send_cb()`.
The difference is that it takes the `struct bt_l2cap_le_chan` object
directly instead of a connection + CID.
We need the channel object in order to put the PDU on the TX queue. It
is inefficient to do a search for every PDU when the caller knows the
channel object's address and can just pass it down.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
`att_req_send_process` is not thread safe.
In the case where the current context is pre-emptible (e.g. when a user
sends something over GATT from the main thread):
The iterator in `att_req_send_process` can get interrupted mid-processing,
breaking the logic and resulting in an assert/crash/data corruption.
Additionally, the connection state check in this fn is also not
thread-safe, the RX thread could pre-empt us and disconnect right before
we attempt to send on an ATT bearer that is on it.
This is a hotfix until we have a generalized solution for the host API
surface. It seems a lot of our logic assumes cooperative priority.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
This served no purpose for responces. The minimum MTU is sufficient for
all ATT headers.
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
When EATT is enabled, bt_att_create_rsp_pdu used to reserve headroom for
the SDU header even when responding on the UATT bearer.
That subtracted from the room for the ATT payload in the buffers. The
remaining buffer size was insufficient to create a PDU of ATT MTU size,
since the exchanged local MTU is calculated the with the assumption that
the SDU header is not present.
This broke the ATT MTU promise, and e.g. our read response will have two
bytes fewer than promised. This caused a failure in PTS.
The new bt_att_create_rsp_pdu pays attention to the bearer type and only
allocates the SDU header on EATT bearers.
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
Removed the "operation" infix from the bt_gatt_authorization_cb
callback structure in the Bluetooth GATT header.
Signed-off-by: Kamil Piszczek <Kamil.Piszczek@nordicsemi.no>
If an att buf is destroyed during bearer teardown, we want to avoid
using and passing invalid references to the application.
Double-check that the current bearer, the ATT object and the ACL conn
objects it is attached to are not NULL before proceeding.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Added the GATT authorization callback API that allows the user to
define application-specific authorization logic for GATT operations.
Signed-off-by: Kamil Piszczek <Kamil.Piszczek@nordicsemi.no>
This is just as arbitrary as what was before, but simpler.
Before this change, the callback were invoked upon receiving the num
complete packets event.
This did not necessarily work with all spec-compliant controllers.
Now the callback is invoked as soon as the lower layer destroys the
buffer. ATT shouldn't care whether L2CAP sends it over RFC1149 or
something else after that point.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Co-authored-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
Why?
- metadata is easier to manage as an array + index
- less error-prone -> less memory-management bugs
- we can. because of the previous refactor
- PDU allocations are more predictable
- ATT buffer size can be optimized by app
- isolates ATT from the rest of the ACL users
- decouples ATT PDU size from e.g. SMP w/ LESC
Drawbacks:
- higher memory usage
- kconfig change
The higher memory use is only temporary, as this will be followed-up
with more refactors that should bring it back down.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Co-authored-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
This fixes CCC subscriptions that were removed if the automatic
resubscription was aborted by ACL disconnection.
As the client renews subscriptions, there is no point of removing those
if the link is disconnected unexpectedly.
The API user won't be notified about the failure, as the automatic
resubscriptions are implicit, and after reconnection the subscriptions
will be still valid.
Signed-off-by: Mariusz Skamra <mariusz.skamra@codecoup.pl>
It's bad form, especially since in that case, it's always the same function
that is called `bt_att_sent()`.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Enforcing the peer's behavior is not strictly necessary. All the host
should do is make sure it is resilient to a spec-violating peer.
Moreover, a growing number of platforms were disabling the check, as the
spec allows "batching" HCI num complete packets events, stalling ATT RX.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Co-authored-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
EATT is the only user of `bt_l2cap_chan_send_cb`, and not necessary. We
can maintain the same functionality without it.
Instead of passing and storing the callback into l2cap, we can store it
in a callback queue in the ATT bearer struct.
This will allow us to remove that internal API later, in order to
streamline the l2cap API.
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
If the conn security elevation is already in progress, retry the ATT
request if failed due to security reasons.
Signed-off-by: Mariusz Skamra <mariusz.skamra@codecoup.pl>
When EATT is established, the value returned from `bt_att_get_mtu` is
not useful to determine the ATT_MTU that applies to a ATT response. This
is because `bt_att_get_mtu` may return the value for a different bearer
than the request is serviced on.
To fix this, the params struct for the GATT read operation is given a
new field that will record the ATT_MTU that applies to this ATT
operation. This value is then used to determine if the GATT long read
operation is concluded.
Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/61741
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
A race condition between ATT RX and the connection teardown can happen, as
the teardown is executed from a workqueue.
For example:
- connection is established
- `connected` cb is called (in BT RX context)
- user calls `bt_conn_disconnect` in that cb
- connection is marked as disconnecting
- ATT teardown & general conn cleanup is scheduled
- BT RX gets an ATT request, tries to handle it
- ATT bearer is still not GC'd, so it tries and fails to send it
-> results in error message "not connected" on log
- ATT teardown & general conn cleanup runs
To avoid that, we not only check the bearer state, but also its ACL conn
state.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
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>
Add a pointer to the associated server structure in the L2CAP accept()
callback. This allows the callee to know which server an incoming L2CAP
connection is associated with.
Signed-off-by: Donatien Garnier <donatien.garnier@blecon.net>
Modify the signature of the k_mem_slab_free() function with a new one,
replacing the old void **mem with void *mem as a parameter.
The following function:
void k_mem_slab_free(struct k_mem_slab *slab, void **mem);
has the wrong signature. mem is only used as a regular pointer, so there
is no need to use a double-pointer. The correct signature should be:
void k_mem_slab_free(struct k_mem_slab *slab, void *mem);
The issue with the current signature, although functional, is that it is
extremely confusing. I myself, a veteran Zephyr developer, was confused
by this parameter when looking at it recently.
All in-tree uses of the function have been adapted.
Fixes#61888.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
Using a different channel for responding to a request is forbidden by spec.
The allocator was especially flawed as it iterated over all the EATT
channels to find one w/ a big enough MTU, but the sending was still done
over the same channel as the REQ.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
This to ensure we don't fail to send a response and never get an ATT
TIMEOUT due to ACL TX buffer starvation caused by other users of the stack.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>