[Battlemesh] Extract firmware

[Gui Iribarren]

> No. I have a running router and I would want that it stays like that.
> But I would like to extract its firmware out, so that I can flash the
> second router with the same firmware.

if you don't have the original binary firmware with which you flashed
the first router, you might try to 'dd' the squashfs partition out
somehow, but i never tried that. Why not recreate the .bin with
openwrt build environment?

Now, if when you say "firmware" you're instead thinking about
"configuration" on top of firmware (readonly rootfs vs read-write
overlay) that's another issue.
Even if you could dump the partition with dd, AFAIU you won't be able
to flash that to the second router since you can't include /overlay in
binary images

ruci [0] might help.
1) If you somehow have still the original firmware (.bin) with which
you flashed the first router,
2) if it's squashfs (So everything is populated in /overlay)
3) and you have ssh access to both routers,

[0]
    hg clone https://bitbucket.org/guidoi/ruci

NicoEchaniz described it this way:

----
It's called ruci (for remote uci) and it has many useful features:

1) uses a centralized mercurial repository to store all your nodes
configuration.
2) can "pull" configurations from nodes at any time into the repo.
3) can push configuration changes to a node or set of nodes.
4) can compare configuration status between repo and nodes.
5) can always revert nodes or the whole network to any previous state
(provided by mercurial), as long as you keep a useful commit policy.

When new configuration is pushed, the remote router updates and reboots
(we found this to be safer than just restarting services). It then boots
with the new configuration and a 10min. revert timer, which triggers
unless you confirm the changes.

This simple method provides enormous experimentation possibilities. You
can, for example modify your entire network's IP addressing policy in
your local configs repo and then push the change simultaneously. If
something goes wrong, the routers will revert configuration and reboot
in 10 min.; if everythig went well, you can just confirm your changes
during the "revert window" to make them permanent.

Anyone who would like to test it, and might need some initial guidance
(mainly to set up things, the rest is self-explanatory), just drop guido
or me an e-mail and we will gladly help you out. There's no list or
forum yet...
----

Quickstart in a nutshell

    mkdir my_overlays ; cd my_overlays
    hg init
    ruci pull --ip first.router first.router
    ### at this point you have cloned first.router' overlay into your repo
    hg commit -A -m "pulled first.router"
    ruci push --ip second.router --full first.router
    ### --ip argument accepts both hostnames (as shown)
    ### or ip addresses (v4 or v6)

at this point you should probably need to turn off first.router, since
you'll have an ipv4 collision if not.

(second.router will reboot and come back up with the exact
configuration cloned from first.router, including ipv4, etc)

you also probably need to check if /etc/config/wireless is using a
hardcoded macaddr. In that case, change it before pushing to
second.router, or replace it with phy approach, making the config
hardware independent:

uci set wireless.radio0.macaddr=
uci set wireless.radio0.phy=phy0

last but not least, if everything went well,

    ruci confirm first.router

before the 10 minutes countdown.

If something went wrong, (you can't ssh into it) , then wait 10
minutes uptime: it should revert back to previous config.

Cheers!

Gui