Adds HCI support for:
- LE CS Read Remote Supported Capabilities
- LE CS Read Remote FAE Table
Callbacks have been added to the conn object to allow upper layers to
make use of the cache commands, with which it will be possible to store
this information and provide it again in the case of a disconnect
and reconnect to the same device.
Signed-off-by: Olivier Lesage <olivier.lesage@nordicsemi.no>
We don't own the thread that calls the final `bt_conn_unref()`. The
users might not be aware that they are re-using that poor thread's
stack.
Putting it on the system workqueue gives a predictable stack size and
thread priority for the invocation of the recycled handlers.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Add a bool fn so there is some room for a comment explaining why this is
not guarded by an IS_ENABLED().
Also add an optimization when building with an onboard controller.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
The code was a bit hard to read. From what I understood, the intent is
to not send the PHY update if we are already on 2M symmetric.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
`conn_auto_initiate()` starts a bunch of controller procedures (read: HCI
commands) that are fired off right after connection establishment.
Right now, it's called from the RX context, which is the same context where
resources (cmd & acl buffers) are freed. This not ideal.
But the procedures are all async, so it should be fine to schedule this
function on the system workqueue, where we have less risk of deadlocks.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Rename `BT_CONN_AUTO_FEATURE_EXCH` to `BT_CONN_LE_FEATURES_EXCHANGED`,
and add some comments for readability.
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
To make the scanner module more understandable and more streamlined, I
reworked the update mechanism of the scanner. The scanner tracks now the
parameters that were used to enable it and the reason why it is running.
This facilitates state logic and allows other modules to "start the
scanner", altough it is already running.
This is mostly a refactoring and not a functional change.
Added a test to verify the behavior.
Signed-off-by: Jan Müller <jan.mueller@nordicsemi.no>
add to task
callback_list was renamed to conn_cbs in commit 3eb975d.
However plm callback was missed due to it not being built
anywhere.
Signed-off-by: Sean Madigan <sean.madigan@nordicsemi.no>
Trigger the TX processor on connection teardown.
When a disconnection happens before the controller has acknowledged some
ACL fragments the host has sent, we run `process_unack_tx()` to free
those unacknowledged buffers and their associated TX contexts.
The problem is that the TX processor still holds a reference to the conn
object. That reference is not released until the TX processor is
triggered again and figures out that the connection is invalid.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
This function call frees the buffer kept by the host for reassembling L2CAP
PDUs into.
Without this call, the current buffer will eventually be
leaked, leading to a non-functional host due to lack of RX buffers.
The effect is worse when host flow control is not enabled, as the RX
buffer pool is shared with events, which means communication with the
controller is essentially dead.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Don't push the TS flag on `buf` itself.
This messes up the MTU calculations: a packet that would exactly fit the
MTU and has a timestamp would be unnecessarily fragmented.
The MTU check is done on `buf` as a whole. At the point where the
fragmentation length is decided, `buf` includes one extra byte to pass the
TS bit around. That byte shouldn't count towards the MTU.
Instead, infer the presence of the timestamp by inspecting the amount of
headroom that the buffer has. This works because we always reserve
enough memory to push the timestamp, but not always push a timestamp on
the buffer. #tightlycoupled
This method is slightly uglier IMO, but eases MTU confusion and doesn't
rely on user_data.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Adds support for LE Connection Subrating as defined in Core 5.4
Vol 6, Part B, Section 5.1.19.
As this is primarily a controller feature, the host support is mostly
a wrapper around the relevant HCI commands.
Note that subrating provides a new method to update the connection's
peripheral latency and supervision timeout alongside subrating parameters.
Signed-off-by: Aleksandar Stanoev <aleksandar.stanoev@nordicsemi.no>
Refactor. The deferred work is rescheduled just after it's canceled.
This is hopefully equivalent to just the reschedule, so the cancel can
be removed.
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
The Softdevice Controller now sends the disconnect event only after
receiving all Host Num Completes for the packets it sent to the host.
This is done for security reasons.
In our current reassembly logic, it does not really matter when we
withhold the num complete.
Before this patch, it's the first fragment that is withheld, and after
the patch it will be the last fragment that is withheld until the host
is done processing.
The flow control properties are maintained, just in a different way.
Co-authored-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
When implementing vendor specific HCI APIs and events,
we want to be able to convert between host objects,
handles and back again.
Exposing this API makes that possible
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
The rationale behind that change is that the Application can use the
`bt_conn_le_param_update()` API to signal the controller to reschedule
the link.
Even if the new connection params are within the old ones, the
controller would be free to choose an e.g. smaller interval. The host
API should not prevent this usage.
Fixes https://github.com/zephyrproject-rtos/zephyr/issues/74292
Co-authored-by: Knut Eldhuset <knut.eldhuset@nordicsemi.no>
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
This is a bug-fix:
When upper layers want to send something, they add a `conn` object to a
list. They do so by adding a node on `struct conn` rather than the object
itself.
We forgot to increase the reference count of the connection object when
doing so. This means that there can be a scenario where the conn object is
destroyed and re-used while still being on the TX list/queue.
This is bad for obvious reasons.
This patch fixes that by:
- increasing the refcount when putting on the TX list
- decreasing the refcount *only* when popping off the TX list
- passing a new reference from `get_conn_ready` into `bt_conn_tx_processor`
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
The HCI command LE Read Supported States command returns
if the controller supports running the scanner and initiator
roles in parallel.
This commit utilizes this information in the host:
- It does not prevent initiating a connection when the scanner is
running
- It does not prevent the host from restarting the background
scanner when there the host wants to auto-initiate a connection.
- It does not stop the scanner when the host wants to auto-initiate
a connection.
To support this feature, the scanner and initiator
always have to use the same address.
This because the HCI command LE Set Random Address
cannot be issued after the initiator or scanner has started.
1. When privacy is disabled, the scanner has to use its identity
address to ensure it uses the same address as the initiator.
2. Only one identity is supported.
To simplify the implementation, it is a requirement to use
extended advertising commands to avoid interfering with
the random address used by the advertiser(s).
Also, it is a requirement to never use time-limited scanning,
as RPA this feature does not work when privacy is being used.
See https://github.com/zephyrproject-rtos/zephyr/issues/73634.
The changes in this commit will be tested out of tree as the
Zephyr Bluetooth Controller does not support this functionality.
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
Returning a status code will allow the application developer
to detect logic issues.
We consider this as not breaking the API.
If `-Werror -Wunused-result` is enabled, the application developer needs
to validate the return code.
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
Callbacks can only be registered once. Otherwise the slist
will become circular.
In this commit we have choosen to ignore the second registration
call if the callback has already been registed. The alternative
is to trigger an assertion. That doesn't work if the assertions
are turned off.
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
This allows us to use functionality provided by slist.
First use case: Avoid adding an element twice.
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
View buffers are now also a limited resource. Acquire them before
attempting to pull data. `CONFIG_BT_CONN_FRAG_COUNT` should be tuned on
a per-application basis to avoid this.
A possible optimization, that was present before, is to not create a
frag when the original buffer fits the controller's HCI size.
I prefer deferring this optimization to a future patchset.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
We can get rid of the view pool for SDU segments :)
We have to make the code slightly more complex :'(
The basic idea is always giving the original SDU buffer to `conn.c` for it
to pull ACL fragments from.
In order to do this, we need to add the PDU headers just-in-time.
`bt_l2cap_send_pdu()` does not add them before putting the PDU on the queue
anymore. They are added by `l2cap_data_pull()` right before the data leaves
`l2cap.c` for `conn.c`.
We also have to inform `conn.c` "out of band" of the real L2CAP PDU size so
it doesn't fragment across segment boundaries. This oob is the new `length`
parameter to the `.pull()` method.
This is the added complexity mentioned above.
Since SDU segmentation concerns only LE-L2CAP, ISO and Classic L2CAP don't
need this extra logic.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
We don't need the TX thread anymore.
Generalizing the pull-based architecture (ie. `tx_processor`) to HCI
commands makes it possible to run the whole TX path from the the system
workqueue, or any workqueue really.
There is an edge-case, where we call `bt_hci_cmd_send_sync()` from the
syswq, stalling the system. The proposed mitigation is to attempt to drain
the command queue from within `bt_hci_cmd_send_sync()`.
My spidey sense tingles however, and it would be better to just remove the
capability of calling this fn from the syswq. But doing this requires
refactoring a bunch of synchronous procedures in the stack (e.g. stack
init, connection establishment, address setting etc), dragging in more
work. I will do it, but in a later patch.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
The current TX pattern in the host is to try to push a buffer through all
the layers up until it is ingested by the controller.
Since sending can fail at any layer, we need error-handling and separate
retry logic on pretty much all layers. That logic obscures the "happy path"
for people trying ot understand the code.
This commit inverts the control, in a way that doesn't require changing the
host or HCI driver API (yet):
Layers don't send buffers synchronously, they instead put their buffer in a
private queue of their own and raise a TX flag on the lower layer. Think of
it as a `READY` interrupt line that has to be serviced by the lower layer.
Sending is now non-blocking, rate depends on the size of buffer pools.
There is a single TX processing function. This can be thought as the
Interrupt Service Routine that will handle the `READY` interrupt from the
layers above.
That `tx_processor()` will then attempt to allocate enough resources in
order to send the buffer through to the controller. This allocation logic
does not block.
After acquiring all the resources, the TX processor will attempt to pull
data from the upper layer. The upper layer has to figure out which buffer
to pass to the controller. This is a good spot to put scheduling or QoS
logic in the upper layer.
Notes:
- user-facing API for tuning QoS will be implemented in a future patch
- this scheme could (and probably will) be extended to upper layers (e.g.
ATT, L2CAP CoC segmentation).
- this patch removes the `pending_no_cb()` memory optimization for
clarity/correctness. It might get re-implemented after a stabilization
period. Hopefully with more documentation.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Co-authored-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
Instead of allocating segments/fragments and copying data into them, we
allocate segments as "views" (or slices) into the original buffer.
The view also gives access to the headroom of the original buffer, allowing
lower layers to push their headers.
We choose not to allow multiple views into the same buffer as the headroom
of a view would overlap with the data of the previous view.
We mark a buffer as locked (or "in-view") by temporarily setting its
headroom to zero. This effectively stops create_view because the requested
headroom is not available.
Each layer that does some kind of fragmentation and wants to use views for
that needs to maintain a buffer pool (bufsize 0, count = max views) and a
metadata array (size = max views) for the view mechanism to work.
Maximum number of views: number of parallel buffers from the upper layer,
e.g. number of L2CAP channels for L2CAP segmentation or number of ACL
connections for HCI fragmentation.
Reason for the change:
1. prevent deadlocks or (ATT/SMP) requests timing out
2. save time (zero-copy)
3. save memory (gets rid of frag pools)
L2CAP CoC: would either allocate from the `alloc_seg` application callback,
or worse _steal_ from the same pool, or allocate from the global ACL pool.
Conn/HCI: would either allocate from `frag_pool` or the global ACL pool.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
Co-authored-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
`bt_conn_send_cb` used to allocate a TX context (K_FOREVER).
Instead, we now put the context in the userdata of the buffer.
This means that now this fn will never block and always succeed since the
tx_queue is a FIFO (infinite size). It just puts the buf on the queue.
The metadata is stored safely in there until we have acquired all the
necessary resources to send it to the controller without failing: TX
context and controller buffer.
I.e. when `bt_conn_process_tx` is called, that's when a TX context is
try-allocated and the contents of `buf->userdata` is moved into it.
The buffer is now ready to be sent to the lower layer.
`bt_conn_process_tx` will return -EWOULDBLOCK if it's not able to acquire a
TX context, this PR modifies `bt_conn_prepare_events` to respond to this by
also waiting on the TX context pool.
Unfortunately, this increases the required userdata size for any buffers
handed to `bt_conn_send_cb`. This will be fixed in a later commit.
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
https://github.com/zephyrproject-rtos/zephyr/pull/72674 fixed
a bug where this configuration did not work.
Now that this configuration is tested, we should mark it
as supported.
The timeout check that was present in the code before
was useless and was not working because the check was
run before a default timeout of 0 was converted to a timeout.
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
This commit adds host support for the Path Loss Monitoring
feature see Bluetooth Core specification, Version 5.4,
Vol 6, Part B, Section 4.6.32.
Limited logic is required, just adding a wrapper around the
HCI command and callback for HCI event.
Add new zone - BT_CONN_LE_PATH_LOSS_ZONE_UNAVAILABLE, to
convert 0xFF path loss to a useful zone.
Add new Kconfigs and functionality to the bt shell.
Signed-off-by: Sean Madigan <sean.madigan@nordicsemi.no>
These are safety checks to guard against silent data corruption. The
implementation currently does not clobber bufs, but soon it will. The
bufs will be zero-copy segmented and fragmented, which involves
overwriting already-sent contents with headers for the next fragment.
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
If bt_conn_set_state(conn, BT_CONN_DISCONNECTED) is called
while the connection is already disconnected, this triggers
a warning. This is likely to happen when bt_conn_cleanup_all
is called as part of bt_disable.
Added the state check to avoid unnecessary warnings in the log.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
Calling bt_disable in system workqueue context while BLE connected may
lead to calling wait_for_tx_work in this context. Fix check in code to
avoid assertion failure.
Signed-off-by: Marek Pieta <Marek.Pieta@nordicsemi.no>
We can't just keep blocking the syswq, people be mad.
Override the timeout value so we always have K_NO_WAIT.
Also print a message to whomever's listening.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
To make it easier to understand the code, the following was done:
- Use INITIATING/ADV for state names that are exclusive to central
or peripheral. Previously it was not necessarily clear that the state
BT_CONN_CONNECTING was for central only by just looking at where
it was used. The terms INITIATING/ADV were used in favor
of central and peripheral as these terms also work for SCO connection
establishment.
- BT_CONN_CONNECTING_SCAN -> BT_CONN_SCAN_BEFORE_INITIATING
to make it more clear that we are not scanning and connecting at
the same time. The new name should make it more clear why we are
scanning - only with the intention to start the initiator later.
- BT_CONN_CONNECTING_AUTO -> BT_CONN_INITIATING_FILTER_LIST.
This makes it clear that this state is something different than
BT_CONN_AUTO_CONNECT.
Signed-off-by: Rubin Gerritsen <rubin.gerritsen@nordicsemi.no>
Recently (during Bluetooth UPF), a lot of developers experience
confusion due to weird errors in SMP, etc, which are actually irrelevant
and caused by the connection never having existed.
As a stop-gap measure, until upper layers properly report lower layer
failures, add a warning in the logs to stop wasting developer time.
Signed-off-by: Aleksander Wasaznik <aleksander.wasaznik@nordicsemi.no>
Remove SCO security management code block.
Currently, security related checks are not
necessary. It can be added if needed.
Signed-off-by: Lyle Zhu <lyle.zhu@nxp.com>
Currently, SCO connections and disconnections
are agnostic to upper-layer.
Add two functions, bt_sco_connected and
bt_sco_disconnected, to notify the SCO
connect changes.
For Central side, pass "struct bt_sco_chan"
object when calling bt_conn_create_sco. it
uses to manage the SCO channel for upper-
layer.
For Peripheral side, two functions
bt_sco_server_register and
bt_sco_server_unregister are added to monitor
SCO connection request for upper-layer. The
upper-layer could accept or reject SCO connect
When the connection request received. If the
connect is accepted, the "struct bt_sco_chan"
object could be passed by "sco_server->accept".
Signed-off-by: Lyle Zhu <lyle.zhu@nxp.com>
My recent change overlooked this configuration, which is not tested in CI
currently.
If someone had enabled it, they would've just gotten an unfixable assert.
The correct test would be checking if the current thread is the system wq,
but I think the compiler can't know that and can't remove the "dead" code.
Signed-off-by: Jonathan Rico <jonathan.rico@nordicsemi.no>
If no callbacks have been registered then callback_list
is NULL, in which case we can skip searching.
This also fixes a NULL-pointer acces in the while loop
as previous_callback would be NULL when it gets
dereferenced as previous_callback->_next.
Signed-off-by: Emil Gydesen <emil.gydesen@nordicsemi.no>
