Serializing settings

1

I know variants of this has been discussed multiple times, and I believe I have read about every single thread in the forum, but still have not been able to come up with a solution that works for us.

Some background:

  • We have a number of devices that need a software upgrade. However, before we do the actual upgrade, we need to change some settings. But now the tricky part - when we change some of those settings, the device will disconnect (and reconnect). This obviously causes the firmware upgrade to fail, as the device is disconnecting while the upload is happening.

So - I have tried to solve this by doing the “tag dance”:

Provision 1 - “PRE-UPGRADE”, triggered by “2 PERIODIC” with precondition “Tags.FW-UPGRADE IS NOT NULL”:

  • Sets the initial config
  • Removes the tag “FW-UPGRADE”
  • Adds the tag “DO-FW-UPGRADE”

Provision 2 - “UPGRADE”, triggered by “2 PERIODIC” with precondition “Tags.DO-FW-UPGRADE IS NOT NULL”:

  • Uploads the new firmware
  • Removes the tag “DO-FW-UPGRADE”
  • Adds the tag “FW-UPGRADE-DONE”

Provision 3 - “POST-UPGRADE”, triggered by “2 PERIODIC” with precondition “Tags.FW-UPGRADE-DONE IS NOT NULL”:

  • Sets additional config for the new firmware

(Of course there is more happening in the provisions, but this is the core functionality).

To me, the preconditions should cause the Provision 1 to run first. Then the device will disconnect, and reconnect, and then Provision 2 should run on the next “Periodic”.
And after the firmware has been uploaded, the device is rebooting, and after that reboot, Provision 3 should run on the next “Periodic” again.

But this is not how it works in reality. I have added a bunch of log lines to follow the flow, and this is what I see:

On the first “Periodic inform” after the “FW-UPGRADE” tag is set, the Provision 1 is triggered as expected.
But as soon as it comes to the line where the tag “DO-FW-UPGRADE” is set, the second provision is also triggered.
And as soon as Provision 2 sets the FW-UPGRADE-DONE-tag, Provision 3 is triggered.
So they all start at basically the same time (a few seconds delay between them) during the first “2 PERIODIC” trigger.

My understanding was that the preconditions were checked when the event happened (e.g. when the “Periodic” inform arrived). And if the tag was not set then, the Provision would not be triggered (or its preconditions checked) until next Periodic inform.

But it seems like Genie is “to smart”, and rechecks the preconditions and triggers the provisions also later, if any preconditions become true duriing the run of another provision.

This is quite unexpected, and not how I understand that others are solving similar problems.

2

This is the intended behavior. To accomplish your goal, you need to keep the CPE from immediately doing a f/w upgrade after the settings change. Is that correct? If so, what about after step 1 rebooting the CPE?

3

The CPE automatically and immediately disconnects from the network after step 1.
But the reconnect can take a minute or so.

Step 1 is reconfiguring the “wan” interface, and this must be done prior to the software upgrade, as the new software version does no longer support the current config of that interface.

But how can we ensure that Step 2 does not start until the device has reconnected?

For Step 3, I do a check that the current software version is correct before changing the settings, so that works fine.