[OLPC Networking] hostap & olpc mesh

[Michail Bletsas]

A brief history of OLPC's mesh stack deviations from 802.11s:

We chose 802.11s for interoperability and its nice alignment with our 
power management architecture.
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)

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.

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).

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

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.
(Out testing had showed that it was the b/mcast WDS frames that were 
triggering the erratic WDS behavior on the affected APs)

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.


As far as a more "thin-MAC" implementation of 802.11s is concerned, I 
suggest that you look at 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.

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.
(We also need the thin-MAC firmware for SoftAP functionality and advanced 
sniffing and frame injection capabilities).


Michail
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080112/5ffca053/attachment.html>