<br><font size=2 face="sans-serif">A brief history of OLPC's mesh stack
deviations from 802.11s:</font>
<br>
<br><font size=2 face="sans-serif">We chose 802.11s for interoperability
and its nice alignment with our power management architecture.</font>
<br><font size=2 face="sans-serif">Our goal has always been to produce
a proper subset of the emerging 802.11s standard (in the same manner that
WiFi is a subset of 802.11b/g)</font>
<br>
<br><font size=2 face="sans-serif">When we started our implementation,
the 802.11s working draft called for a new frame type for mesh frames.
It was obviously a sound engineering decision which didn't reflect the
reality of millions and millions of wifi radios deployed that could not
support a new frame type.</font>
<br>
<br><font size=2 face="sans-serif">Marvell's 8388 was one of them and we
decided to move on using standard WDS frames on the 8388 while at the same
time making sure that its successor (the 8682) does support the new frame
type (a capability that Marvell immediately added to its new silicon).</font>
<br>
<br><font size=2 face="sans-serif">When many participants in the 802.11s
committee realized the magnitude of the problem using a new frame type
for mesh frames, they voted and changed the 802.11s draft to also use WDS
frames. At that point, OLPC's implementation automatically became a proper
subset of 802.11s</font>
<br>
<br><font size=2 face="sans-serif">Using WDS frames for the mesh traffic
turns out that it creates serious interoperability problems with WDS-capable
access points that implement Dynamic establishment of links with other
WDS peers (like the ubiquitous Linksys WRT54 router/AP). We found that
out during field testing and it took several months to identify all the
failure modes. Given that the lazy-WDS functionality is implemented in
the firmware of the Broadcom radio used in those devices and it can not
be turned off, we decided that we had to either turn the mesh off completely
by default in shipping XOs, or modify our frame format so that it doesn't
get misinterpreted by the Dynamic-WDS (or Lazy-WDS) APs. Given that
we still don't know exactly how Broadcom's code works (despite our efforts
to get that information from them), we took a dual approach: we added extra
header information in the XO mesh frames which allows the XO to reliably
identify mesh frames from WDS frames and we changed the broadcast/multicast
mesh frame format to use plain 3-address frames as opposed to 4-address
WDS frames.</font>
<br><font size=2 face="sans-serif">(Out testing had showed that it was
the b/mcast WDS frames that were triggering the erratic WDS behavior on
the affected APs)</font>
<br>
<br><font size=2 face="sans-serif">We have submitted our changes to the
standards committee and we hope that they are accepted into the standard,
since I don't see the millions of WRT54s going away in the next two years
and deploying 802.11s devices with plain WDS framing will wreak havoc in
WLANs using the affected radios.</font>
<br>
<br>
<br><font size=2 face="sans-serif">As far as a more "thin-MAC"
implementation of 802.11s is concerned, I suggest that you look at </font><a href=http://www.open80211s.com/><font size=2 face="sans-serif">http://www.open80211s.com
which aims to create an 802.11s implementation on top of the mac80211 stack
that is gaining traction in the linux world and is very similar from an
operating perspective to hostap.</font></a>
<br>
<br><font size=2 face="sans-serif">We are also working to release a "thin-MAC"
firmware for the 8388 that will allow most of the low-level network stack
to run on the host CPU so that the above components run on the XO, should
its user decide that he/she prefers to sacrifice power savings for a complete
open source software stack.</font>
<br><font size=2 face="sans-serif">(We also need the thin-MAC firmware
for SoftAP functionality and advanced sniffing and frame injection capabilities).</font>
<br>
<br>
<br><font size=2 face="sans-serif">Michail</font>
<br>