Use BT_CONN_TX_USER_DATA_SIZE when defining pools of buffers that will go
through `bt_conn_send_cb()`.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
MTU doesn't count against the ISO and ISO data headers.
Then a config with CONFIG_BT_ISO_TX_MTU ==
CONFIG_BT_CTLR_ISO_TX_BUFFER_SIZE should not fragment SDUs over HCI.
Also set the TS_Flag bit if a timestamp is present.
Fixes#56749
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
The LOG_ERR was printing the wrong variable. `type` always has the value
`BT_BUF_H4` here, so there is no point in printing it.
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
The PAwR sync can receive a connection request from the PAwR
advertiser and become peripheral.
Signed-off-by: Herman Berget <herman.berget@nordicsemi.no>
This is known as the Periodic Advertising Connection Procedure.
The PAwR advertiser can initiate a connection to a synced device and
become the central.
Signed-off-by: Herman Berget <herman.berget@nordicsemi.no>
The reassembly buffer for periodic sync was not initialized
if the sync was established via PAST.
Move the initialization of the reassembly buffer to a common place.
Signed-off-by: Herman Berget <herman.berget@nordicsemi.no>
Adds API for Periodic Advertising with Responses - Scanner:
- Synchronize to a PAwR train
- Choose which subevents to synchronize to
- Receive advertising reports from subevents
- Send responses
The support is enabled by CONFIG_BT_PER_ADV_SYNC_RSP, and requires
a controller that selects CONFIG_BT_CTLR_SYNC_PERIODIC_RSP_SUPPORT.
Signed-off-by: Herman Berget <herman.berget@nordicsemi.no>
Adds API for Periodic Advertising with Responses - Advertiser:
- Configure parameters
- Receive subevent data requests
- Set subevent data
- Receive response reports
The support is enabled by CONFIG_BT_PER_ADV_RSP, and requires
a controller that selects CONFIG_BT_CTLR_ADV_PERIODIC_RSP_SUPPORT.
Signed-off-by: Herman Berget <herman.berget@nordicsemi.no>
The ATT_PENDING_SENT flag was still not being cleared in all cases.
Also reset `data->att_chan` when not able to send on a given channel.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
The API doesn't allow the stack to make any guarantees about the number of
available buffers that the app has.
Only send 1 credit at a time, as that is the only guarantee the stack can
give to the peer.
We can send MTU/MPS's worth of credits once we have acquired an SDU buffer
from the application (that is, on the first PDU of the SDU). Though we
still have to cap that to the buffer size we have just acquired.
------
The testcase added here shows a scenario where the relationship
between the number of credits and the number of available buffers does not
hold true any more:
In this test, the app only has one buffer in its pool.
The central will queue SDUs that are bigger than the stack's
buffers (so the user allocator is necessary) but lower than the
channel's MTU.
The device receiving the SDU keeps a reference to the buffer before
returning from the `recv` callback. It releases that reference after a
small delay.
The central will still have credits, so it will queue another SDU, but the
peripheral will not be able to receive the next SDU (as the allocator will
fail) and will close the channel.
To see the test fail, just revert the `l2cap.{c,h}` changes.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Turns out the [first bugfix] was too naive: there is a case where resuming
all channels will not work on all queued SDUs, and the work handler will
give up and wait for the next sent SDU instead of trying to resume again.
This happens when the number of credits and conn contexts is very low for
the amount of data to send.
Always reschedule with a delay to avoid that situation.
[first bugfix]: https://github.com/zephyrproject-rtos/zephyr/pull/50476
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Refactoring. All occurences of `atomic_test_bit((.*)->flags,
ATT_ENHANCED)` are replaced with `bt_att_is_enhanced($1)`.
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
The EATT MTU in Zephyr is static. We know it at channel creation time,
so we should communicate the MTU as part of channel creation.
Side note: With this approach, it should no longer be neccessary or
useful to do a channel reconfigure.
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
The previous approach with `cap_eatt` was flawed. It would overwrite
`le_chan->tx.mtu`, losing its true value. (It is supposed to be the
L2CAP MTU as reported by the remote side.)
The previous approach worked out for UATT because the locally triggered
exchange always carries the remote MTU in the response, so we did not
need to keep track of the remote MTU.
But, unlike the UATT MTU exchange, the L2CAP reconfigure only exchanges
the MTU in one direction. If the remote does the first reconfigure, we
would correctly cap the ATT MTU to our local MTU. But, we would
incorrectly store this as the remote's MTU. When we then increase our
local MTU using `bt_eatt_reconfigure`, we correctly set and send our
MTU. But we have an incorrect notion that the remote MTU is the value
that we ourselves limited. And mistake would incorrectly limit the
negotiated ATT MTU locally.
The simplest solution is to not mess with `le_chan->tx.mtu` and just
calculate the ATT MTU like Spec intended.
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
This is a refactor. There is no behavioral change because
`BT_LOCAL_ATT_MTU_UATT` is `BT_LOCAL_ATT_MTU_EATT + 2` is
`BT_ATT_BUF_SIZE` is the old `BT_ATT_MTU`.
The old `BT_ATT_MTU` was wrong for EATT bearers. EATT MTU is two bytes
less because of ECRED overhead.
Instead of the old `BT_ATT_MTU`, we define one for each bearer type. We
also define the max of them to use as a convenience for allocating
buffers that fit either.
To avoid confusion, 'LOCAL' has been added to the name. This is to
differentiate it from what the spec calls 'ATT MTU', which is a
negotiated property. (It is the minimum of the two side's local ATT
MTU.)
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
There is an assert that `req_psm` is the same for all channels in the
same connection request because HCI requires this. The same is true for
`req_mtu`. This adds the obviously missing assert.
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
This is a refactoring, only visible inside `att.c`.
Give the expression `chan->chan.tx.mtu` the name `bt_att_mtu`. Use it
when the intention is to get the ATT MTU property of a channel.
This is done in preparation a more complex expression for `bt_att_mtu`,
since the expression currently incorrect. The fix will come in a later
commit in the same PR.
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
Commit gets rid of host dependency to generate DH key.
Mesh uses its own function for it that has synchronous
behavior and correct endianism. It simplifies the provisioning
state machine since it doesn't require waiting for the host HCI
handler.
Also, it removes hidden cross-dependency between BLE Mesh and
SMP in the aspect of competition for the same DH key
(https://github.com/zephyrproject-rtos/zephyr/issues/23292)
Signed-off-by: Aleksandr Khromykh <aleksandr.khromykh@nordicsemi.no>
The init infrastructure, found in `init.h`, is currently used by:
- `SYS_INIT`: to call functions before `main`
- `DEVICE_*`: to initialize devices
They are all sorted according to an initialization level + a priority.
`SYS_INIT` calls are really orthogonal to devices, however, the required
function signature requires a `const struct device *dev` as a first
argument. The only reason for that is because the same init machinery is
used by devices, so we have something like:
```c
struct init_entry {
int (*init)(const struct device *dev);
/* only set by DEVICE_*, otherwise NULL */
const struct device *dev;
}
```
As a result, we end up with such weird/ugly pattern:
```c
static int my_init(const struct device *dev)
{
/* always NULL! add ARG_UNUSED to avoid compiler warning */
ARG_UNUSED(dev);
...
}
```
This is really a result of poor internals isolation. This patch proposes
a to make init entries more flexible so that they can accept sytem
initialization calls like this:
```c
static int my_init(void)
{
...
}
```
This is achieved using a union:
```c
union init_function {
/* for SYS_INIT, used when init_entry.dev == NULL */
int (*sys)(void);
/* for DEVICE*, used when init_entry.dev != NULL */
int (*dev)(const struct device *dev);
};
struct init_entry {
/* stores init function (either for SYS_INIT or DEVICE*)
union init_function init_fn;
/* stores device pointer for DEVICE*, NULL for SYS_INIT. Allows
* to know which union entry to call.
*/
const struct device *dev;
}
```
This solution **does not increase ROM usage**, and allows to offer clean
public APIs for both SYS_INIT and DEVICE*. Note that however, init
machinery keeps a coupling with devices.
**NOTE**: This is a breaking change! All `SYS_INIT` functions will need
to be converted to the new signature. See the script offered in the
following commit.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
init: convert SYS_INIT functions to the new signature
Conversion scripted using scripts/utils/migrate_sys_init.py.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
manifest: update projects for SYS_INIT changes
Update modules with updated SYS_INIT calls:
- hal_ti
- lvgl
- sof
- TraceRecorderSource
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
tests: devicetree: devices: adjust test
Adjust test according to the recently introduced SYS_INIT
infrastructure.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
tests: kernel: threads: adjust SYS_INIT call
Adjust to the new signature: int (*init_fn)(void);
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
We should clear the bt_dev.sent_cmd pointer after using it to allocate a
new HCI event buffer in the bt_buf_get_cmd_complete() function.
Otherwise, there is a risk of reusing the same stored net_buf for
multiple consecutive HCI events in case the controller sents duplicate
or invalid event packets.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When central is sending SMP Pairing Request is it unknown if
pairing will be legacy or LE SC so set OOB flag if any OOB
data is present and assume to peer device provides OOB data
that will match pairing type.
This was affecting following qualification test cases:
SM/CEN/OOB/BI-01-C
SM/CEN/OOB/BV-01-C
SM/CEN/OOB/BV-03-C
SM/CEN/OOB/BV-09-C
Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl>
Various bluetooth tests fails to link because bt_le_ext_adv_set_data
can't be resolved. Solve this by adding a check CONFIG_BT_EXT_ADV
around use of bt_le_ext_adv_set_data.
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
Remove unnecessary guarding. With `BT_DEBUG` removed, those conditions
were not needed anymore.
Signed-off-by: Théo Battrel <theo.battrel@nordicsemi.no>
We get compile warnings of the form:
error: converting the result of
'<<' to a boolean; did you mean
'((__aeabi_ctype_table_ + 1)[(byte)] << 28) != 0'?
[-Werror,-Wint-in-bool-context]
if (!isprint(byte)) {
^
Since isprint (and the other is* functions) return an int, change check
to an explicit test against the return value.
Signed-off-by: Kumar Gala <kumar.gala@intel.com>
Remove Kconfig symbol `BT_DEBUG`. It was not useful anymore with the
previous logging updates.
Replace it, where it was used, by the file local debug symbol.
Signed-off-by: Théo Battrel <theo.battrel@nordicsemi.no>
conn->le.keys are set on-demand when actual security action happens and
it is possible that permission check needs to happen before those.
This fix regression in following qualification test cases:
GAP/SEC/AUT/BV-23-C
L2CAP/LE/CFC/BV-25-C
L2CAP/ECFC/BV-32-C
Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl>
Both L2CAP and GATT have same requirements with regards to error code
on no encryption when LTK is or isn't present.
Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl>
“Insufficient Encryption” shall be returned only if link is not
encrypted and proper LTK is present, otherwise “Insufficient
Authentication” shall be used.
Core Specification 5.4 Vol. 3 Part C 10.3.1
"If neither an LTK nor an STK is available, the service
request shall be rejected with the error code
“Insufficient Authentication”.
Note: When the link is not encrypted, the error code
“Insufficient Authentication” does not indicate that
MITM protection is required.
If an LTK or an STK is available and encryption is
required (LE security mode 1) but encryption is not
enabled, the service request shall be rejected with
the error code “Insufficient Encryption”."
This was affecting GAP/SEC/AUT/BV-11-C qualification test case.
Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl>
The fact of having such extern in iso_internal.h forces the source files
that include this header to include conn_internal.h. This breaks the
encapsulation of conn object.
Signed-off-by: Mariusz Skamra <mariusz.skamra@codecoup.pl>
Move all Kconfig symbols related to Bluetooth logging into the newly
created `Kconfig.logging`. The logging symbols are now grouped by into a
menu "Bluetooth logging". Closely related symbols are grouped with each
others. For example, audio related logging symbol are found behind a
submenu "Audio" inside the "Bluetooth logging".
The deprecated logging symbols have also been moved in a submenu of
"Bluetooth logging", it's easier to avoid them so.
Behavior of the Bluetooth logging system:
When `LOG` symbol is selected, if Bluetooth is enabled (`BT` symbol
selected), the Bluetooth logging is enabled.
If the user does not set any log level, the Bluetooth logging symbols
will inherit the log level of `BT_LOG_LEVEL`. If the user does not set
the level of `BT_LOG_LEVEL`, the default log level will be the one
defined by the logging subsystem. Which currently is `LOG_LEVEL_INF`.
Signed-off-by: Théo Battrel <theo.battrel@nordicsemi.no>
When receiving extended advertising reports with incomplete
data status, it is not necessary to mark for recovering from
currently assembled fragments, but rather drop them and
start a fresh assembly of subsequently received extended
advertising reports.
Timing changes in the Controller cause Periodic Advertising
PDUs AUX_SYNC_IND + AUX_CHAIN_IND to be placed between
primary channel ADV_EXT_IND and AUX_ADV_IND. This causes the
Controller to generate alternating incomplete and complete
data status reports, exposing the Host bug that is fixed in
this commit.
Relates to commit ba09a252ec ("bluetooth: host: refactor
bt_hci_le_per_adv_report data reassembly").
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
The ISO hci_le_cis_req event handler was missing
calls to bt_conn_unref and bt_iso_cleanup_acl to properly
clearn up the reference counters.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Added missing bt_conn_unref where bt_conn_lookup_handle is
called, but where the function returns without providing the
conn pointer to the caller.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
When we supply the conn pointer of the remote device that
provides the PAST information, we do a lookup on the
conn_handle using bt_conn_lookup_handle which takes a
reference count. This count is never dereferenced again.
This commit adds calls to bt_conn_unref to ensure that we
do not keep the reference count after the function
returns.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Unit test project for bt_pub_key_gen().
This is part of subsys/bluetooth/host/ecc.c unit testing.
Signed-off-by: Ahmed Moheb <ahmed.moheb@nordicsemi.no>
Move newly added `bt_data_get_len` and `bt_data_serialize` from `ead.c`
to `data.c`.
Also, removed unnecessary include of `zephyr/kernel.h`.
Signed-off-by: Théo Battrel <theo.battrel@nordicsemi.no>
Some systems can support only legacy OOB pairing while others only
LE SC OOB pairing.
The existent API function "bt_set_oob_data_flag" was removed.
Two new API functions were added:
* "bt_le_oob_set_legacy_flag" to signal that legacy OOB pairing is used
* "bt_le_oob_set_sc_flag" to signal that LE SC OOB pairing is used
The code will now advertise the presence of OOB flag depending
on the type of pairing method(SC vs legacy)
Signed-off-by: Sebastian Panceac <sebastian.panceac@ext.grandcentrix.net>
The BT_ISO_STATE_DISCONNECTING was never set when the
CIS was actually in the disconnecting state.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
In the case of a constrained system that uses dynamic channels (ie, not
much initial credits), the user's log would be flooded with those three
messages.
This is not really an error per se as the stack will handle it properly and
reschedule the sending of the buffers as soon as more credits arrive.
Thus downgrading the severity of
- the l2cap messages, as they are only compiled when dynamic channels are
enabled
- the conn message. Reporting the error belongs in the upper layers.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
This moves bt_data_parse function outside of hci_core.c.
Having it in separate file makes unit testing easier as the
function do not use kernel objects, thus can be used in unit tests
without a need for adding any mocks.
Signed-off-by: Mariusz Skamra <mariusz.skamra@codecoup.pl>
Most of this struct is bookkeeping for the dynamic channels.
This isn't needed for e.g., a simple peripheral using GATT.
With a peripheral_hr build for nrf52840dk_nrf52840, we save
280 bytes of RAM.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
