WDS problems observed in today's testing
John Watlington
wad at laptop.org
Sat Mar 1 16:37:03 EST 2008
I was told that 17 laptops were associated on Friday, w. lots of
bandwidth
left over.
Question 1: What is "lots of bandwidth" ? CSMC networks don't work
well
past around 50 - 60% of available bandwidth...
Question 2: Did this bandwidth measurement include the relayed WDS
frames ?
wad
On Mar 1, 2008, at 2:17 PM, Kim Quirk wrote:
> 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
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
More information about the Devel
mailing list