Fetching config values via Wifi "OTA" update

[hagenbuch]

While I think OTA flashing is a great idea, I am thinking about making the following:

After being flashed, the software must contain credentials for my (local) Wifi - or accept any unencrypted Wifi.

Then it makes a GET request to my webserver (HTTPS) sending its own MAC to fetch a specific configuration vector (maybe even with new Wifi data) including LoRa constants. Would be great if these could be flashed into flash memory.

Big advantage would be: If I deploy many devices, I can flash them all with the same firmware. Later in the field I may ask colleagues to just bring them into the vicinity of an open Wifi to be reconfigured.

So, I duplicate the Bintray code and go from there?

[cyberman54]

The current OTA function is for proof of concept purpose. It has a can of desgin flaws and therefore should not be further developed;

• bintray has a too large footprint for updating iot devices and is too expensive for private usage (as long as you don't use public repo, but this is a severe security flaw as long as firmware binary contains credentials)
• firmware flash file contains credentials (Wifi & LoRaWAN keys). We don't want credentials, neither encyrpted or even unencrypted, in flash files
• current approach does not scale if you need to update bunches of devices in the field

I think We need a completely new and more elaborated approach here:

• three phase provisioning process (1st = install bootstraploader, 2nd = install device production code, 3rd = pull individual device configuration)
• some kind of authentication to asssure validity and integrity of firmware on our device
• process should be deployable on top of different carrier channels (currently Wifi, in future we may want to have FOTA diff updates via LoRaWAN TTN v3 stack)

etc.

You're very welcome to do start here and do some of the heavy lifting and make pull request!