I have successfully automated the configuration of new Digi IX20W devices using a Python script with paramiko for ssh connection. Now, I am trying to automate the firmware update process.
I attempted to use the scp command in the Digi CLI to transfer the firmware file from my local PC to the Digi device but have not been successful. My goal is to upload the firmware to /tmp/ and then execute system firmware update /tmp/{firmware}.bin via SSH in my script.
Additionally, I checked Digi Remote Manager’s API but found no direct API for uploading firmware—only an API for triggering firmware updates based on the assigned group. Our devices require an intermediate firmware update before upgrading to the latest version, which would require assigning them to an intermediate group first.
Furthermore, I noticed that the web interface uploads the firmware via a POST request before installing it. While I’d prefer not to use web requests, I’m open to any working method.
Has anyone successfully automated firmware uploads and updates on Digi IX20W devices? Any insights on using SCP, an alternative file transfer method, or leveraging the web request approach would be appreciated.
@cshafer , granted I am a very biased opinion since I use Digi Remote Manager daily in my troubleshooting of customer issues, but I really think the answer to your question is Digi Remote Manager.
For example, a Template can be created, which is specific to a Group and Device Type, which would insure that all of your devices conform with the firmware version, settings, and file load you specify on the device, and this would automatically be checked at whatever interval you configure. To tackle your intermediate firmware update requirement, you’d run a pre-Template Automation, which would update your firmware to the intermediate version even before the Template scan continues. When the Template is scanned, your device would then be updated to that version you specified.
RE: your description of the firmware being uploaded first via POST, before the OS/firmware update runs on the devices, this is true and very intentionally by design. The firmware is uploaded in its entirety, after which a checksum is run on what was uploaded to verify the file isn’t corrupted. Only after that will the update continue, with the new OS being loaded in the primary partition, and the previous firmware being pushed to a backup partition (in case the primary OS doesn’t load). In more modern firmware versions, if the updated OS doesn’t load properly, the device will eventually fall back to what it was running before the update, as a failsafe/self-rescue feature. I can verify this works, as I test new versions of our OS pre-release all the time, and this has happened on pre-release firmware before we worked the bug out.
I haven’t personally tried doing a firmware update the way you described, so unfortunately I can’t offer any recommendation on the scripting etc. you’re trying to do to accomplish that task, but since Digi Remote Manager is bundled with many of our products now via Digi360 and Lifecycle Assurance, you can’t go wrong if you give the method I described a try. You could definitely save yourself some work though by Automating this!:
References: Templates, Automations
@michaelt Thank you for the quick and detailed response!
I agree that creating an intermediate group for the staged firmware update is the best way to go, and I’ll move forward with implementing it that way.
My main reason for initially exploring SCP or direct uploads was speed—during testing, I found that updating firmware while connected via Ethernet was noticeably faster. However, I understand the benefits of Remote Manager’s verification and failover mechanisms, so I’ll work within that framework.
Thanks again for your help! I’ll report back with any issues for successes that I have.