Test release of multicast NAND updater

[Mitch Bradley]

http://dev.laptop.org/~wmb/q2e22a.rom

This firmware contains a test version of the multicast NAND update 
utility.  It can "clone" an XO's  NAND image onto any number of other 
XO's simultaneously.  (It can also send NAND images from USB sticks,etc, 
but I'm not ready for people to begin testing that yet.)

It uses the mesh as a fast broadcast medium by setting time-to-live=1 so 
packets don't get forwarded.  You don't need an access point at all, 
just two or more XOs.  The primary use case is for updating a very large 
number of machines at once, in an dedicated area like a warehouse.  
Think of a country trying to update 50,000 machines by next week, in 
time for school to start.

The current version only works on unsecure machines, and only for 
unpartitioned NAND images.  Both of those limitations are on my list to 
fix.  I'm also going to improve the user interface a lot.  But for now, 
I'd like to get some feedback on how well the current version works for 
people in different RF environments.

Here's how to use it:

a) Pick a wireless channel that is relatively clear (1, 6, or 11), using 
whatever technique you prefer.

b) On the machine whose NAND you want to send, type:
   ok ether-clone6   (or ether-clone1, or ether-clone11, according to 
which channel you want to use)

c) On the receiving machines, type:
   ok enand6  (or enand1 or enand11)

The sending machine will send continuously, over and over, until you 
power it off.  The receiving machines can be started at any time in any 
order.  It should be possible to have an arbitrary number of receivers, 
as the data traffic is strictly one-way.

When a receiving machine starts, it may say something like:

1083 need 93
1084 need 30

The first number (e.g. 1083) is the block number.  The number after 
"need" is the number of data packets that are missing for that block.  A 
few - 2 or 3 - such lines is normal because the receiver drops a few 
packets when it is preparing all its initial data structures.  The 
missing packets will be collected the next time around.  After the first 
few blocks, on my setup (quiet RF environment), packet loss is very 
rare.  I'd be interested to hear your results.