Use IN_RANGE instead of explicitly checking that a value is
in between two other values
Signed-off-by: Andries Kruithof <andries.kruithof@nordicsemi.no>
The BT Core Spec v5.4 allows separate SDU_Interval to
be set on C_To_P and P_To_C directions,
but this is not possible with the existing interface.
This PR splits the interval parameter in the call to
bt_iso_sig_create into one for C_To_P
and one for P_To_C
It also splits the latency parameter into one for
C_To_P and one for P_To_C
Signed-off-by: Andries Kruithof <andries.kruithof@nordicsemi.no>
Bluetooth: ISO: update UI for extended API
The API for setting the SDU interval and latency have been updated.
This PR also updates the setting of these by the user in the shell
and the iso_connected_benchmark sample
Signed-off-by: Andries Kruithof <andries.kruithof@nordicsemi.no>
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>
The `BT_HCI_OP_HOST_NUM_COMPLETED_PACKETS` is not expected to generate a
response from the controller, but from the spec:
Normally, no event is generated after the
HCI_Host_Number_Of_Completed_Packets command has completed. However, if
the HCI_Host_Number_Of_Completed_Packets command contains one or more
invalid parameters, the Controller shall return an HCI_Command_Complete
event with a failure status indicating the Invalid HCI Command
Parameters error code.
In practice, this can also be generated if flow control is inadvertedly
turned off during operation. Running `hci_cmd_done` is not correct when
the event happens (as there is no corresponding command buffer), and
`ncmd` should not be returned as this command ignores the semaphore when
sending.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Links host to mbedTLS library if Bluetooth Mesh is enabled, and
CONFIG_BT_TESTING=y.
Bluetooth Mesh has test dependencies in the host.
In order to compile Bsim tests with these test features
and PSA enabled, the libraries must be linked.
Signed-off-by: Anders Storrø <anders.storro@nordicsemi.no>
Rename the Kconfig option from BT_ISO_ADVANCED to
BT_ISO_TEST_PARAMS to more explicitly denote that it
enables support for using the ISO test parameters.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
When compiling conn.c using arm-none-eabi-gcc version 11.3.1 20220712
with the -Wmaybe-uninitialized flag a warning is emitted due to
pending_no_cb not being initialized. I'm not sure if initializing it to
NULL is the "correct" fix, but it's certainly not any worse then it being
uninitialized, and it fixes the warning.
Signed-off-by: Dennis Grijalva <dennisgrijalva@meta.com>
Connection states are non-trivial to understand based on their names
only, so add short descriptions in the header file explaining what they
do.
Signed-off-by: Carles Cufi <carles.cufi@nordicsemi.no>
A few of the length checks that deal with HCI packets coming from the
controller were using assert statements. But the recommended practice is
to drop invalid packets and continue execution whenever a malformed
packet arrives from an external source, so replace those assert
statements with branches that will drop the packet and return.
Signed-off-by: Carles Cufi <carles.cufi@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>
Added run-time BT_CENTRAL role check for the path that was
central specific and did not have such check.
When multi-role BT device tried to pair without bonding (peripheral role)
while already previously bonded with the same device on another
Bluetooth identity, pairing failed.
It executed central-specific code, which should not be executed in case
when the device acts as peripheral (as it is even opt-out from code when
CONFIG_BT_CENTRAL is not enabled).
Signed-off-by: Mateusz Kapala <mateusz.kapala@nordicsemi.no>
BT_SECURITY_FORCE_PAIR option gets overridden when CONFIG_BT_SMP_SC_ONLY
or CONFIG_BT_SMP_OOB_LEGACY_PAIR_ONLY is defined. Cache the bit value
before overrides.
Add explicit forced pair handling to existing security level check.
Functionality did not change as this was done implicitly due to integer
comparison for enums.
Add extra clarification to the method doc.
Signed-off-by: Rait Rääk <raitraak@gmail.com>
iso_has_ts wasn't set correcrly for fragments of HCI ISO Data packets,
now it is set depending on timestamp
provided in the original buffer provided by host user
Signed-off-by: Ivan Iushkov <ivan.iushkov@nordicsemi.no>
this commit partially reverts e460847b60
According to Core Spec 5.4, Vol. 4, Part E, 5.4.5, Data_Total_Length field
contains length of the whole packet including optional fields of SDU
(Time_Stamp, Packet_Sequence_Number, ISO_SDU_Length, RFU and
Packet_Status_Flag). In Zephyr Host, Data_Total_Length value
is stored in bt_dev.le.iso_mtu field.
Therefore, there is no need to calculate iso_hdr_len(),
this length is already taken into account in conn_mtu(conn).
This commits removes iso_hdr_len() function and fixes
calculation of HCI ISO Data packet length calculations.
Signed-off-by: Ivan Iushkov <ivan.iushkov@nordicsemi.no>
The firmware on these devices seems to have a bug that can cause reordering
of received packets. This can lead to new GATT requests being received
before the acknowledgement of the previous GATT response, accompanied by
log messages like the following:
<wrn> bt_att: bt_att_recv: Ignoring unexpected request
Signed-off-by: Armin Brauns <armin.brauns@embedded-solutions.at>
The purpose of this test is to prove that the zephyr host can handle the
behavior described in the Bluetooth Core Specification Vol.3 Part.F
3.3.2 "Sequential protocol".
The host should be able to handle all of those in parallel: one
indication, one write request, multiple commands and multiple
notifications.
The "tester" part had to be written with a "tiny host" implementation
instead of the Zephyr host, as the ZH conflates GATT client and server
and doesn't allow a device to enqueue an ATT request + an ATT indication
on the same bearer.
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>
bt_iso_cig_reconfigure would almost always fail due to invalid
checks that did not take the functioner properly into account.
The CIS provided to bt_iso_cig_reconfigure can now be allocated
beforehand, if the CIG for the CIS is the same as the one being
reconfigured.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
In `gatt_write_ccc_rsp`, the third field of
`SYS_SLIST_FOR_EACH_NODE_SAFE` was use as the `prev` sys_node when
calling `gatt_sub_remove`. This was wrong because the third field of
`SYS_SLIST_FOR_EACH_NODE_SAFE` is actually the next node.
Fix the issue by adding a pointer to the previous node and passing it to
`gatt_sub_remove`.
Signed-off-by: Théo Battrel <theo.battrel@nordicsemi.no>
This requirement was implicit as the only backend the host is currently
tested with behaves this way.
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>
The bt_conn_exists_le is commonly hit by users attempting
to connect (either as central or peripheral) to a device
they are already connected to in some way. The current log statement
does not provide particularly much information, so added more.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Makes the long workqueue init priority configurable and sets
the default to 50, this is to allow for relocating bluetooth
libraries to other parts of memory e.g. external flash, and
allows for those flash drivers to be initialised prior to
calling functions residing in them.
Signed-off-by: Jamie McCrae <jamie.mccrae@nordicsemi.no>
If the central disconnects a CIS while it is being
established, then we receive both a CIS established event
with BT_HCI_ERR_OP_CANCELLED_BY_HOST and a disconnect complete
event.
In this case we should not call bt_iso_disconnected in the
CIS established event handler, as that will also be
called from the disconnect complete event handler.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
As per the core spec, the CIS is not allowed to disconnect
a CIS if it is pending (i.e. in the connecting state).
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
If the bonding information has been cleared before pairing had a chance
to complete (probably by the application), indicate this by setting an
appropriate log message.
Also check that keys exist before calling `bt_keys_store`.
Fixes#59788 and #61465
Signed-off-by: Théo Battrel <theo.battrel@nordicsemi.no>
Fix an issue in the CCC configuration when the Peripheral device
maintains two or more distinct connections on different identities
with the same peer. The issue occurs when the local device performs
the pairing and the bonding procedure on a connection associated
with one of the Bluetooth identities. During the identity resolution,
the peer address field in the CCC descriptor is converted from the
RPA-type address to the Identity Address. However, the destination
address on the remaining connection objects associated with other
Bluetooth identities is not converted. Due to this, their CCC
configuration is reset and GATT indications and notification fail
to be sent even if the Central device subscribed to them.
Added necessary code to iterate over all connection objects during
the identity resolution phase and aligned their destination address
from the RPA-type to the Identity Address.
Signed-off-by: Kamil Piszczek <Kamil.Piszczek@nordicsemi.no>
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>
bt_l2cap_chan_send_sdu previously returned the number of bytes sent
in the last sent sdu buf fragment or 0 if the buf has only
one fragment. bt_l2cap_chan_send_sdu now returns the total data
bytes sent from the buf.
Signed-off-by: Tom Finet <tom.codeninja@gmail.com>
Fix a bunch of mismatched CONTAINER_OF, few missing
k_work_delayable_from_work conversions but also many
bt_l2cap_le_chan/bt_l2cap_chan and few others.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
Fix few instances of delayable work handlers using the k_work pointer
directly in a CONTAINER_OF pointing to a k_work_delayable.
This is harmless since the k_work is the first element in
k_work_delayable, but using k_work_delayable_from_work is the right way
of handling it.
Change a couple of explicit CONTAINER_OF doing the same work as the
macro in the process.
Signed-off-by: Fabio Baltieri <fabiobaltieri@google.com>
When calling `bt_iso_chan_disconnect()` while the channel is
connecting, the host should simply use HCI Disconnect.
Note: For the peripheral it is not allowed to call HCI Disconnect
on a CIS after it has accepted the CIS request, but before it has
received the CIS established event. The implementation in this
commit does not fix this case. In that case the controller will
return an error code.
Also, this commit does not handle the events following the
HCI Disconnect correctly.
In this particular case, two events are raised by the controller.
See Core_v5.4, Vol 6, Part D, Figure 6.51.
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
Fixes a race condition that could occur if the TX queue was read out
before iso_has_ts was set. In that case, the provided buffer is of
wrong length.
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
This fixes return error from notify_cb function that was never set up.
As the result, the functions like bt_gatt_notify_cb and bt_gatt_indicate
returned invalid error when failed to send notification.
Signed-off-by: Mariusz Skamra <mariusz.skamra@codecoup.pl>
Fixes a coverity-reported issue by explicitly ignoring the return value
of the cas-operation. The return value is the old value, but we are not
interested in it in the situation when we just want to initialize a
value if it is in the uninitialized state.
Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/60474
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@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>
The ATT module has provisions to queue a packet/buffer for sending later if
it can't send it right away. For example if the conn.c tx context
allocation fails.
This unfortunately doesn't work if the buffer can't get allocated in the
first place, or if the ATT metadata can't also be allocated.
The metadata is allocated from a global pool set to the same number as
conn.c TX contexts. That can lead to a situation where other users of ATT
manage to queue a bunch of buffers (e.g. the app spamming GATT
notifications), depleting the number of ATT metadata slots so that none are
available.
When none are available, and we receive an ATT REQ, we try to allocate one,
fail, and drop the buffer (!). That pretty much guarantees an ATT timeout.
As a workaround for this, use a per-channel metadata slot, that is only
used for completing transactions.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
This is useful in multilink scenarios, especially since there is not user
callback when the ATT channel times out.
Adding a user-facing callback should ideally also be done, but just logging
the address already provides useful insight.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Easier to debug that way.
Ideally we'd have more error codes/logging instead of just returning
UNLIKELY for most errors.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
When a PAwR sync connects to a PAwR advertiser and CONFIG_BT_PRIVACY
is enabled a Resolvable Private Address will be used. Use that
as responder address instead of the identity address to match what
the central sees.
Signed-off-by: Herman Berget <herman.berget@nordicsemi.no>
