This allows to move flash operations from the context that triggered
storing device key candidate to the mesh settings work item that runs
on the system workqueue. This is required to for a case where the mesh
settings work item is running on a separate thread instead of the system
workqueue to unblock the system workqueue eventually.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
This allows to move flash operations from the context that triggered
bt_mesh_provision or bt_mesh_reprovision to the mesh settings work item
that runs on the system workqueue. This is required to for a case where
the mesh settings work item is running on a separate thread instead of
the system workqueue to unblock the system workqueue eventually.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@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>
This deduplicates a code a bit by reusing existing bt_bap_stream_reset
function to unbind and detach the stream object.
Signed-off-by: Mariusz Skamra <mariusz.skamra@codecoup.pl>
This removes redundant bt_ascs structure pool that held the list of
ases per connection. The memory usage can be reduced by moving the conn
reference to bt_ascs_ase structure. This change reduces flash and RAM
memory usage.
Signed-off-by: Mariusz Skamra <mariusz.skamra@codecoup.pl>
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>
