WDS problems observed in today's testing

[Michail Bletsas]

I have associated and run successfully web and collaboration sessions 
between groups of 5 machines with 40 XOs on a WRT54GS running DD-WRT


M.





"Kim Quirk" <kim at laptop.org> 
Sent by: kim.quirk at gmail.com
03/01/2008 02:20 PM

To
"Javier Cardona" <javier at cozybit.com>, "Kim Quirk" <kim at laptop.org>, 
"Michail Bletsas" <mbletsas at laptop.org>, "Chris Ball" <cjb at laptop.org>, 
"OLPC Developer's List" <devel at laptop.org>, "Jim Gettys" <jg at laptop.org>, 
"Ricardo Carrano" <carrano at ricardocarrano.com>
cc

Subject
Re: WDS problems observed in today's testing






Was anyone able to get a test with a different AP?  We were only able
to associate something like 20 laptops on Fri. Do we believe it should
be 30 or more?

Kim




On 3/1/08, Javier Cardona <javier at cozybit.com> wrote:
> Kim, Michail,
>
> The conclusion to all of this is that we should not use WRT54G in
> deployments, regardless of whether mesh is used or not (in fact, if we
> *only* use mesh we don't have this problem as the AP ignores mesh
> multicast traffic now).  The WRT54G will forward multicast traffic to
> all other APs in the vicinity that it identifies as peers using flawed
> criteria (Lazy-WDS).  Since the xo's generate a lot of multicast
> traffic, that creates a risk of triggering the multicast storms that
> we saw at OLPC.
>
> Javier
>
> PS. If we have no choice but to use that AP, then we should re-image
> the AP with a distribution that allows turning WDS off.  In Tomato
> (http://www.polarcloud.com/tomato) this can be achieved via Basic ->
> Wireless Mode = 'Access Point' and NOT 'Access Point + WDS'
>
>
> On 3/1/08, Javier Cardona <javier at cozybit.com> wrote:
> > Ricardo,
> >
> >
> >  > - The access point Javier mentions is the one I bought yesterday
> (Linksys
> >  > WRT54G)
> >
> >
> > Agreed, yes:
> >  35 00:1d:7e:44:ce:6e Broadcast  Beacon frame,SSID: "linksys"
> >
> >
> >  > - Most of this traffic is retransmission (3606):
> >  > (wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] ==
> ce:6e) &&
> >  > (wlan.fc.retry == 1)
> >
> >
> > Agreed.
> >
> >
> >  > - It is also interesting to detect other wds peers this AP 
identified
> (one
> >  > is 00:0b:85:53:27:50 and got 1066 of these frames).
> >  > ((wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] ==
> ce:6e))
> >  > && (wlan.ra == 00:0b:85:53:27:50)
> >
> >
> > Yes.  Note that none of the WDS peers are xo's, as was the case in the
> past.
> >
> >
> >  > It seems that the linksys is expecting acks for this wds frames 
(which
> btw are mulcast frames). It is amazing.
> >
> >
> > Well, even if the final destination is a multicast address, those WDS
> >  frames are unicast, and therefore acknowledged.  What's troubling is
> >  that the WDS links are not torn down when the link quality is so 
poor.
> >   But we all know that Lazy-WDS is a flawed protocol.
> >
> >
> >  > I believe we should compare this with the previous capture from the
> >  > Netgear AP, just to confirm that this is (again) specific to WDS 
issues
> >  > on the Linksys.
> >
> >
> > I don't have access to that capture.  Maybe David?
> >
> >  Javier
> >
> >
> >
> >  > On Sat, Mar 1, 2008 at 5:23 AM, Javier Cardona <javier at cozybit.com>
> wrote:
> >  >
> >  > > Michail, Chris,
> >  > >
> >  > >
> >  > > This afternoon I captured some traffic while Chris was running 
tests
> >  > > for Peru.  The test setup consisted on ~25 laptops associated to 
a
> >  > > WRT54 access point.  When the laptops were on, associated and 
(not
> >  > > sure about this) idle, we observed a high volume of wireless 
traffic.
> >  > > The spectrum analyzer showed close to 50% duty cycle utilization 
of
> >  > > the channel.
> >  > > We also observed that a few xo's could not associate, and some 
seemed
> to
> >  > > intermittently lose and recover association.
> >  > >
> >  > > Turning off the WRT54 (and therefore stopping all the infra 
traffic)
> >  > > freed up most of the bandwidth on that channel.
> >  > >
> >  > > In my 50 second capture (taken before turning off the AP) we 
observe:
> >  > >
> >  > > Total traffic:                  15081 frames (100%)
> >  > > All WDS traffic (1):             6023 frames ( 40%)
> >  > > WDS, xo is source addr (2):      4343 frames ( 29%)
> >  > >  (96% of the above xmitted at 1 Mbps (3) and 100% sent by a 
single
> AP(4))
> >  > >
> >  > > Compare that with
> >  > >
> >  > > xo originated infra frames (5):   401 frames ( 3%)
> >  > >  (77% of the above xmitted at rates higher than 2 Mbps (6))
> >  > >
> >  > > What does all this mean?
> >  > >
> >  > > 1. Multicast traffic gets replicated and retransmitted.
> >  > > 2. The ratio of original frames to AP generated multicast
> >  > > retransmissions is 1:11
> >  > > 3. Taking into account the data rates this means that for 1 
airtime
> >  > > unit used to transmit useful traffic, over 200 units are wasted
> >  > > transmitting useless WDS traffic.
> >  > > 4. All this is done by a single Cisco AP, MAC: 00:1e:7e:44:ce:6e
> >  > >
> >  > > Michail, is that one of OLPC APs?
> >  > > Chris, we should see a big improvement if we can disable that
> >  > > "feature" on the AP... or put it under water.
> >  > >
> >  > > I've posted my capture here:
> >  > >
> >  >
> 
http://dev.laptop.org/~javier/captures/cisco-wds-traffic-around-xo-testbed.cap

> >  > >  in case someone wants to double check my analysis (Ricardo?).
> >  > >
> >  > > Cheers,
> >  > >
> >  > > Javier
> >  > >
> >  > > (1) wlan.fc.ds == 3
> >  > > (2) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4
> >  > > (3) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and
> radiotap.datarate ==
> >  > 0x2
> >  > > (4) wlan.fc.ds == 3 and wlan.sa[0-2] == 00:17:C4 and wlan.ta[4-5] 
==
> ce:6e
> >  > > (5) wlan.fc.ds == 1 and wlan.sa[0-2] == 00:17:C4
> >  > > (6) wlan.fc.ds == 1 and wlan.sa[0-2] == 00:17:C4 and
> radiotap.datarate > 4
> >  > >
> >  > > --
> >  > > Javier Cardona
> >  > > cozybit Inc.
> >  > >
> >  >
> >  >
> >
> >
> >
> > --
> >  Javier Cardona
> >  cozybit Inc.
> >
>
>
> --
> Javier Cardona
> cozybit Inc.
>

-- 
Sent from Gmail for mobile | mobile.google.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080301/6e680f77/attachment.html>