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