Javier Cardona 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' > > dd-wrt (http://www.dd-wrt.com/) has a tab for Wireless -> WDS which allows you to disable lazy WDS.
Sameer > On 3/1/08, Javier Cardona <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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. >> >> > > > _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel