If relay feature doesn't have own adv set, it should use the main adv
set to send messages.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
Move the network buffer header file from zephyr/net/buf.h to
zephyr/net_buf.h as the implementation now lives outside of the networking
subsystem.
Add (deprecated) zephyr/net/buf.h header to maintain compatibility with old
file path.
Signed-off-by: Henrik Brix Andersen <henrik@brixandersen.dk>
This commit allows to suspend the mesh stack from `bt_mesh_send_cb`
callbacks by removing the deadlock caused by `k_work_flush` in the
extended advertiser.
In case of the extended advertiser there are 2 cases:
- when the `bt_mesh_adv_disable` is called from any of `bt_mesh_send_cb`
callbacks which are called from the advertiser work item, or
- when it is called from any other context.
When it is called from `bt_mesh_send_cb` callbacks, since these
callbacks are called from the delayable work which is running on the
system workqueue, the advertiser can check the current context and its
work state. If the function is called from the advertiser work, it can
disable the advertising set straight away because all ble host APIs have
already been called in `adv_start` function. Before sending anything
else, the advertiser checks the `instance` value in `adv_start`
function, which is also reset to NULL in `bt_mesh_adv_disable` call, and
aborts all next advertisements. The `ADV_FLAG_SUSPENDING` tells the
advertiser work to abort processing while `bt_mesh_adv_disable` function
didn't finish stopping advertising set. This can happen if the work has
been already scheduled and the schedler ran it while sleeping inside
the `bt_le_ext_adv_stop` or `bt_le_ext_adv_disable` functions.
When `bt_mesh_adv_disable` is called from any other context or from the
system workqueue but not from the advertiser work, then `k_work_flush`
can be called safely as it won't cause any deadlocks.
The `adv_sent` function is inside the `bt_mesh_adv_disable` function to
schedule the advertiser work (`send_pending_adv`) and abort all pending
advertisements that have been already added to the pool.
In case of the legacy advertiser, if the `bt_mesh_adv_disable` is called
form the advertiser thread (this happens when it is called from
`bt_mesh_send_cb.start` or `bt_mesh_send_cb.end` callbacks), then
`k_thread_join` returns `-EDEADLK`. But the `enabled` flag is set to
false and the thread will abort the current advertisement and the
pending advertisements.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
This commit removes extra rescheduling in the extended advertiser after
the last advertising has been finished. This commit also removes the
`ADV_FLAG_SCHEDULED` flag as not needed anymore.
This extra rescheduling and the flag were needed to delay the next
advertisement by 20ms. Now, when the delay is removed the advertiser can
pick the next advertisement from the pool and push to the host right
away.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
If `CONFIG_BT_MESH_GATT_SERVER` is disabled or the advertising set
doesn't support proxy adv, the solicitation PDU will not be sent.
However, solicitation PDU transmission doesn't depend on the proxy
feature of the device it sends. Therefore, solicatation PDU should be
sent regradless of `CONFIG_BT_MESH_GATT_SERVER` option and advertiser
tag.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
Return error code to let an implementation know if the adv was actually
stopped (was scheduled) or not.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
Before this change, the bt_mesh_send_cb.end callback was called when all
references to the adv were removed. If an implementation kept more
references to the adv buffer after calling `bt_mesh_adv_send`, the end
callback would not be called when the advertiser finished advertising
this adv.
With this change, the end callback is always called by the advertiser
when the advertisement is finished regardless of the number of
references. This allows an implementation to keep the adv buffer for the
future use. As an example, pb_adv.c keeps advs for retransmission.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
The recommendation to have 20ms is fair for two
consecutive messages over a single bearer. When mesh
sends two messages it can be interpreted as two
bearers working in parallel. No need to keep
an artificial 20ms delay for that. Delay was
removed and all related bsim tests were fixed.
Signed-off-by: Aleksandr Khromykh <aleksandr.khromykh@nordicsemi.no>
Adds a disable function for the extended advertising which stops and
deletes the advertising instances, allowing them to be properly
reinitialized when calling `bt_mesh_adv_enable()` after bluetooth has
been disabled and re-enabled.
For the legacy advertising, the function terminates the advertising
thread. If legacy advertising is used, `bt_mesh_adv_init()` must be
called before `bt_mesh_adv_enable()` to properly resume advertising
after suspension.
Signed-off-by: Håvard Reierstad <haavard.reierstad@nordicsemi.no>
Since notice that simultaneous advertising is not only used
by relay message, provision over pb-adv can also be used.
so it was changed to a more general name.
refs:https://github.com/zephyrproject-rtos/zephyr/pull/48903
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
In PR (#58723) has introduce another bug, that,
the flag ADV_FLAG_PROXY set before actually enabled.
When ctx:: BT RX call schedule_send will atomic_test_and_clear
ADV_FLAG_PROXY, but at this time, the proxy advertising will
not at advertising state, maybe in update params or set adverting
data phase,
so that, call bt_le_ext_adv_stop will nothing, and then call
k_work_reschedule --> send_pending_adv(at this time, the proxy
advertising actually enabled, but the upper layer clear proxy flags),
cause latest advertising unable start, because unable in advertising
state to update params(-EINVAL).
Fixes: #58721
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
When proxy advertising enabled, but at same time, the
connection event report, will cause `ADV_FLAG_PROXY` not
set, so cb `connected` will not be process, cause mesh message
unable to sent.
Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/58721
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
Until now iterable sections APIs have been part of the toolchain
(common) headers. They are not strictly related to a toolchain, they
just rely on linker providing support for sections. Most files relied on
indirect includes to access the API, now, it is included as needed.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
STRUCT_SECTION_ITERABLE cannot be used with arrays, because of
preprocessor tokenization issues.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Reschedule dedicated relay adv sets immediatey after finishing
advertising of the previous relay message. This allows a node to
relay messages as fast as possible when Relay Retransmit Count state
is zero using less relay adv sets.
When Relay Retransmit Count state is non-zero, the delay doesn't do
anything as the time between pushing a relay message to the host and
triggering adv_sent callback will be greater than this delay. In this
case the relay adv set will send a next message immediately.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
This is initial implementation of Proxy solicitation procedure.
This includes:
- support for sending and receiving Solicitation PDUs
- On-Demand Private Proxy functionality (Server and Client) controlling
behaviour of node after receiving Solicitation PDU
- Solicitation PDU RPL Configuration (Server and Client), which manages
Replay Protection List for Solicitation PDUs.
Proxy Solicitation allows to enable advertising of Proxy service on node
by sending Solicitation PDUs. These PDUs are not part of Mesh messages;
instead, these are non-connectable, undirected advertising PDUs with
their own format, containing Proxy Solicitation UUID.
Signed-off-by: Krzysztof Kopyściński <krzysztof.kopyscinski@codecoup.pl>
The purpose of this commit is to facilitate future improvements to the
LPN and friendship feature. By being able to identify friendship related
messages on the advertising layer, it will be possible to treat these in
a specific manner so that message exchange between LPN and friend
devices can be conducted in a more power efficient manner.
This commit adds the following:
- A separate tag for friendship related messages
- A optional separate advertising set for friend related messages
Signed-off-by: Anders Storrø <anders.storro@nordicsemi.no>
The `bluetooth/common/log.h` and `bluetooth/common/log.c` files have been
removed. Files that were using them have been updated to use
`zephyr/logging/log.h` instead.
Those replacement have been done consequently:
- `/BT_DBG/LOG_DBG/`
- `/BT_ERR/LOG_ERR/`
- `/BT_WARN/LOG_WRN/`
- `/BT_INFO/LOG_INF/`
- `/BT_HEXDUMP_DBG/LOG_HEXDUMP_DBG/`
- `/BT_DBG_OBJ_ID/LOG_DBG_OBJ_ID/`
Also, some files were relying on the `common/log.h` include to include
`zephyr/bluetooth/hci.h`, in those cases the include of `hci.h` has
been added.
For files that were including `common/log.h` but not using any logs,
the include has been removed and not replaced.
Signed-off-by: Théo Battrel <theo.battrel@nordicsemi.no>
Enable advertiser main to support relay messages, this maximizes
theutilization efficiency of advertising sets, which is helpful for the
sending of dense relays, but for Friend and LPN, it delays the sending
of local messages a little, this may cause the time slot deviation between
friend and lpn, and the power consumption of lpn will increase.
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
Functions related to string manipulation that were defined in
`common/log.h` has been moved to the `common/bt_str.h` file and their
implementation in `common/bt_str.c`.
Files that were using those functions has been updated consequently.
Signed-off-by: Théo Battrel <theo.battrel@nordicsemi.no>
By design, adv main set can use to send relay mesh messages
but here adv main set is invoked.
Add in the ended, so, adv main set only can be used when all
relay adv sets busy.
and this way does not cause too much delay for adv main set,
due to local message will process firstly.
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
`struct bt_le_ext_adv_start_param.timeout` resolution is in 10ms. When
duration is less than 10ms, division will be evaluated to zero, which
will result in indefinite timeout. Set timeout to 10ms to avoid
indefinite timeout. The advertisement will end earlier anyway after the
event is finished.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@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>
In order to bring consistency in-tree, migrate all subsystems code to
the new prefix <zephyr/...>. Note that the conversion has been scripted,
refer to zephyrproject-rtos#45388 for more details.
Signed-off-by: Gerard Marull-Paretas <gerard.marull@nordicsemi.no>
Since the default syswork thread priority = `-1`.
`adv_send` will call when controller report advertising
sending completed, due to this process by BT RX task, will
maybe process this before `buf_send`, since, sysworkq will be
used by other place and defer by any place.
Note: secure beacon will be 40ms, and friend and lpn will be 20ms.
This problem is very easy to reproduce, especially in native posix.
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
When pb-gatt advertising enabled, after extablish connect,
will call `cb->connected` and `cb->adv_send`.
In previous connected also clear `ADV_FLAG_PROXY` flag, but
in `adv_send` will attempt unref null point buffers.
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
The extended advertiser would fail to build due to a missing kconfig
option dependency when relay was disabled.
Fixes#43172.
Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no>
When Proxy advertising or PB-GATT Advertising Enabled and use a same
advertising sets.
As `adv_start` will call multi HCI Command will cause syswork_q yield.
At same time, if another thread(BT RX) all `schedule_send` will cause
unable send mesh message, because `ADV_FLAG_ACTIVE` was be set, but
`ADV_FLAG_PROXY` not set currentlly.
Add `ADV_FLAG_SCHEDULE_PENDING` indicate mesh buf has been pendings
but not scheduled, so when proxy advertising enable, let's take again,
as we can't break or terminated `adv_start`, so we must waiting proxy
advertising enabled.
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
This PR add multi advertising sets for bluetooth mesh adv bearer.
At the present, the local mesh network occupy single advertising.
And GATT Services Advertising use a single advertising, if support.
One or more advertising sets maybe used by relay node.
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
Align the capitalization of the term "Bluetooth Mesh" to Bluetooth mesh"
in the documentation. This is done to to match the new updated naming
convention done in Bluetooth SIG. In the upcoming spec versions, it its
used "Bluetooth mesh" with the lower case convention.
Signed-off-by: Ingar Kulbrandstad <ingar.kulbrandstad@nordicsemi.no>
The Bluetooth proxy feature includes proxy client
and proxy server. In addition to the proxy pdu
message used above, pb-gatt also uses the same
proxy pdu message.
Currently zephyr bluetooth mesh couples them in one file.
A file at the separation is called gatt_services.c,
which is used to contain Mesh Provisioning Service
and Mesh Proxy Service.
Another file in the separation is called proxy_msg.c,
which is used to process Proxy pdu messages.
Also according to Trond's suggestion:
Rename `CONFIG_BT_MESH_PROXY` to `CONFIG_BT_MESH_GATT`.
Create an additional promptless entry
`CONFIG_BT_MESH_GATT_SERVER` that selects
`CONFIG_BT_MESH_GATT` and is selected by
`CONFIG_BT_MESH_GATT_PROXY` or `CONFIG_BT_MESH_PB_GATT`.
Create additional `CONFIG_BT_MESH_PROXY` used to represent
proxy feature (also include proxy client).
see #36343
Signed-off-by: Lingao Meng <menglingao@xiaomi.com>
Switch to the new API in Mesh's extended advertising handler.
Signed-off-by: Peter Bigot <peter.bigot@nordicsemi.no>
Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no>
Adds support for extended advertiser commands in the mesh. This doubles
throughput for common packet sending, and significantly improves timing
accuracy for the Friend and Low Power features.
The proxy module's advertisement control has been moved inside the adv
module to abstract away the different advertiser modes.
The extended advertiser mode does not need an advertising thread to
operate, and ends up with a net reduction in RAM usage.
Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no>
