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.
> 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.
On Thu, Nov 5, 2009 at 9:17 PM, Antoine van Gelder
<anto...@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 ?
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.
> On Thu, Nov 5, 2009 at 9:17 PM, Antoine van Gelder > <anto...@7degrees.co.za> wrote: >> 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
*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.
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.
On 06 Nov 2009, at 07:59 , jan.groenew...@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.
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.
On Fri, Nov 6, 2009 at 4:55 PM, <jan.groenew...@gmail.com> wrote:
> Hi
> 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.
On Fri, Nov 6, 2009 at 8:25 AM, <jan.groenew...@gmail.com> wrote: > 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.
> 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.
|
