Is there a way to upgrade firmware via curl?

Hi all,

Basically, system upgrade can be done with WebUI or CLI command.
But, I'm try to do auto test and upgrade firmware via curl.
I double check JSON-RPC interface, looks like no upgrade feature over there.
So, anyone have experience about if I want to upgrade firmware via curl, how can I do? Thanks.

Yes you can do it, with something like when you install Brew on macOS, like this command:

/bin/bash -c "$(curl -fsSL"

But this would depend where the script is pointing to download the firmware (because you may run out of memory), it should be something like /tmp and then auto run the upgrade with:

sysupgrade -v /tmp/nefirmware.bin

I would suggest to add to the script a file checksum check first!


Do you mean that you want to be able to send a POST/GET to the router for it to start self-update?

1 Like

Can you please define “system upgrade”?

1 Like

is there a reason, why SSH does not work for your automation? Millions of people already use SSH everyday non-interactively, to do stuff on remote machines.

1 Like

with luci-app-commands you can define commandos which are then available as url but i have no idea why someone want to upgrade like that.

1 Like

Hi All,

Thanks for quick response.

First, our developing device have firewall rules to stop ssh, basically, do firmware upgrade via port 80/443 is good for long term developing.

Second, yes, we would like to use POST/GET to do system upgrade.
System upgrade mean firmware upgrade, sorry for wrong key word.


Third, how can I use luci-app-commands via curl? Is there any exist Web API I can use directly? Thanks.

why no vpn?

1 Like

You can run ssh on a custom different port too like 65542 or something. Or disable web interface on port 80 and place ssh there.

Using POST/GET to do firmware upgrade sounds like a lot of complexity for just a development device, and it isn't very safe for production systems either.
When someone finds the way to abuse that, they can remote-update your device firmware.

Breaking ssh with key authentication is much harder


I have very little experience with rpcd, but yeah, you'd have to write your own code for that afaik.

1 Like

Hi all,

Thanks for sharing useful experience. I will double check if ssh solution is suitable for my project.

It seems to me the real goal is to avoid SSH

I see you want to use curl to trigger luci-app-commands, I would recommend you look at the reverse possibility of using luci-app-commands to trigger curl

Personally I would use curl for the simple step of moving the new firmware image to the device

As for the actual sysupgrade, you can set a cron job to automatically attempt a sysupgrade every day at a certain time. If the file doesn't exist or cannot be verified, nothing happens. I do this on many of my boards.

30 4 * * * sysupgrade /tmp/firmware.bin

if you do it this way, all you need to worry about is getting the image to the device, and when you wake up next day it will be on the new image.

1 Like

Hi mpratt14,

Thanks. I will take this solution to try. ^^

you can also create a cron job to download the image, then as long as you host the image with the same location and name it will be fully automated, the only downside would be waiting until the time you set

I believe that sysupgrade also accepts download URL as the input so you can try something like

30 4 * * * sysupgrade http://some.where/path/to/image.bin

1 Like

Hi @mpratt14

Thanks. If we have cloud service, yes, we would like to use cron table to do pull and firmware upgrade.
But, for auto testing, we prefer to use simple and active way to firmware upgrade.

Note that SSH signature is sent in plain text and can be easily detected at any transit host.
And transit hosts like routers can be compromised collecting data about SSH connections.
Also, key-based authentication cannot protect against open vulnerabilities.
Thus VPN as an independent layer of security is your best option.

I said ssh with key auth. That's why I said it.

SSH works like a VPN aka scp or rsync or a whole lot of programs use it to create a secure and encrypted tunnel to transfer data over.

If you disable remote access to web interface and leave only ssh with key auth, then you are even safer than by piping the web interface over a VPN

1 Like

My intuition still tells me that SSH providing shell access leads to a broader scope of concern.
This may be a false impression, but reading some CVE details can make you paranoid.
So, better safe than sorry and use SSH over VPN when possible. :sweat_smile:

1 Like

Yeah more VPNs is more better.

But SSH alone with key auth is by no means unsafe