List of changes:
* New component esp_local_ctrl added
* Example added under examples/protocols/esp_local_ctrl
* Documentation added under protocols/esp_local_ctrl
* Demo client side app esp_local_ctrl.py added under examples/protocols/esp_local_ctrl/scripts
* protocomm_ble : protocomm_ble_config_t given struct name for allowing forward declaration
* esp_prov/transport_softap renamed to transport_http
* transport_http module supports verification of server certificate
* transport_http module performs name resolution before connection
- Adds NimBLE stack support to existing BLE variant of unified provisioning.
- Uses scan response to send device name, 128 bit custom UUIDs based on service
UUID.
- Minimal changes to `app_prov.c`, component.mk, CMakeLists.txt and
`protocomm_ble.h` to accomodate NimBLE stack for provisioning.
List of changes:
* Use 128 bit characteristic UUIDs when creating GATT table entries
* Change primary service attribute value to 128 bit custom service UUID
* Use raw advertisement data to convey flags and 128 bit primary service UUID
* Use raw scan response to send device name as complete local name
* Increase maximum device name length in relation to maximum scan response length
* Set Characteristic User Description attributes for each characteristic to convey protocomm endpoint names
New APIs:
* protocomm_open_session()
* protocomm_close_session()
This allows external applications using protocomm to manually create and close sessions.
These internally call the new_transport_session() and close_transport_session() APIs implemented by the security scheme in use.
Updated unit tests with usage of new APIs
List of changes:
* Security APIs accept handle to instance created during initialization
* Protocomm internally stores the security instance handle and calls security APIs with this handle as first parameter
This will be useful if a webserver is already running and the application
does not want protocomm to start a new instance.
Signed-off-by: Piyush Shah <piyush@espressif.com>
* This manages secure sessions and provides framework for multiple transports.
* The application can use protocomm layer directly to have application specific extensions for provisioning (or non-provisioning) use cases.
* Following features are available for provisioning :
* Security - Security0 (no security), Security1 (curve25519 key exchange + AES-CTR encryption)
* Proof-of-possession support for Security1
* Protocomm requires specific protocol buffer modules for compilation which can be generated from the `.proto` files in the `proto` directory using make.
Co-Authored-By: Amey Inamdar <amey@espressif.com>
Co-Authored-By: Anurag Kar <anurag.kar@espressif.com>
Anton Maklakov