OpenWrt Forum Archive

Topic: Need help on how to update firmware remotely

The content of this topic has been archived on 9 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hello all,

Problem: I have many openwrt WRT54Gs spreaded geographically. I have physicall access to them, but they are many (about 350) and I want to upgrade their firmware. Has anyone any idea on how to do it remotely? Is it possible?

I have ssh, sftp and could also have http access to them.

Any ideas?

Sugestions are also very welcome.

Iurgi Arginzoniz

yissnn wrote:

Problem: I have many openwrt WRT54Gs spreaded geographically. I have physicall access to them, but they are many (about 350) and I want to upgrade their firmware. Has anyone any idea on how to do it remotely? Is it possible?

Yes. Put the firmware on the wrt54g with scp, then use the command

mtd -r write yourfirmware.trx linux

And yes, you need a .trx, not a .bin (which has an additional header).

The -r option allows you to reboot once the new firmware is in place. This is useful because reboot can no work any more when the new firmware is in place.

And you need to handle the cases of nvram variables before flashing. Either it is a minor upgrade and you don't care, either it is not and you need to update the nvram correctly.

Great!! thank you very much Vincent!

One more question still: is there a problem or warning with the hardware versions to be taken on account?

Some of them are v2.0 and some are v2.2 I want to upgrade to experimental or whiterussian (what's the difference?). Should both work?

Last thing; any suggestions on how to do it in the cleanest way? Right now, I have cron executing a script which downlads a second script from my server and execute it. This way I can make automatic upgrades just by making the script with the commands I need. This second script also has a little vesioning system in order not to re-execute upgrades. But it has falied in some cases if the conection was interrupted. I guess doing it with ipkg would be more safe?

Thanks again

Iurgi Arginzoniz

Oooops

openwrt# mtd -r write firmware.trx linux
No valid option suplied
openwrt#

Any ideas?

yissnn wrote:

Last thing; any suggestions on how to do it in the cleanest way? Right now, I have cron executing a script which downlads a second script from my server and execute it. This way I can make automatic upgrades just by making the script with the commands I need. This second script also has a little vesioning system in order not to re-execute upgrades. But it has falied in some cases if the conection was interrupted. I guess doing it with ipkg would be more safe?

Maybe you should setup everything in the image u upload at the beginning; with some startup scripts executing every single step each reboot and removing theirselves only at upgrade completition. In this way you don't have the "connection interrupt" point of failure in the procedure as u upload everything in one step and then is everything full automated... just a bit more work at the beginning to plan, deploy and deeply test everything, but then you rock 350 units in a few minutes...

Or, if you do it issueing commands from remote, use screen, to avoid the tty loss while the script is running...

(hoping to understood what you said, sorry for my poor english)

ciao

Renton78

yissnn wrote:

openwrt# mtd -r write firmware.trx linux
No valid option suplied
openwrt#

Your mtd seems too old to support reboot. Remove it and append "&& reboot" behind. If some boxes are unable to reboot, use this clean way to force them to reboot :

cat /dev/zero > /dev/kmem

They will panic and reboot.

thank you both!

Vincent, you're right, it works now with the '&& reboot' tip.

Wallace, thanks for your suggestion, I'll take it on account.

Now I have a third problem... probably related to nvram...

I've tried this two things:
A) flash .trx image and reboot (no change on nvrams)
B) flash .trx image, mtd erase nvram and reboot.

In both cases, I get a 'destination host unreachable' from my eth connection.
If I start in failsafe mode, I can si lan_ipaddr=192.168.4.1 in the first case (precious IP) and lan_ipaddr=192.168.1.1 in the second (due to nvram erasing)

But can't get response in normal startup... weird.

Any ideas? And thanks again for you help and even more for such fast replies!

Iurgi

yissnn wrote:

I've tried this two things:
A) flash .trx image and reboot (no change on nvrams)
B) flash .trx image, mtd erase nvram and reboot.

In both cases, I get a 'destination host unreachable' from my eth connection.
If I start in failsafe mode, I can si lan_ipaddr=192.168.4.1 in the first case (precious IP) and lan_ipaddr=192.168.1.1 in the second (due to nvram erasing)

But can't get response in normal startup... weird.

In the second case, did you try to ping 192.168.1.1 with an IP in the 192.168.1.* network ? It should work.

Some notes on the squashfs image -

The jffs2 filesystem is outside the normal firmware; reflashing can sometimes corrupt the jffs2 partition.

Boot into failsafe (to prevent it from using the jffs2 partition) then run firstboot.
(if you want to preserve the contents of the jffs2 as much as possible, mount it before running firstboot)

thanks vincent and mbm

Vincent: yes, I've done it from a 192.168.1.0/24 ip. I now it's a typical silly mistake, thanks for the warning. Still doesn't work.

mbm: thank you to for the notes. I don't need to kkep jffs2 info. What I want to do is a completely new installation. I'm preparing a custom image with everything I need. I want to place it in all my boxes and delete every previous thing.

So, to sum up:
- I build the image, put it with scp and flash it.
- Then mtd erase nvram.
- firstboot
- set the nvrams they way I want them.
- reboot.

should that work? I mean, would that be a valid way to upgrade my boxes without need of any physical access to them?

thanks!

(Last edited by yissnn on 13 Jul 2005, 12:58)

The discussion might have continued from here.