The sequence number is by the core spec defined as 16-bit.
We had implemented a workaround for the wrapping of the
sequence number, which required the type to be larger
than 16-bit (32-bit).
However, since the definition of the sequence number,
and the use of, is poorly defined by the core spec, we
are reverting this workaround and reducing the sequence
number to 16-bit again. This way it is more in line
with the core spec, as well as more intuitive given the
other uses for the sequence number.
This change moves the responsibility of using the
right value to the upper layers, as the stack can
and will no longer provide any guarantees.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
bt_id_del() was setting the bit 'BT_KEYS_ID_PENDING_ADD' instead
of setting the bit 'BT_KEYS_ID_PENDING_DEL'
Signed-off-by: Ahmed Moheb <ahmed.moheb@nordicsemi.no>
Increment the number of identities after a successful execution
of id_create() by checking if the return value is 0.
Signed-off-by: Ahmed Moheb <ahmed.moheb@nordicsemi.no>
Document `bt_irk.rpa` as "Cache for `bt_keys_find_irk`. Not reliable as
"current RPA"!".
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
There should be functional equivalence between these two forms. And the
'_eq'-form is more readable.
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
The "limit" field of struct k_sem was in use in two places in the BTLE
host code, in one it was being used as a duplicate placeholder for the
"iso_max_num" field received in read_buffer_size_v2_complete[1]. In
another, it was just being tested for zero[2].
Those are pretty clear abuses of internal data, provide minimal value
beyond a few bytes of memory in struct bt_dev_le, and in any case
won't work with zync, where that field doesn't have the same name and
may not even exist depending on app configuration.
Copy the limit value into the struct where it belongs, and use it from
there.
[1] I strongly suspect there is a bug lurking there if the semaphore
maximum is being used to implement the kind of "packet buffer" this
code looks like. Calling k_sem_give() on a "full" semaphore WILL NOT
BLOCK. It will just drop the increment on the floor and return
synchronously. Semaphores aren't msgqs or ringbuffers! But disabling
the max value feature in zync does not result in test failures, so
maybe this usage is safe.
[2] Again, this seems suspicious; a valid k_sem should never have a
zero in that field. Presumably this is really a test for "is
initialized", and so implies there's a mixed up initialization path
somewhere?
Signed-off-by: Andy Ross <andyross@google.com>
Zephyrs Host has by default enabled automatic resume of advertising
in case of disconnection when peripheral role is enabled.
The feature becomes a bit problematic in case of multirole usage.
For example assume a use case where a device is working as peripheral
and central, where it may establish single connection for each role.
In case there are two connections established and connection in
central role is dropped by peer, Host will automatically resume
advertising. After that an application can resume scanning, e.g.
in disconnected callback. That should not happen.
If one of connections was used for central role, it should not
be stolen by Host to run peripheral role. Host should verify
if a disconnected connection role was peripheral and then resume
advertising.
This approach will not break backward compatibility and change
correct resume behavior. What more, Host will follow an application
decisions about use of connection objects.
Signed-off-by: Piotr Pryga <piotr.pryga@nordicsemi.no>
Gives the application a two way mapping between array index
and a per_adv_sync object instead of current only per_adv_sync
obj -> index using bt_le_per_adv_sync_get_index.
Signed-off-by: Jakob Krantz <jakob.krantz@u-blox.com>
- Downgrade the warning emitted when we run out of channels.
- Only log a warning when failing to establish channels and the error is
not -ENOMEM.
- Add a debug log message in that case to hint what might've happened.
This should make it less confusing to the average user not aware of the
stack internals.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
This is a scary-looking warning for users, and should only really matter to
stack developers. It will eventually show up in the wild for embedded
devices that don't get updated to the latest and greatest.
Reword it to make it clear we are rejecting it, and it doesn't impact the
stack in any way.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
This makes it more user-friendly, in case no failed cb has been
registered so this error is printed out of context.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Reword the scary-looking `bt_hci_core; Malformed data` warning to show
where it is originating from.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
If a device sends an MTU that is bigger than our maximum tx buffer size,
that could cause assertion failures down the line.
This PR limits it to the maximum we support (CONFIG_BT_L2CAP_TX_MTU).
The issue has been observed with a gatt discovery procedure, but is likely
present in other places in att.c.
To reproduce it, we need two zephyr shell devices, with one having a larger
MTU than the other:
- connect
- do data length update to the bigger MTU
- set security to 2, EATT channels get connected
- launch a gatt discovery from the device with the larger MTU
- observe kernel panic on the other device when it attempts to add too much
memory to a net buf.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Log the LE Secure Connection (SC) LTK in a pairing procedure without
bonding when CONFIG_BT_LOG_SNIFFER_INFO is enabled.
Fixes: #50691
Signed-off-by: Joakim Andersson <joakim.andersson@nordicsemi.no>
When getting a channel timeout, l2cap_chan_destroy is called from the
rtx_work work item.
In that function we attempted to cancel the current work item, and sync on
it being cancelled. The kernel API says that this will block until the work
item completes execution, hence a deadlock.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
This callback allows use-cases where the SDU is much larger than the l2cap
MPS. The stack will then try to allocate using this callback if specified,
and fall-back on using the buffer's pool (previous behavior).
This way one can define two buffer pools, one with a very large buffer
size, and one with a buffer size >= MPS, and the stack will allocate from
that instead.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
See the code comments.
SDUs might enter a state where they will be blocked forever, as a
workaround, we nudge them when another SDU has been sent.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
There was an edge-case where we were sending back too much credits, add a
check so we can't do that anymore.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Add error message logging for Advertising enable/disable at
RPA timeout when the resolvable address is updated.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Fix resolvable address update after RPA timeout with
Extended Advertising support enabled. As Extended
Advertising HCI Commands are being used to start legacy
advertising, incorrectly the local random address was being
used instead of using the random address populated in the
Extended Advertising set. BT_DEV_RPA_VALID is not cleared
when Extended Advertising HCI commands are used, hence the
local random address is not updated and the incorrect use
of it did not make any change to the advertising when
disabled and enabled at RPA timeout.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
this changes adv_new_legacy to adv_get_legacy.
without this fix the function would return NULL if BT_EXT_ADV is enabled.
Signed-off-by: Jonas Woerner <jonas.woerner@online.de>
As per BAP_v1.0, Section 5.6.3.1:
If HCI is used when setting up their respective audio data paths,
and if the codec in use resides in the Bluetooth Host of the device
using the LE Setup ISO Data Path command, the Unicast Client and/or
Unicast Server shall:
* Write the LE Setup ISO Data Path command Codec_Configuration_Length
parameter with the value 0x00.
* Write octet 0 (Coding_Format) of the LE Setup ISO Data Path command
Codec_ID parameter with the value 0x03 (Transparent).
We can assume the codec in use resides in the Bluetooth Host default.
Signed-off-by: Hang Fan <fanhang@xiaomi.com>
The timestamp is not part of the SDU, and should
thus not be used to get the maximum SDU size.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
As of today <zephyr/zephyr.h> is 100% equivalent to <zephyr/kernel.h>.
This patch proposes to then include <zephyr/kernel.h> instead of
<zephyr/zephyr.h> since it is more clear that you are including the
Kernel APIs and (probably) nothing else. <zephyr/zephyr.h> sounds like a
catch-all header that may be confusing. Most applications need to
include a bunch of other things to compile, e.g. driver headers or
subsystem headers like BT, logging, etc.
The idea of a catch-all header in Zephyr is probably not feasible
anyway. Reason is that Zephyr is not a library, like it could be for
example `libpython`. Zephyr provides many utilities nowadays: a kernel,
drivers, subsystems, etc and things will likely grow. A catch-all header
would be massive, difficult to keep up-to-date. It is also likely that
an application will only build a small subset. Note that subsystem-level
headers may use a catch-all approach to make things easier, though.
NOTE: This patch is **NOT** removing the header, just removing its usage
in-tree. I'd advocate for its deprecation (add a #warning on it), but I
understand many people will have concerns.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
bt_keys_find_addr() is used to find key by both ID and address.
Following checks must continue to compare ID and address as well.
Or, we can compare key references which is faster.
Signed-off-by: Ahmed Moheb <ahmed.moheb@nordicsemi.no>
The CC/Codec Configuration in bt_iso_chan_path was
defined as an array of size 0. This meant that the
CC always had to be allocated right after the
bt_iso_chan_path struct.
This does not give a very flexible API, and also makes
it impossible for two bt_iso_chan_path to share the same
CC.
The API is modified so that the CC is simply a pointer
to a an array now.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
`bt_l2cap_chan_send_cb()` overwrote the buffer user data for internal
use. In the case where sending fails, this would be visible for the
caller. If the caller relied on the buffer user data to be unchanged,
this could cause unexpected behavior.
L2CAP tx metadata was also not freed in the error case.
Signed-off-by: Herman Berget <herman.berget@nordicsemi.no>
This commit clears cached random address in bt_dev when calling
bt_disable(). This change makes future calls of set_random_address()
function possible with previously used address value, after BLE stack
re-initialization. Without this change no HCI command was sent, see this
condition in set_random_address():
/* Do nothing if we already have the right address */
if (!bt_addr_cmp(addr, &bt_dev.random_addr.a)) {
return 0;
}
Signed-off-by: Adam Augustyn <adam.augustyn@hidglobal.com>
Normal usage for Bluetooth applications are getting close to or
already overflowing the default BT RX stack size of 1024.
For example:
- Discovery using the fixed ATT channel used 984 bytes.
- Discovery using an enhanced ATT channel used 1048 bytes,
which would lead to stack overflow using the default BT RX thread
stack size.
Signed-off-by: Herman Berget <herman.berget@nordicsemi.no>
When using periodic advertising list and receiving
hci_le_per_adv_sync_established event from controller with
an error code the bt_le_per_adv_sync_term_info would be
incorrectly populated with le_addr and sid. This is because
the current pending advertising sync object is not populated
with any le_addr and sid from bt_le_per_adv_sync_create as
those are not used when option
BT_LE_PER_ADV_SYNC_OPT_USE_PER_ADV_LIST is set.
Instead the bt_le_per_adv_sync_term_info shall be populated
with the le_addr and sid coming in the event from controller.
Signed-off-by: Jakob Krantz <jakob.krantz@u-blox.com>
This commit adds the `const` qualifier to the `addr` parameter of the
`bt_monitor_new_index` function because this parameter is and should
never be modified within this function.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This commit adds the `const` qualifier to the `addr` parameter of the
`find_sc_cfg` function because this parameter is and should never be
modified within this function.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
