Lines Matching full:the
6 The Proxy feature allows legacy devices like phones to access the Bluetooth Mesh network through
7 GATT. The Proxy feature is only compiled in if the :kconfig:option:`CONFIG_BT_MESH_GATT_PROXY`
8 option is set. The Proxy feature state is controlled by the :ref:`bluetooth_mesh_models_cfg_srv`,
9 and the initial value can be set with :c:member:`bt_mesh_cfg_srv.gatt_proxy`.
11 Nodes with the Proxy feature enabled can advertise with Network Identity and Node Identity,
12 which is controlled by the :ref:`bluetooth_mesh_models_cfg_cli`.
14 The GATT Proxy state indicates if the Proxy feature is supported.
19 A node supporting the Proxy feature and the :ref:`bluetooth_mesh_models_priv_beacon_srv` model can
20 advertise with Private Network Identity and Private Node Identity types, which is controlled by the
22 the node allows the legacy device to connect to the network over GATT while maintaining the
23 privacy of the network.
25 The Private GATT Proxy state indicates whether the Private Proxy functionality is supported.
30 In the case where both GATT Proxy and Private GATT Proxy states are disabled on a node, a legacy
31 device cannot connect to it. A node supporting the :ref:`bluetooth_mesh_od_srv` may however be
32 solicited to advertise connectable advertising events without enabling the Private GATT Proxy state.
33 To solicit the node, the legacy device can send a Solicitation PDU by calling the
34 :func:`bt_mesh_proxy_solicit` function. To enable this feature, the device must to be compiled with
35 the :kconfig:option:`CONFIG_BT_MESH_PROXY_SOLICITATION` option set.
38 Solicitation UUID, encrypted with the network key of the subnet that the legacy device wants to
39 connect to. The PDU contains the source address of the legacy device and a sequence number. The
40 sequence number is maintained by the legacy device and is incremented for every new Solicitation PDU
43 Each node supporting the Solicitation PDU reception holds its own Solicitation Replay Protection
44 List (SRPL). The SRPL protects the solicitation mechanism from replay attacks by storing
46 processed by the node. The delay between updating the SRPL and storing the change to the persistent
49 The Solicitation PDU RPL Configuration models, :ref:`bluetooth_mesh_srpl_cli` and
50 :ref:`bluetooth_mesh_srpl_srv`, provide the functionality of saving and clearing SRPL entries. A
51 node that supports the Solicitation PDU RPL Configuration Client model can clear a section of the
52 SRPL on the target by calling the :func:`bt_mesh_sol_pdu_rpl_clear` function. Communication between
53 the Solicitation PDU RPL Configuration Client and Server is encrypted using the application key,
54 therefore, the Solicitation PDU RPL Configuration Client can be instantiated on any device in the
57 When the node receives the Solicitation PDU and successfully authenticates it, it will start
58 advertising connectable advertisements with the Private Network Identity type. The duration of the
59 advertisement can be configured by the On-Demand Private Proxy Client model.