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>
Prevent referencing inactive CISes by clearing state variables
after teardown. This was seen as necessary when having CISes on
different ACLs, and disconnecting ACLs in random order.
Signed-off-by: Morten Priess <mtpr@oticon.com>
In the broadcast sink when the streams disconnected (without
the PA disconnecting), the streams were not properly
removed from the sink's list of streams. This allowed
the same stream to be added to the list twice, which
would cause a infinite loop as the stream would
point to itself as the next.
Signed-off-by: Emil Gydesen <emil.gydesen@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>
This fixes loop over arrayed metadata/cc parameters. The paramaters have to
be pulled from the buffer, because in case the ASE_ID is invalid or in
invalid state, the next loop iteration would read invalid data.
Signed-off-by: Mariusz Skamra <mariusz.skamra@codecoup.pl>
Add configurations where CONFIG_BT_AUDIO_TX and CONFIG_BT_AUDIO_RX
are disabled.
Fixes issues found in the BT shell implemented caused by these
configurations.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Move the BT_AUDIO_TX guard so that it does not cover the
verification functions for valid_codec and qos, as they
are also relevant for receivers to verify what remote
devices send.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
This adds callbacks for Secure and Private Network Beacons.
SNB callbacks are called after `secure_beacon_authenticate` ends
with success, and Private Beacon callback after Private Beacon
payload is decrypted succsessfully.
Signed-off-by: Krzysztof Kopyściński <krzysztof.kopyscinski@codecoup.pl>
This removes opcode from ascs_cp_rsp_add function parameters and moves
response buffer initialization to be done in Control Point write
function context.
Signed-off-by: Mariusz Skamra <mariusz.skamra@codecoup.pl>
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>
This moves ASE Control PDU length validation before request processing.
If the PDU length is not as expected, the operation shall be considered
as invalid. Thus shall be rejected.
ASCS_v1.0; 5 ASE Control operations
"A client-initiated ASE Control operation shall be defined as an invalid
length operation if the total length of all parameters written by the
client is not equal to the total length of all fixed parameters plus
the length of any variable length parameters for that operation"
Signed-off-by: Mariusz Skamra <mariusz.skamra@codecoup.pl>
This fixes sending proper Response_Code in ASE Control Point
notification in case the client initiates Receiver Start/Stop Ready
operation on Sink ASE.
The response that shall be sent according to the specification is
"Invalid ASE direction", while the implementation sent "Invalid ASE state"
instead.
Signed-off-by: Mariusz Skamra <mariusz.skamra@codecoup.pl>
Add verbose output of scan data to output all received data types as
hex values. This is turned off by default and can be toggled using
the bt scan-verbose-output <on|off> command.
Signed-off-by: Martin Rieva <mrrv@demant.com>
Change the default value of past_preference to true, to prefer
PAST by default when using the scan delegator.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
When copying the stream specific codec configuration data,
the value pointer in the bt_data struct was not properly
updated, causing possible invalid data access.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
The bt_cap_initiator_unicast_audio_update function was missing
NULL and 0 checks for input parameters.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Use the minimum supported cis_offset_min considering that
ACL radio event does not overlap with CIG event. Use the
calculated maximum of local and remote cis_offset_min in the
Response PDU.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
Commit adds experimental support mbedtls psa as crypto
backend for ble mesh. It were run only on bsim tests.
Signed-off-by: Aleksandr Khromykh <aleksandr.khromykh@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>
Commit splits mesh crypto module on security library dependent
and independent parts.
Independent part includes security toolbox implementation.
Dependent part includes security algorithms usage based on
API third party security library.
Signed-off-by: Aleksandr Khromykh <aleksandr.khromykh@nordicsemi.no>
Fix Advertising PDU size calculation when direction finding
feature is enabled and PDU fragment count includes the
maximum CTE PDU chained. Fix removes redundant PDU count
included for Extended Advertising. Only Periodic advertising
PDUs chain CTE requires number of additional PDUs.
Signed-off-by: Vinayak Kariappa Chettimada <vich@nordicsemi.no>
When ISO Central is enabled it is allowed to configure many CISes at
once. For this a large command buffer is needed. This is also tested
by HCI/CIS/BI-05-C.
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
If device running BLOB Server called `bt_mesh_blob_srv_recv`,
but rebooted before it received `XFER_START` message from BLOB Client,
it was wrongly "recovered" into Suspended phase, which would lead to
Server try to resume transfer on `XFER_START`. It would not be possible,
because `srv->state.xfer` was not set with acual values yet.
Set phase again to BT_MESH_BLOB_XFER_PHASE_WAITING_FOR_START, which will
allow to accept new transfer.
Signed-off-by: Krzysztof Kopyściński <krzysztof.kopyscinski@codecoup.pl>
