ESP32 Forum

Wow! Was not expecting the protocomm component and associated generic provisioning tools! Congratulations to the Espressif team, this looks like a well-designed provisioning setup that I can't wait to start using.

In fact, I was in the middle of developing something very similar based on blufi, would it be correct to say that protocomm/esp_prov will be superseding blufi? (or at least esp_prov being recommended over blufi for new projects?)

Additionally, my blufi-based solution was using flatbuffers https://google.github.io/flatbuffers/, which are lighter-weight than protobufs. I use them elsewhere in my IoT solution and I can imagine others would like to use flatbuffers, too. So if I wanted to contribute a PR for the flexibility to use flatbuffers instead, would that be accepted within the protocomm component? (or would I have to fork protocomm on my own, and make a "flatbuffercomm")?

I plan to make a provisioning app similar to the samples, ideally one factory partition app could do all the transports at once (SoftAP, BLE, serial). Is that a supported use of esp_prov? Seems like it is geared towards using this as a factory app for 1st-time configuration, then rebooting to another (OTA) app entirely. Or is it supposed to live within the main app, and be turned on/off based on whether it has been configured already?

So if I wanted to contribute a PR for the flexibility to use flatbuffers instead, would that be accepted within the protocomm component? (or would I have to fork protocomm on my own, and make a "flatbuffercomm")?

The only place where protobuf is used in protocomm is the session security (protocomm_security0 and protocomm_security1) which uses protobuf packets for secure handshake. If flatbuffers is used then security is the only part that gets replaced under protocomm.

Though there is another component `wifi_provisioning` under IDF and the `esp_prov` tool which rely on protobuf. So in case flatbuffers is used all these will have to be changed.

I plan to make a provisioning app similar to the samples, ideally one factory partition app could do all the transports at once (SoftAP, BLE, serial). Is that a supported use of esp_prov?

`esp_prov` is simply a tool for only trying out the provisioning examples under IDF but it supports all three modes of transport. The provisioning examples use the protocomm and wifi_provisioning components to build a provisioning app but each app supports only one mode of transport (either Softap / BLE / serial) and switching from one mode to another is not flexible. But we are currently internally working on a one factory partitioning app with all supported transports and I believe it will be available as a component soon.

Seems like it is geared towards using this as a factory app for 1st-time configuration, then rebooting to another (OTA) app entirely. Or is it supposed to live within the main app, and be turned on/off based on whether it has been configured already?

In the present provisioning examples under IDF, we simply turn off the provisioning app. This is for the sake of simplicity only. But if one wishes to reboot to another app after configuration, that should also be possible.

If you have more questions please feel free to ask

So if I wanted to contribute a PR for the flexibility to use flatbuffers instead, would that be accepted within the protocomm component? (or would I have to fork protocomm on my own, and make a "flatbuffercomm")?

ESP_Anurag wrote:The only place where protobuf is used in protocomm is the session security (protocomm_security0 and protocomm_security1) which uses protobuf packets for secure handshake. If flatbuffers is used then security is the only part that gets replaced under protocomm.

Though there is another component `wifi_provisioning` under IDF and the `esp_prov` tool which rely on protobuf. So in case flatbuffers is used all these will have to be changed.

Alright. Just to confirm, but the components *.proto's do not include each others? So they could be ported separately in that case (or some with flatbuffers, some with protobuf)?

I plan to make a provisioning app similar to the samples, ideally one factory partition app could do all the transports at once (SoftAP, BLE, serial). Is that a supported use of esp_prov?

ESP_Anurag wrote:`esp_prov` is simply a tool for only trying out the provisioning examples under IDF but it supports all three modes of transport. The provisioning examples use the protocomm and wifi_provisioning components to build a provisioning app but each app supports only one mode of transport (either Softap / BLE / serial) and switching from one mode to another is not flexible. But we are currently internally working on a one factory partitioning app with all supported transports and I believe it will be available as a component soon.

Sounds great! Maybe I'll wait until then. Seems like protocomm has a global cur_session? So hopefully all three transports could be active at the same time, with each different encryption keys?

ESP_Anurag wrote:If you have more questions please feel free to ask

Sure a couple implementation questions:
- Why protobuf? What do you think about flatbuffers?
- Why does sec1 use AES-CTR (and not AES-XTS, for example?) I think when using AES-CTR, should generate a different nonce for each message, not just re-use the same session rand?

Thanks for your help!

Sounds great! Maybe I'll wait until then. Seems like protocomm has a global cur_session? So hopefully all three transports could be active at the same time, with each different encryption keys?

Yes, with a small change it should be possible to make multiple transports work simultaneously.

Sure a couple implementation questions:
- Why protobuf? What do you think about flatbuffers?

Protobufs seem to be okay on memory and CPU on ESP32 (in fact we could use the same provisioning on ESP8266 as well without any issue). One important consideration was to make sure that we have good client side languages supported (Java for Android, Swift and Objective-C for iOS and Python for host). Protobufs have pretty good support not only for the languages but also for integration of the compilers in the corresponding IDEs like Android Studio and Xcode.
Also, please note that for any of the extensions to the protocol by adding a new protocomm endpoint, you can use FlatBuffers (or any other encoding) as the handler receives and expects a raw buffer. So your own extensions can easily use FlatBuffers without changing core code.

- Why does sec1 use AES-CTR (and not AES-XTS, for example?) I think when using AES-CTR, should generate a different nonce for each message, not just re-use the same session rand?

AES-CTR uses a random nonce for each session. For each message exchange within the session, the nonce is auto-incrementing (by the property of CTR) which provides pretty good security.

@i_amey Thanks for clarifying the point related to usage of Flatbuffers.

@p-rimes Pardon me. I'll correct my statement as to how Flatbuffers can be used with protocomm and quote what Amey stated :

for any of the extensions to the protocol by adding a new protocomm endpoint, you can use FlatBuffers (or any other encoding) as the handler receives and expects a raw buffer. So your own extensions can easily use FlatBuffers without changing core code.

.