Updating firmware in operational mesh
Johann Hugo
I've got a couple of questions for the list.
1) To all the people maintaining some kind of mesh network. At some stage one
needs to upgrade the firmware on all the nodes. How do you tackle it ?
2) I've flashed a ubiquity pico station with openwrt recently. It's easy if
your directly connected to the hardware with access to the reset button, but
when I tried the upgrade option on the web interface, it said "this action is
not supported". How do one preform a remote upgrade on one of these devices.
3) How would one upgrade all the mesh-patato's once they are deployed in an
operation network.
Regards
Johann
Antoine van Gelder
On 05 Nov 2009, at 20:50 , Johann Hugo wrote:
> 1) To all the people maintaining some kind of mesh network. At some
> stage one
> needs to upgrade the firmware on all the nodes. How do you tackle it ?
AFAIK Scarborough mesh is still done manually and very carefully. :)
> 2) I've flashed a ubiquity pico station with openwrt recently. It's
> easy if
> your directly connected to the hardware with access to the reset
> button, but
> when I tried the upgrade option on the web interface, it said "this
> action is
> not supported". How do one preform a remote upgrade on one of these
> devices.
With redboot capable devices I put a rule in to check for new firmware
on a remote server.
Redboot can also fallback to the old partition if upgrade fails.
For the rest I ssh a:
wget http://some.host.with/firmware.trx -O - | mtd -e linux -r
write - linux
> 3) How would one upgrade all the mesh-patato's once they are
> deployed in an
> operation network.
I'd recommend the redboot method I mentioned above.
- antoine
David Carman
<ant...@7degrees.co.za> wrote:
> On 05 Nov 2009, at 20:50 , Johann Hugo wrote:
>> 1) To all the people maintaining some kind of mesh network. At some
>> stage one
>> needs to upgrade the firmware on all the nodes. How do you tackle it ?
For Atheros:
ssh root@meshnode /sbin/reboot
ssh root@meshnode
wget http://yourfavouriteimage/openwrt-atheros-root.squashfs rootfs
wget http://yourfavouriteimage/openwrt-atheros-vmlinux.lzma
mtd write openwrt-atheros-root.squashfs rootfs
mtd write openwrt-atheros-vmlinux.lzma kernel
reboot
However you still need ethernet access unless you create an image that
autoconfigures wireless, IPs and mesh routing.
If you need to resize mtd partitions to fit your custom image, then
the only option is the reset button. Flash with .bin with big kernel
while you still have access to the reset button.
> With redboot capable devices I put a rule in to check for new firmware
> on a remote server.
I don't think redboot can do wireless. Probably best to have a cron
script to check for updates rather than rc.d - with solar panels you
can't rely on rolling blackouts to cycle the routers.
David
Antoine van Gelder
*duh*
Of course not - what was I thinking?
Seconding the cron script.
> with solar panels you
> can't rely on rolling blackouts to cycle the routers.
Ah the convenience :)
- a
jan.gro...@gmail.com
On Thu, Nov 05, 2009 at 08:50:49PM +0200, Johann Hugo wrote:
> I've got a couple of questions for the list.
> 1) To all the people maintaining some kind of mesh network. At some stage one
> needs to upgrade the firmware on all the nodes. How do you tackle it ?
./update-all.sh ;)
I have a script which scp's over the firmware and mtd's it.
I've never bricked one. 1 out of 60 fail due to connectivity problems
each time (the initial ssh fails or something).
It does one at a time, as it has to reboot, and can affect other nodes
connectivity.
> 2) I've flashed a ubiquity pico station with openwrt recently. It's easy if
> your directly connected to the hardware with access to the reset button, but
> when I tried the upgrade option on the web interface, it said "this action is
> not supported". How do one preform a remote upgrade on one of these devices.
firmware-burn /tmp/openwrt-freifunk-1.6.36-en.trx
> 3) How would one upgrade all the mesh-patato's once they are deployed in an
> operation network.
Self upgrading or parallel is not good in a mesh network, as the nodes may need to
restart, adn then may interrupt a neighbour's upgrade.
Jan
--
.~.
/V\ Jan Groenewald
/( )\ www.aims.ac.za
^^-^^
Antoine van Gelder
On 06 Nov 2009, at 07:59 , jan.gro...@gmail.com wrote:
>> 3) How would one upgrade all the mesh-patato's once they are
>> deployed in an
>> operation network.
>
> Self upgrading or parallel is not good in a mesh network, as the
> nodes may need to
> restart, adn then may interrupt a neighbour's upgrade.
Sorry, seems like I can't get my brain out of neutral today - I blame
my dentist - Jan is of course 100% correct.
1. list of nodes
2. pick first router from the list
3. flash it
4. wait till it is finished, rebooted and back up
5. goto 2
You could do a depth-first-traversal of the mesh graph but - in
practice - routes change and you can still end up with a router
getting cut off mid-flash.
- antoine
jan.gro...@gmail.com
On Fri, Nov 06, 2009 at 08:17:38AM +0200, Antoine van Gelder wrote:
> You could do a depth-first-traversal of the mesh graph but - in
> practice - routes change and you can still end up with a router
> getting cut off mid-flash.
Not a huge problem. The firmware is copied to /tmp locally,
and then if some firmware checksum matches, then it can
fimrware-burn (mtd) locally, and it does not matter
if the connection drops.
However, if you did a normal mesh in parallel, 50% or more
would just fail to get the firmware copied locally and stop there.
One at a time (if pull technology, client side, node side, then
perhaps at 3am+node*minutes times, or random, or something; or
prepare at 2am and flash/reboot at 3am, operator-set) avoids this.
Perhaps a mesh-wide reboot (in case of updates) is OK at 3am.
In some meshes. Some of the time.
Jan
Mike O'Connor
maybe a cronjob, it could check this node for an update.
Mike
David Carman
> One at a time (if pull technology, client side, node side, then
> perhaps at 3am+node*minutes times, or random, or something; or
> prepare at 2am and flash/reboot at 3am, operator-set) avoids this.
Definitely a good idea to reboot all routers at 03h30 - as long as
ntpdate is working. Ntpdate in rc.d doesn't work because the router
takes a minute to find a gateway. I cron ntpdate at 00h10 so that the
time is set 10 minutes after boot (and every night at 00h10).
Instead of doing one-at-a-time, a cron job can run at 02h30 to check
for new image and copy it to /tmp if present.
Cron job at 03h30 can check /tmp for new image and, if present, flash
before rebooting.
Two caveats:
1. Some routers are going to be off at upgrade time, so upgrades must
be backward compatible.
2. Upgrading a WRT is easy because the config is preserved in NVRAM.
Not so with Atheros devices - so there are two possible solutions:
a) Store config parameters temporarily in mtd partition that is not
going to be reflashed.
b) Have the server generate a customized image for each router based on its IP.
David
Julio Cesar Puigpinos
>
> Hi everyone
Hi
> I've got a couple of questions for the list.
>
> 1) To all the people maintaining some kind of mesh network. At some stage one
> needs to upgrade the firmware on all the nodes. How do you tackle it ?
For our WMN we've choosen a non automatic triggered method.
Using tools included in OpenWrt (mtd and others) we flash the nodes
preserving the current configuration that they have (passwords, BMX
settings, etc). We provide a simple web page where the
owner/administrator of the node uploads the firmware, and then a
script does the checkings, flashing, etc..
We preferred to let the *when* to the owner/administrator of the node,
because a fixed or random scheduled time seemed *for our case* to have
more cons then pros.
In our case no one owns or administers all (or most of) the nodes,
each members takes care of its node/s. Of course we help them when
ever they need/request it :)
> 2) I've flashed a ubiquity pico station with openwrt recently. It's easy if
> your directly connected to the hardware with access to the reset button,
Using the reset button should be the last resort.
> but
> when I tried the upgrade option on the web interface, it said "this action is
> not supported". How do one preform a remote upgrade on one of these devices.
mtd, sysupgrade-atheros
> 3) How would one upgrade all the mesh-patato's once they are deployed in an
> operation network.
>
> Regards
> Johann
Saludos, Julio
--
www.lugro-mesh.org.ar/ Wireless Mesh Networks Group
www.lugro.org.ar GNU/Linux User Group Rosario, Argentina
Slackware rulez :P www.slackware.org
NO A LA MATRICULA!!!: http://noalamatricula.wordpress.com/