WDS problems observed in today's testing

[Javier Cardona]

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.