Bluetooth Mesh Proxy

.. _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 device 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