Autoupdater Improvements

tl;dr: Signed site/domain-config updates, using a site.conf-independent push (& pull) propagation

Concept

• Similar to firmware updates, provide a versioned and signed site-/domain-config, too.
• Provide an AP interface with a fixed, non-configurable, static ESSID and non-configurable, static IP address (similar to the local-node address, but not changeable via site.conf)
  • Run some (web?) server on it capable of receiving and verifying signed site-/domain-config, as well as offering the own, current site-/domain-config.

Push update (for immediate propagation):

• One initial node gets "manually" infused with the new, signed site-/domain-config.
• It restarts its gluon-scheduled-domain-switch (if present) and checks if the new config contains a domain switch that is due now.4 If so, this switch is performed first (including device reboot)
• Then it scans for neighbor APs with the magic config-updater ESSID.
• Then for each such AP found:
  • It connects to it in STA ("client") mode and uploads the signed site-/domain-config
  • Receiving nodes validate the signature and check that the version number incremented.
  • If those checks are ok, then this neighbor node installs the new site-/domain-config and performs the same push-steps again for its own neighbors.
  • Finally, with some offset it reboots so that the newly installed site-/domain-config can take effect

Pull updates (for previously offline nodes or temporarily jammed channels):

• After (a re)boot plus jitter and in regular intervals plus jitter a node should scan for neighbor APs with the magic config-updater ESSID.
• Then for each such AP found:
  • It connects to it in STA ("client") mode and downloads the signed site-/domain-config this neighbor currently uses.
  • It then validates the downloaded and signed signature and checks whether the version number is higher.
  • If those checks are ok, then this neighbor node install the new site-/domain-config.
  • This node then switches from "pull-mode" to "push-mode" and follows the according push mode procedure.
  • Finally, with some offset it reboots so that the newly installed site-/domain-config can take effect

Advantages

• Any potentially broken site-/domain.conf changes, including scheduled domain switches can be undone at any time. The site/domain-conf-updater itself is fully independent of any site-/domain.conf settings.
• Flash writes are minimized.
• A power-cut during this update process is harmless.
• site-/domain.conf are device and architecture independent and therefore easy and quick to propagate to and hold for neighbors: Each node is a site-/domain.config mirror on its own, no need for central update servers.

ToDo & Questions:

• Always use public keys from the site.conf autoupdater section from the original version provided by the firmware? Instead of any new version provided by a signed site-/domain-config update. -> to avoid that such an update messes anything up irrevocably

• How to best propagate an update over VPN and cable connections?

Option 1)

• Join a special, fixed IPv6 multicast address on VPN and cable interfaces
• To scan and discover, a node sends an ICMPv6 packet to this dedicated multicast address
• Use the IPv6 source addresses returned by the ICMPv6 Echo Replies as targets to connect to and to download/upload site-/domain-configs from/to as well

Disadvantage:

• Not revertable on broken VPN settings changes in new site-/domain-config

=> Maybe add a special "site update channel" VPN. For its settings, always use the parameters specified in the original site.conf provided by the firmware (similar to public keys for site-/domain.conf updates, as suggested above).

Option 2)

• Allow direct push to potential, global IPv6 address on WAN/uplink interface
• Might (temporarily) be memorized on the gateway server side from the previous VPN connections?

Option 3)

• Some central, last-resort web-server on the internet where an HTTP-GET with the own site-code might be send to over WAN/uplink interface?

Option 4)