<br>
<br><tt><font size=2>Bryan Berry &lt;bryan.berry@gmail.com&gt; wrote on
03/05/2008 03:07:12 AM:<br>
<br>
&gt; Michailis, thanks for your quick reply<br>
&gt; <br>
&gt; &gt; small schools, the school server is all that you need. In the
<br>
&gt; &gt; meantime, APs with controllable WDS behavior are recommended.
<br>
&gt; <br>
&gt; I am not an expert on access points. Can you suggest a particular
model<br>
&gt; that meets this criteria?</font></tt>
<br>
<br><tt><font size=2>Bryan,</font></tt>
<br>
<br><tt><font size=2>The problem is mostly obvious on consumer APs with
Broadcom radios (the Linksys WRT54 being the most common) and is not an
XO specific problem anymore.</font></tt>
<br><tt><font size=2>Any application that generates multicast traffic will
trigger storms in environments where many such access points are deployed
in the vicinity of each other.</font></tt>
<br><tt><font size=2>Most enterprise Access Points will work just fine
because they allow for fine control of WDS. </font></tt>
<br><tt><font size=2>Since we assume a limited budget here, I will stick
to consumer and prosumer grade gear.</font></tt>
<br><tt><font size=2>A good starting point should be the DLINK DWL-2100AP
which uses an Atheros Chipset.</font></tt>
<br>
<br>
<br>
<br><tt><font size=2><br>
&gt; <br>
&gt; &gt;The solution to that problem is to be able to turn off WDS. The
stock<br>
&gt; &gt;Linksys firmware doesn't do it, however OpenWRT and its variants
can do<br>
&gt; &gt;it. <br>
&gt; <br>
&gt; I am not familiar w/ OpenWRT and its variants. Similar to my previous<br>
&gt; question, is their an off-the-shelf AP where WDS can be disabled w/out<br>
&gt; having to load OpenWRT?</font></tt>
<br>
<br><tt><font size=2>The reason that I mentioned OpenWRT, DD-WRT etc. is
that the Linksys WRT54Gx is the most popular AP that I know off.</font></tt>
<br><tt><font size=2>Avoiding them completely will be hard ;-) In many
models (the ones with 8MB of RAM) loading DD-WRT is &nbsp;trivial.</font></tt>
<br>
<br><tt><font size=2><br>
&gt; <br>
&gt; To Mesh or not to Mesh?<br>
&gt; Using regular access points, is there actually a mesh network at all?
It<br>
&gt; sounds like we are back to using a regular 802.11 g network. Jabber
just<br>
&gt; emulates the features of a mesh over a regular network.<br>
Let's separate the mesh transport (802.11s-like layer-2 transport) from
the collaboration middleware (jabber, avahi, telepathy).</font></tt>
<br><tt><font size=2>They are completely indepedent and as you point out
the applications will run on any transport.</font></tt>
<br>
<br>
<br><tt><font size=2>&gt; <br>
&gt; We were really excited about kids using the mesh to connect to the<br>
&gt; Internet from their own homes to and each other via the mesh at great<br>
&gt; distances. Is this dream currently not a reality? If it is not currently<br>
&gt; a reality, when can we expect it to work?</font></tt>
<br>
<br><tt><font size=2>When we started OLPC, we thought that the mesh would
have two main uses:</font></tt>
<br>
<br><tt><font size=2>* extending the range of access points (via multihopping)</font></tt>
<br><tt><font size=2>* enabling p2p ad-hoc collaboration for small groups
without any infrastructure</font></tt>
<br>
<br><tt><font size=2>We had the first scenario working very early on. Every
time one XO connects to an AP, it acts as a gateway for other XOs via its
mesh interface.</font></tt>
<br><tt><font size=2>Then we disabled that functionality (by means of stopping
the gateway script from running in the XOs - very easy to reenable) for
a variety of reasons, the most important being that we wanted to focus
on school server operation and having multiple gateways (MPPs - mesh portals)
under the same roof, doesn't agree with the current state of the collaboration
software.</font></tt>
<br>
<br><tt><font size=2>The second scenario works very well now for small
groups (&lt;10). Since it relies heavily on multicast and since the mesh
currently implements multicast as a controlled flooding, it won't scale
to larger numbers of nodes until we address one of the two (or better both)
issues.</font></tt>
<br>
<br><tt><font size=2>Add to that the fact that the mesh is inherently more
chatty due to its control traffic, and you realize that when you care about
how to stuff the maximum number of nodes under one roof (pushing the limits
of what people can do with WiFi in general), using the mesh where you can
easily use access points is a very suboptimal choice. &nbsp;There is no
need for multihopping inside the school.</font></tt>
<br>
<br><tt><font size=2><br>
&gt; <br>
&gt; Two Networks?<br>
&gt; Should we use AP's for the school but then also use Active Antennas
so<br>
&gt; that kids can connect to the Internet from home via the mesh?</font></tt>
<br><tt><font size=2>You could do that, you can also enable MPP functionality
on the laptops, so that the kids who are closer to the school connect via
WiFi to the school and via the mesh interface to other XOs downstream from
them.</font></tt>
<br>
<br>
<br><tt><font size=2><br>
What is ironic is that we didn't want to offer many choices to the users
(so that they don't get confused) and that lack of control is giving us
many headaches right now... People who are command-line jockeys can do
very ellaborate setups with the XOs. We have to expose those capabilities
to the GUI too.</font></tt>
<br>
<br>
<br><tt><font size=2>M.</font></tt>