80158c1428
Updated related docs. Small fix in mesh/Kconfig and shell.rst. Signed-off-by: Stine Åkredalen <stine.akredalen@nordicsemi.no>
62 lines
3.4 KiB
ReStructuredText
62 lines
3.4 KiB
ReStructuredText
.. _bt_mesh_proxy:
|
|
|
|
Proxy
|
|
#####
|
|
|
|
The Proxy feature allows legacy devices like phones to access the Bluetooth
|
|
mesh network through GATT. The Proxy feature is only compiled in if the
|
|
:kconfig:option:`CONFIG_BT_MESH_GATT_PROXY` option is set. The Proxy feature state is
|
|
controlled by the :ref:`bluetooth_mesh_models_cfg_srv`, and the initial value
|
|
can be set with :c:member:`bt_mesh_cfg_srv.gatt_proxy`.
|
|
|
|
Nodes with the Proxy feature enabled can advertise with Network Identity and Node Identity,
|
|
which is controlled by the :ref:`bluetooth_mesh_models_cfg_cli`.
|
|
|
|
The GATT Proxy state indicates if the Proxy feature is supported.
|
|
|
|
Private Proxy
|
|
*************
|
|
|
|
A node supporting the Proxy feature and the :ref:`bluetooth_mesh_models_priv_beacon_srv` model can advertise with
|
|
Private Network Identity and Private Node Identity types, which is controlled by the
|
|
:ref:`bluetooth_mesh_models_priv_beacon_cli`. By advertising with this set of identification types,
|
|
the node allows the legacy device to connect to the network over GATT while maintaining the
|
|
privacy of the network.
|
|
|
|
The Private GATT Proxy state indicates whether the Private Proxy functionality is supported.
|
|
|
|
Proxy Solicitation
|
|
******************
|
|
|
|
In the case where both GATT Proxy and Private GATT Proxy states are disabled on a node, a legacy device cannot
|
|
connect to it. A node supporting the :ref:`bluetooth_mesh_od_srv` may however be
|
|
solicited to advertise connectable advertising events without enabling the Private GATT Proxy state.
|
|
To solicit the node, the legacy device can send a Solicitation PDU by calling the :func:`bt_mesh_proxy_solicit` function.
|
|
To enable this feature, the client must to be compiled with the :kconfig:option:`CONFIG_BT_MESH_PROXY_SOLICITATION`
|
|
option set.
|
|
|
|
Solicitation PDUs are non-mesh, non-connectable, undirected advertising messages
|
|
containing Proxy Solicitation UUID, encrypted with the network key of the subnet that the legacy device
|
|
wants to connect to. The PDU contains the source address of the legacy device and a sequence number. The
|
|
sequence number is maintained by the legacy device and is incremented for every new Solicitation PDU sent.
|
|
|
|
Each node supporting the Solicitation PDU reception holds its own Solicitation Replay Protection List (SRPL).
|
|
The SRPL protects the solicitation mechanism from replay attacks by storing solicitation sequence number (SSEQ)
|
|
and solicitation source (SSRC) pairs of valid Solicitation PDUs processed by the node. The delay between updating the
|
|
SRPL and storing the change to the persistent storage is defined by :kconfig:option:`CONFIG_BT_MESH_RPL_STORE_TIMEOUT`.
|
|
|
|
The Solicitation PDU RPL Configuration models, :ref:`bluetooth_mesh_srpl_cli` and
|
|
:ref:`bluetooth_mesh_srpl_srv`, provide the functionality of saving and clearing SRPL entries.
|
|
A node that supports the Solicitation PDU RPL Configuration Client model can clear a section of the SRPL on the target by calling the :func:`bt_mesh_sol_pdu_rpl_clear` function.
|
|
Communication between the Solicitation PDU RPL Configuration Client and Server is encrypted using the application key, therefore,
|
|
the Solicitation PDU RPL Configuration Client can be instantiated on any device in the network.
|
|
|
|
When the node receives the Solicitation PDU and successfully authenticates it, it will start
|
|
advertising connectable advertisements with the Private Network Identity type. The duration of the
|
|
advertisement can be configured by the On-Demand Private Proxy Client model.
|
|
|
|
API reference
|
|
*************
|
|
|
|
.. doxygengroup:: bt_mesh_proxy
|