[OLPC Networking] hostap & olpc mesh
mbletsas at laptop.org
Sat Jan 12 13:17:13 EST 2008
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
(We also need the thin-MAC firmware for SoftAP functionality and advanced
sniffing and frame injection capabilities).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Networking