On Wed, 2007-06-27 at 17:42 +0200, Alexander Larsson wrote: > On Tue, 2007-06-26 at 15:03 -0400, Mike C. Fletcher wrote: > > > My understanding here is that Alex's system is currently point-to-point, > > but that we don't yet have any way to distribute it on the mesh? That > > is, that we are looking at a research project to determine how to make > > it work in-the-field using some form of mesh-based discovery protocol > > that's going to try to optimise for connecting to local laptops. I > > personally don't care which way we distribute, but I'm wary of having to > > have some mesh-network-level hacking implemented to provide discovery of > > an update server. > > I'm not sure what you mean here exactly. Discovery is done using avahi, > a well known protocol which we are already using in many places on the > laptop. The actual downloading of file uses http, which is a well known > protocol with many implementations. > > The only thing i'm missing atm is a way to tell which ip addresses to > prefer downloading from since they are close. This information is > already availible in the mesh routing tables in the network driver (and > possibly the arp cache), and its just a question of getting this info > and using it to drive what servers to pick for downloading.
So, like michail said, do something like: n = 0 while (True) { buf = output of (iwpriv msh0 fwt_list_neigh n) if (buf == "(null)") break; // all done <parse buf into fields> hwaddr = parsed[0] // Grab the 'ra' field (1st one) ip4addr = lookup_hwaddr_in_arp(hwaddr) <do something with ip4addr> n++; } Look on the 'olpc' branch of the libertas driver here: http://git.infradead.org/?p=libertas-2.6.git;a=blob;f=drivers/net/wireless/libertas/README;hb=olpc http://git.infradead.org/?p=libertas-2.6.git;a=blob;f=drivers/net/wireless/libertas/ioctl.c;hb=olpc The README has a description of the command, and the ioctl.c has the implementation. Just search for the string "neigh" and you'll find it. Dan > > > Basically aside from the vserver bits, which no one has seen, I don't > > > see a particular advantage to using rsync. In fact, I see serious > > > downsides since it misses some of the key critical advantages of using > > > our own tool not the least of which is that we can make our tool do what > > > we want and with rsync you're talking about changing the protocols. > > > > > Hmm, interestingly I see "using our own tool" as a disadvantage, not a > > huge one, but a disadvantage nonetheless, in that we have more untested > > code on the system (and we already have a lot), and in this case, in a > > critical must-never-fail system. For instance, what happens if the user > > is never connected to another XO or school server, but only connects to > > a (non-mesh) WiFi network? Does the mesh-broadcast upgrade discovery > > protocol work in that case? > > Avahi works fine for these cases too. Of course, since it was originally > created for normal networks. However, if you never come close to another > OLPC machine, then we won't find a machine to upgrade against. Its quite > trivial to make it pull from any http server on the net, but that has to > be either polled (which I don't like) or initiated manually (which might > be fine). > > > _______________________________________________ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel